The logger was obviouslly there, it was deliberatly collecting the SSIDs and MAC addresses.
Possibly a debug option to log the whole packets added during development, and it was accidently left on in production.
Or the whole packet was always logged, a second process would then skim just extracting the SSID/MAC (correlating with GPS), and another process was deleting the raw logs. That third process failed.
A few big drives in teh data collection devices, and possibly nobody noticed where filling up a little too quickly.
Surely the point of a 'signup' is to create an account able to login into a webapp (or similar)
This appears to just capture the details into a database. There isnt even an API to allow users to login to do something (eg to access a hidden download page)
... so really its just a Form data capture tool, ala wufoo, used for surveys or petitions sort of thing. Not signups.
tinyurl and other shorteners generally use a 301 redirect, which often does pass 'link juice'.
nofollow is usually under the control of the webmaster. Which may or may not be the same as the content creator.
Think forums and blog comments, as poster you generally have no control if nofollow is added to links. Usually it should be, but no garentee.
Also think of sites like twitter, facebook and g+, again you can't ensure that nofollow is added. Similally when that content is then copied or syndicated. You can usually hope that the copier will perserve the link itself, but they may or may not choose to 'nofollow' the copied link.
And lastly, 'bad' bots, may well ignore the nofollow anyway. It would have to be broken/clever bot to get the destiniation from donotlink
Its quite probable the engineer that built the layer has left (either Google altogether, or just to another team).
As its aged its started misbehaving, and nobody left is interested enough to figure how to fix it. Ultimately its easier just to ditch it than to maintain.
Look carefully at the source code. Its bogus. Not the etags trick, but the demo itself.
The demo is actually just identifying users by hashing the REMOTE_ADDR and USER_AGENT, HTTP headers.
So it appear to work, when it doesn't really. Users with dynamic-ip or via proxies etc will often fail.
This is why it appears to work cross incognito windows. Chrome sends the same useragent incognito or not.
----
The etag trick is real. But DO need to use Javascript in the browser to extract the etag from the headers of the cached image. It doesnt really have to be an image. Just a request that can be made via XMLHttpRequest.
... or could set the etag on the page itself, and use the fact that the browser will send a If-None-Match on the next request. But only works for the one single uri, not all pages on the domain. The code appears it COULD be used to do that. But it never sets ETag http header on itself.
Really the Reader "Web App" - is not that exiting. Cloning it is only a matter of a few days work.
The interesting bit is the 'backend', the crawler and database, ie the servers that supplies the API. But that simply can't be open-sourced, as it too Google centric.
I just used TT-RSS for the backend, and built my own GReader like front end in a matter of ours.
... these are almost certainly used in many spelling and grammar checkers. (To help with where the same spelled word is used in different context)
http://www.aclweb.org/anthology/W12-0304