W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] Should DOM storage objects be mapped by an "effective script origin" rather then just an "origin"?

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 26 May 2009 02:40:57 -0700
Message-ID: <63df84f0905260240w77e3182ew487d26fa217405c5@mail.gmail.com>
On Tue, May 26, 2009 at 2:26 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 26 May 2009 09:31:15 +0200, Honza Bambas <honzab at allpeers.com> wrote:
>> See also mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=494799
>> Effective script origin driven by document.domain is used to allow
>> sharing of properties and data among pages coming from different
>> subdomains. Should this "data sharing" apply also to sessionStorage and
>> localStorage? It means: having page load from http://test.mysite.com
>> accessing sessionStorage would get sessionStorage bound to
>> http://test.mysite.com. When that same page than changes document.domain
>> to http://mysite.com, sessionStorage it gets now should be a different
>> object, bound to http://mysite.com. A reason to do this is also because
>> of security checking. The subject's origin changes to http://mysite.com
>> and access to sessionStorage bound to http://test.mysite.com should not
>> be allowed (origins are not equal).
>> Opinions?
> I'd rather not leak document.domain leak more than necessary. Especially with it being bound to the Public Suffix List. If you want to communicate across origins you can always use postMessage().

Agreed! Document.domain is a wart on the otherwise perfect face of the web :)

Seriously though, I definitely don't see a reason to leak
document.domain hacks more than neccesary. Further, generally the
document.domain feature requires that two pages set document.domain to
the same value in order to communicate. If localStorage was affected
by document.domain, that would mean that foo.example.com could read
example.coms data without example.com ever opting in to this.

/ Jonas
Received on Tuesday, 26 May 2009 02:40:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:12 UTC