One reason to do per-user domains is to prevent cookie leakage caused by user-specified content. A few years ago LiveJournal got bitten by a firefox bug that allowed JS execution inside CSS. Since they allowed each user to style their own page that meant that a malicious user could make the CSS at "www.livejournal.com/~evil_user" capture the viewer's www.livejournal.com cookies. That's why they moved everybody to username.livejournal.com, which previously had been a pay-only feature.
I think the really perplexing about this article is why browsers are so aggressive with DNS prefetching. If there are links on the page to 300 different domains, is there much benefit to precaching ALL of them? It seems clear that very few of the domains are likely to be clicked on. If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests.
It sounds like browsers need a better precaching heuristic.
> is there much benefit to precaching ALL of them? ... If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests.
It's a tragedy of the commons. Each individual user gains personal performance from DNS prefetching. The gain for each individual user is greater than their loss to their share of the performance penalty imposed on the entire system.
The real super smart answer would be predictive prefetching based on pointer movement. When the browser sees the mouse heading towards a link, start prefetching. Or at least on mouseover.
Well, first off the 2006 LJ issue predates the implementation of HttpOnly cookies I think. They're a fairly recent invention.
HttpOnly doesn't really fix the issue though. It prevents evil js from straight-out stealing the cookie, but it can still make HTTP requests that will include the cookies. Therefore the script could still do bad things the user's behalf (add or remove friends, scrape private data, post spam, etc...)
The LJ story is just an example of a general lesson: if you can put user-generated content in a different domain (i.e. browser security context) than your authentication-critical cookies you are in a better position. That way any javascript leakage at evil-user.yourdomain.com can't harm your users any more than if they were viewing it at www.evil-users-domain.com.
Comments
One reason to do per-user domains is to prevent cookie leakage caused by user-specified content. A few years ago LiveJournal got bitten by a firefox bug that allowed JS execution inside CSS. Since they allowed each user to style their own page that meant that a malicious user could make the CSS at "www.livejournal.com/~evil_user" capture the viewer's www.livejournal.com cookies. That's why they moved everybody to username.livejournal.com, which previously had been a pay-only feature.
I think the really perplexing about this article is why browsers are so aggressive with DNS prefetching. If there are links on the page to 300 different domains, is there much benefit to precaching ALL of them? It seems clear that very few of the domains are likely to be clicked on. If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests.
It sounds like browsers need a better precaching heuristic.
Unfortunately subdomains are not secure either, because subdomain is allowed to place cookie for the whole domain, performing session fixation attack:
http://skeptikal.org/2009/11/cross-subdomain-cookie-attacks....
the livejournal change:
http://www.davidpashley.com/blog/computing/livejournal-mozil...
> is there much benefit to precaching ALL of them? ... If anything they're probably hurting performance by bombarding the local nameserver with a flood of requests.
It's a tragedy of the commons. Each individual user gains personal performance from DNS prefetching. The gain for each individual user is greater than their loss to their share of the performance penalty imposed on the entire system.
The real super smart answer would be predictive prefetching based on pointer movement. When the browser sees the mouse heading towards a link, start prefetching. Or at least on mouseover.
That doesn't sound like a good enough reason, why not just use HTTPOnly cookies to prevent that?
Well, first off the 2006 LJ issue predates the implementation of HttpOnly cookies I think. They're a fairly recent invention.
HttpOnly doesn't really fix the issue though. It prevents evil js from straight-out stealing the cookie, but it can still make HTTP requests that will include the cookies. Therefore the script could still do bad things the user's behalf (add or remove friends, scrape private data, post spam, etc...)
The LJ story is just an example of a general lesson: if you can put user-generated content in a different domain (i.e. browser security context) than your authentication-critical cookies you are in a better position. That way any javascript leakage at evil-user.yourdomain.com can't harm your users any more than if they were viewing it at www.evil-users-domain.com.