22481 2013-06-26 17:45:08 +0000 Spec should include rationale for security checks on localStorage 2013-07-26 00:13:09 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 bobbyholley ian ian jonas mike w3c contributor oldest_to_newest 89904 0 bobbyholley 2013-06-26 17:45:08 +0000 Hixie explained on IRC that it has to do with per-origin storage mutexes, but that's a bit of a leap to make from just reading the spec. It would be helpful to list that rationale here: http://www.whatwg.org/specs/web-apps/current-work/#security-localStorage 90240 1 ian 2013-07-03 16:56:01 +0000 Upon further investigation, the storage mutex rationale here doesn't hold water. I don't know why it's designed this way. 90509 2 ian 2013-07-09 20:03:27 +0000 Adam, do you remember why we block scripts that used document.domain from accessing the WebStorage objects from their original origin? 90528 3 bobbyholley 2013-07-09 20:53:39 +0000 (In reply to comment #2) > Adam, do you remember why we block scripts that used document.domain from > accessing the WebStorage objects from their original origin? Well, the wouldn't have access to the original origin, right? Shouldn't it just behave like document.cookie and give you the local data from your effective script origin post document.domain? 90559 4 ian 2013-07-09 23:36:44 +0000 Do we really want the magic document.domain origins to have storage areas? I'm not sure how we'd even explain that to the user. 90562 5 bobbyholley 2013-07-09 23:50:19 +0000 (In reply to comment #4) > Do we really want the magic document.domain origins to have storage areas? > I'm not sure how we'd even explain that to the user. I don't follow. I don't know much about this, but I'd assume that when foo.bar.com sets document.domain to bar.com, document.cookie gives you bar.com's cookies, and window.localStorage gives you bar.com's storage. I haven't tested this in any UA (and haven't even checked what gecko does) FWIW. 90571 6 ian 2013-07-10 00:26:29 +0000 If your origin is 'http://sub.example.com:80' and you set document.domain to 'example.com', your effective origin becomes 'http://example.com:manual override'. Other than through document.domain, you can never reach this origin. It doesn't map to any real Web site. 90572 7 bobbyholley 2013-07-10 00:45:45 +0000 (In reply to comment #6) > If your origin is 'http://sub.example.com:80' and you set document.domain to > 'example.com', your effective origin becomes 'http://example.com:manual > override'. > > Other than through document.domain, you can never reach this origin. It > doesn't map to any real Web site. So, do you get special cookies for http://example.com:manualoverride? If so, then couldn't we do the same localStorage? 90684 8 ian 2013-07-12 19:43:49 +0000 document.cookie, per spec, is unaffected by document.domain. It sets the cookie against the page's URL (which can change using pushState(), e.g.), not the page's origin. (Cookies are set to a URL with a path, not to an origin like Storage.) 90824 9 bobbyholley 2013-07-16 23:02:53 +0000 (In reply to comment #8) > document.cookie, per spec, is unaffected by document.domain. It sets the > cookie against the page's URL (which can change using pushState(), e.g.), > not the page's origin. (Cookies are set to a URL with a path, not to an > origin like Storage.) Ah, I see. Are there any other APIs in the spec world that store persistent data? What happens for indexedDB? 91179 10 ian 2013-07-23 23:34:21 +0000 Good question, I don't know. Sicking? 91255 11 jonas 2013-07-24 18:45:03 +0000 A page from "http://foo.bar.com" that has set its document.domain to "bar.com" definitely should not be able to access "bar.com"s local-storage data. The security model of document.domain is that for a page from "http://foo.bar.com" to be able to interact with "bar.com" in any way, something from "bar.com" has to opt in to that. I.e. a page from "*.bar.com" needs to also set its document.domain to "bar.com". I don't think document.domain should affect the behavior of localStorage at all. It doesn't affect indexedDB or EventSource or XMLHttpRequest at all. I.e. in all those cases do we behave as if document.domain had not been set. I.e. if a page on "http://foo.bar.com" sets document.domain to "bar.com" and makes a XHR request to a page on "http://foo.bar.com" it is still treated as a same-origin request. And a request to anything on "bar.com" is still treated as a cross-origin request. And if the request uses CORS, we still send "http://foo.bar.com" as origin. And if that same page accesses window.indexedDB from its own window, it will get data for the "http://foo.bar.com" origin. If two pages from "http://foo.bar.com" and "http://crow.bar.com" both set their document.domain to "bar.com", and the page from "http://foo.bar.com" accesses otherWindow.indexedDB, where 'otherWindow' refers to the window for the "http://crow.bar.com"-page, that it would get data for the "http://crow.bar.com" page. I.e. the data that you receive should be based on the window you are getting the indexedDB property from. document.domain only affect which objects you can reach, it doesn't otherwise affect storage or network APIs at all. 91297 12 ian 2013-07-26 00:12:56 +0000 So basically, remove all the security stuff around Storage... Yeah, that seems reasonable. Ok. Done. This will simplify some of the other discussions, too. 91298 13 contributor 2013-07-26 00:13:09 +0000 Checked in as WHATWG revision r8090. Check-in comment: Remove the weird stuff around document.domain and localStorage. It doesn't really do anything anyway. http://html5.org/tools/web-apps-tracker?from=8089&to=8090