W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] iframe sandbox and indexedDB

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 7 Sep 2012 04:14:25 +0000 (UTC)
To: Ian Melven <imelven@mozilla.com>
Message-ID: <Pine.LNX.4.64.1209070410460.30734@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org, Adam Barth <w3c@adambarth.com>
On Mon, 6 Aug 2012, Ian Melven wrote:
> Adom wrote:
> > Yes.  I think this is actually a consequence of having a unique origin 
> > and doesn't need to be stated explicitly in the spec.  (Although we 
> > might want to state it explicitly for the avoidance of doubt.)
> 
> yeah, i can see how this situation behaves being implementation 
> dependent - some implementations might allow storing data for the unique 
> origin, which seems undesirable. So, it might be worth stating the 
> restriction explicitly, as it is for LocalStorage.

The restriction on localStorage is just because of the following 
requirement in the Web Storage chapter:

 2. If the Document's origin is not a scheme/host/port tuple, then throw a 
    SecurityError exception and abort these steps.

It has nothing specifically to do with sandboxing. The same would happen, 
e.g., if the page was a data: URL typed by a user (which is another case 
where the page's origin isn't a tuple). Whatever part of IndexedDB says 
what should happen for documents from handtyped data: URLs and any other 
situations with non-tuple origins should automatically cover the case of 
sandboxed content as well.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 7 September 2012 04:14:52 UTC

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