Why aren’t cookies hierarchically named?
One of the big problems with internet browsers is the cookie namespace. Right now, cookie names are associated with an internet domain, whether that domain was the primary instigator of the internet access or subsidiary. If you access as site, foo.com, it can set and get cookies associated with foo.com. If the asset accessed then accesses another site bar.com, it can set and get cookies associated with bar.com. This is great, except now the server for bar.com assets can track references whether from foo.com or another site.
That’s the problem with a flat cookie namespace. If we had a hierarchical namespace, assets from foo.com could set and get cookies associated with foo.com, but if that asset then accessed an asset from bar.com, the cookies would have names of the form foo.com>bar.com which could only be accessed by assets from bar.com which had been requested by foo.com.
That’s huge sentence, so I’ll break it up a bit. Right now, cookies have names which match the domain name of the setting or getting asset. An asset from the site foo.com can access any cookie from that domain. If foo.com/whatever.html sets a cookie, then that cookie is available whenever the user browses anything on the site foo.com. (It’s actually a bit more complex than that since there is also subdomain matching, but that isn’t very important here.)
If foo.com/whatever.html includes some asset from bar.com/whocares.html, then the current cookie naming scheme allows any asset from bar.com to access cookies associate with bar.com. With a hierarchical naming scheme, an asset from bar.com requested by an asset from foo.com would only be able to access assets from bar.com elements which had been requested by assets from foo.com, that is, cookies with names of the form foo.com>bar.com. You could be tracked, but only within a limited domain.
This is an old idea, though it addresses a more recent problem Anyone who was following the work of Anita Jones at CMU in the 1980s will get a sense of deja vu here. She did a lot of work on software protection and protection in distributed systems. She was concerned with the issues of trust, in which a user would have give certain access to a second party software component which could then give further access to a third party software component. Needless to say, this sort of work was barely appreciated back then and woefully under funded.
Now, we think nothing of loading a second party piece of Javascript code into our browsers and running it on our computers. We even allow that less than completely trusted piece of software to access third and fourth party pieces of software and give them first class access to our system and its resources. This wasn’t a big problem in the 1980s, but it became a big problem starting in the 1990s.
One of her solutions involved something even older, capabilities. These were specific rights that could be granted to partially trusted software components. These were proposed in the 1960s, but generally ignored as impractical and inefficient and whatever. They probably were. Nowadays, though, we think nothing of granting specific rights to applications on our home computer, in our browser or on our cell phone. We don’t want every website we access to grab our contacts list or be able to print on our printer.
Jones’ solution involved the user granting the first layer of second party software a set of capabilities which it could then pass on to the second layer and so on in turn. If you didn’t let a program access your tape drive, then it couldn’t let another program do so. If there was some common package used by more than one program, perhaps a graphics package, there was no reason that package should be able to rack up charges on the plotter unless its invoking program had that privilege.
Wow, that was one hundred years ago. This sounds like the stuff Abraham Lincoln worried about when they put a telegraph station in the White House. Still, this kind of hierarchical thinking can serve us today as any unprotected computer on the internet is quickly turned into a hive of malware. A flat cookie namespace encourages this. Program invocation is not flat, no matter what Thomas Friedman says. (He’s sort of the modern Aristotle, the man every essay starts out with as confirming as wrong.) A hierarchical cookie namespace better reflects the real world and the layers of trust and access we expect from our software.