Upon further investigation, the storage mutex rationale here doesn't hold water.

I don't know why it's designed this way.

Adam, do you remember why we block scripts that used document.domain from accessing the WebStorage objects from their original origin?

(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?

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.

(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.

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.

(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?

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.)

(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?

Good question, I don't know. Sicking?

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.

So basically, remove all the security stuff around Storage... Yeah, that seems reasonable. Ok. Done. This will simplify some of the other discussions, too.

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