(Read Introduction and Summary first.)
The most important single feature not yet available for this demo (as of January, 2012) is public accounts (smart links). Public accounts are the public face of the administrative (secret) accounts that you can create and (minimally) manage in this demo. In the future, clicking a smart link will give the end user a small public dashboard, which will provide whatever capabilities and restrictions the account owner chooses to provide (and no other capabilities) to anyone who has a copy of that particular smart link.
Our RepliCounts software and its documentation is free and open source, available to everyone for commercial or non-commercial use, under the license provided and with no further permission from us. We trademarked the RepliCounts(tm) name only to avoid confusion (and to encourage others to use better names, with better emotional resonance). We chose to license this software and documentation under the Apache License Version 2.0 (instead of public domain, the "MIT license," or Creative Commons), because the Apache License includes some resistance to patent abuse. We expect that both proprietary and open-source software will deliver RepliCounts-like services, in a competitive (non-monopoly) environment where companies and other organizations can distinguish themselves by marketing assistance to the artists, for example, as well as by their prices and software.
There are two kinds of RepliCounts: administrative accounts, and public accounts (not yet implemented). You can create and manage administrative accounts through the owner's dashboard, entered through the RepliCounts home page, www.replicounts.com. The assigned name of an administrative account is always a 40-digit number (not beginning with zero). But if you don't need high security, you can and should create one or more nicknames (aliases) for convenient use, and better security in practice.
The name of your administrative accounts is also its password, so keep it secret. You will have the only copy on Earth; even the server keeps only a hashed copy of your account name, so neither we nor anyone else can replace that name if you lose it. That's why everyday use should be with an alias, with the master account name (the 40-digit number) stored away for safekeeping, and used only to regain control of your account in an emergency (if an alias is lost or stolen).
Master accounts can have their own master accounts as well (not yet implemented), to any depth. So you can give access to an important account to others to manage in case you die or are incapacitated -- yet take back control at any time you decide to do so, if you are still around. And you can give account access to a hierarchy of people, with those lower in your hierarchy able to manage its affairs unless overruled by someone higher.
We are surprised that hierarchical passwords are not more widely used, since they would solve some problems. People could turn over limited or unlimited management of personal or business affairs to family members, friends, colleagues, and/or professionals, in case (and only in case) they were no longer able to do it themselves -- yet take back that access if ever necessary. When people die their online friends could be notified, instead of becoming inaccessible.
Public accounts (also called smart links) are created and managed by administrative accounts (or alternatively created by replication of existing public accounts). But public accounts are accessible to almost anyone, simply by clicking a link -- for example, www.replicounts.com/YourPublicAccountName (capitalization does not matter -- so you can "decorate" the name with capital letters, without anyone needing to remember which ones are capitalized).
Anyone who clicks a public account will usually visit a minimal public dashboard, which lets a member of the public do certain things that the account owner chose to allow.
For example, when this system is able to handle money, the public dashboard will usually allow anyone to purchase any number of sponsored copies of a particular digital work -- or download a copy free if and only if a sponsored copy is currently available. The free users may also be able to see certain up-to-the-minute account statistics and other information that the owner wishes to release (such as how much money has been raised through a fundraising campaign so far.) Users can also change the working language to which that smart link (and later copies of it) are currently set. (This working-language system is separate from Google Translate).
A smart link need never expire, but can travel indefinitely in multiple copies, through social networks as long as sponsors and end users care about the art, journalism, or other content it delivers -- paying the artist(s) as it goes. And different copies of the same RepliCounts smart link will be able to use different languages simultaneously -- for art sales, free art distribution, fundraising, and other coordinated actions across language and cultural barriers.
Stay tuned.
(A) The same 10 digits are familiar in all countries and languages. So these account names are international -- and easily entered on any phone (on the rare occasions when manual entry is necessary).
The numbers are 40 digits because at least 39 digits are needed to provide 128-bit complexity against a brute-force password attack -- a standard respected today. We rounded up to 40. The first of the 40 digits is always non-zero, to avoid any confusion about whether or not leading zeros must be entered.
A 40-digit number is bigger than people may realize. So you will almost certainly have the only copy of your account name on Earth. In fact, even if the Milky Way galaxy has a million Earth populations of intelligent creatures, and there are a million similar galaxies out there, and every one of those beings has a billion 40-digit numbers with them, and every one of those numbers everywhere in all the galaxies is different, then the chances are about one in a billion that your account name already exists somewhere in all those worlds. Note that the RepliCounts server hashes your number immediately and destroys the original. So you are responsible for your account name's security; if anybody else has a copy, they got it somehow from you.
* (Q) Why is there only an account name, but no separate password (usually)?
(A) Part of our reason for starting this project was the frustration of typing in so many separate fields to pay with a bankcard. Every one is an opportunity for the customer to make a mistake. We wanted an easier way to do ecommerce, and to automate it -- such as a single name that can be pasted into a field with one click, or easily filled in automatically.
Our system is like that of the numbered Swiss bank accounts. You bring the number in, you can take the money out -- since the account name (the 40-digit number) is also the password. There's no need for a separate password if you make the number long enough. (Yes, there is more vulnerability from having only one item to steal for account access. But when ultra-high security is needed, this should be addressed by 2-factor authentication -- e.g. your account calls your phone for a PIN, which can be made to change every time. Just adding more fields transmitted over the same communication channel is not good security.)
The reason this traditional Swiss system is not in common use is that there is no obvious way to involve third parties -- to pay them from the account, for example, or even just to let them deposit into it. All you have is the account number, and you cannot give that to anyone without giving them the ability to empty your account.
But with replicating accounts, the whole picture changes. An administrative account can produce new accounts -- including special, limited accounts that can take money in, and can give out valuable information such as a particular digital song or investigative news article that needs to repay the cost of its production -- but can never give any money out. In RepliCounts, these are what we call public accounts (or smart links, since they are usually accessed by a click). For example, a sponsor might pay $100 to a smart link, for 1,000 prepaid showings of a video at 10 cents each paid to the artist (minus maybe 0.1 cent each to pay for the RepliCounts processing). Then 1,000 people (a group the sponsor can more or less choose) can click on the same public account to download that song, etc., completely free and registration-free. But all a criminal could do with that public account that sold for $100 would be to download 1,000 identical copies of the file (perhaps requiring 1,000 different computers), and there's not much incentive for that.
Also, RepliCounts will let different sponsors add their own sponsorship to that same smart link, which can manage unlimited sponsorships simultaneously (each with a different number of copies paid for, a different number used so far, a different sponsor's message to give out, and other characteristics). Or any new sponsor can have an existing smart link reproduce another smart link. This gives the sponsor more control over who receives the art that sponsor paid for -- at the cost of less outreach to new people who share the sponsor's interest in the same content, but may have no connection to the sponsor's existing social networks.
Security-wise, while the administrative account name (the40-digit number) cannot be given out to anyone, its owner can have it produce any number of public accounts (smart links) that serve as public faces of the account -- for conducting business with the general public, with a limited public, or with other robot accounts. And different public faces of the same administrative account can do many different things.
* (Q) [a bit technical] What have you done to make this system work fast over poor connections?
The most important principle is to make each round trip to the server count -- deliver useful information to the user, with no trips to other servers for ads, analytics (we'll use the logs), scripts, or images unless you ask for them, etc. Think of a user on the train, coming out of a tunnel for a few seconds before going underground again and being out of contact for an hour; that few seconds of phone access could deliver an entire project page for a small-group project (using the Affinity software we will create next), or perhaps a newspaper article or other document.
Google Translate (which uses JavaScript) works surprisingly fast; however, it does slow down the RepliCounts user significantly if it is downloaded, even if the user does not ask for any translation. So we don't load it unless the user asks for it, by clicking the language-bar link at the top of the initial home page only. In that case, Google Translate stays selected, and provides a language selection box for all pages (it may take a few seconds for the box to appear). To get rid of translation and go back to the fast, untranslated system again, just start over by visiting the home page. (If you reach the home page through your Back button, you will need to remove the 'i', etc. in the address bar, at the end of the URL -- it stands for 'international', and tells RepliCounts to load Google Translate with each new page). The fast system could be extended to certain other languages too, by pre-translating the pages, and we could build support in the server for such a system, but this is a lower priority since Google Translate is available and works well.
There's something else we use for speed. "Write-only memory" is a joke in the computer business; why write to memory is no one will read it? (One engineer wrote specs as a joke, and management only found out when customers called for pricing.) But we use write-only memory for real, almost.
The main purpose here is not speed (since disk access is usually much faster than network transmission), but to resist DDOS attacks conducted by "bot herders" who may use thousands of zombie computers (secretly controlled without their owners' knowledge) to flood a website with many thousands of requests to shut it down, sometimes to extort payment. With RepliCounts, no user can do anything without either having an account already, or starting one. And any account being abused can be suspended automatically, at least until the attack is over. So a key to ultra-fast response to DDOS is to not allow anyone without a valid account to do any disk access at all. Instead the server responds to each request, legitimate or otherwise, entirely from the computer's memory. The usual response to a non-existent account will be an "Error, try again, no such account:" message, but this can be suspended during an attack too, to save bandwidth.
The attack might still flood all the communication channels to the RepliCounts server; this is something we cannot control from the RepliCounts software. (But each attack query to RepliCounts can be limited to very little bandwidth, as explained above; so the communication flood might be addressed by services that can provide much more bandwidth and charge for it during the relatively short time a major attack continues, keeping the website in operation for legitimate users.)
So at least the test for a valid account should be done entirely in memory. (And so far, everything else is done entirely in memory as well -- even this documentation you are reading stays permanently in memory for super-fast delivery, though we will soon move the larger static files to a fast Nginx server.) But servers do crash, and of course backup is needed, so memory alone is not enough. Therefore, all changed accounts are written back to disk (when there is time -- no rush, because account processing always uses the memory version only, and that copy is always current). Except in case of emergency or otherwise restarting the system, the disk copy never gets read -- it just gets written over again and again (although if disk write requests to an account stack up, all but the last one can be discarded). So most disk write errors don't matter (because the erroroneous data will be overwritten before being used), and most disk read errors don't happen at all.
Another advantage is that when one process is writing to an account, it needs to block certain access to that account by other peoples' requests for only a very short time, while the writing occurs to computer memory (not to disk).
And another advantage is that in case the disk writes get behind, and updates to accounts pile up, that's no problem at all (unless the power happens to go out then, or some other crash occurs, causing loss of the new updates).
Almost always (always so far, and into the foreseeable future), all the RepliCounts are quite independent of each other. So even if a server crash should occur and one or more disk updates are lost (which will be rare), usually there is no such thing as the different accounts getting out of synch. If data loss does happen, by far the most likely effect is that a single extra copy of sponsored content will get delivered. E.g. the sponsor bought 100 prepaid copies of a song or video, but a single decrement didn't get recorded, so 101 copies are given out. No one will complain.
Favicon: We have one. We don't need it. But if we didn't have it, browsers would keep asking for it, causing many unnecessary network requests. Better to give them what they want, right away.
* (Q) What security does this software have now?
We don't yet have the most important security, which is SSL for all communication between the account owner and his/her/its administrative accounts. No problem adding it -- though we will need to offer RepliCounts with and without, since some countries outlaw most encryption, and we want RepliCounts to be globally available (at least for experimentation and non-financial uses, if encryption is banned). With and without will probably require two separate, independent Web sites, with each user account only on one, to avoid offering any unencrypted communication with the encrypted system.
The most critical need for encryption will be for payments by sponsors using bankcards, PayPal, etc. We may be able to offload these payments to specialized shopping-cart companies. So SSL isn't our most important issue just now.
We also "escape" dangerous characters in user input, so that malware cannot be imported that way.
When users enter their own Web links, we should have a phish/malware test to avoid accidental or malicious entry of dangerous sites. We are looking for options.
At this time we do not plan to encrypt information that users enter into their accounts, because we are not security specialists able to deliver that level of protection.
The RepliCounts demo software does protect users' account names when they are in the server (so that if someone steals a copy of the server's entire database, they cannot impersonate users on the live system). This is similar to security used for bankcards.
The main security advantage of the RepliCounts design is something else entirely. RepliCounts allows easy or automated creation/destruction of new accounts, most or all of which may never need to have dangerous information or much money in them -- or that have irrevocable restrictions that might be intolerable for general-purpose accounts, like never being able to pay anyone except a single party, or except members of a secret list of parties, or only with telephone approval for amounts over a level set by the account owner. Irrevocable restrictions can mean that even theft of full owner's access will usually not be enough to get the money (the owner can kill the account and have the money delivered to a secret location -- or a criminal with owner's access can kill the account, and have the money delivered to the legitimate owner, at the same location). So while SSL must be provided, the key security advantage of RepliCounts will be to allow much more flexibility in the inevitable trade-offs between convenience and security.
For example, a code that pays only 5 cents, and only pays it to a single payee, will usually not need any other security -- allowing people to publish special email addresses that charge senders a small fee, paying the addressee to receive the message. This will stop almost all spam (the payee will be the email provider that offers the service, which will deduct its fee and send most of the payments to the email recipient). And with only one payee, the amount could be $50 or $500- as well, sent in ordinary email with no encryption -- for instant, spot consulting, a new channel for fundraising, or perhaps personal contact with celebrities, who might even earn a living by receiving and answering special email. And with RepliCounts, there could be many competing premium email services, and a sender could use one account to pay any of them, avoiding pressure to have just one premium-email service. (AOL tried charging for email several years ago, but was rightly rejected because their design was very poor, and would have been a nightmare to live with. Worst of all it affected peoples' existing email. The RepliCounts system of "premium" accounts will leave email strictly alone, using new, special addresses maintained and forwarded by a provider of this service.)
(Q) How can one find out more about RepliCounts?
(A) An earlier (pre-demo-software) description of the idea is archived at www.replicounts.ORG. There have been changes in details and terminology, but as far as we know, nothing needs to be retracted and all the services proposed there are technically viable. Now that we have running software, not just a description, we are completely rewriting the documentation for our new site, www.replicounts.COM.
Copyright 2011 John S. JamesLicensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.