Re: [whatwg] iframe sandbox and indexedDB
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox and indexedDB
On Mon, 6 Aug 2012, Ian Melven wrote: > > the spec at > http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-origin-browsing-context-flag > > says : > > "This flag also prevents script from reading from or writing to the > document.cookie IDL attribute, and blocks access to localStorage." > > it seems that indexedDB access should also be blocked when this flag is > set (ie when 'allow-same-origin' is NOT specified for the sandbox > attribute). It is, assuming that IndexedDB is based on the origin of the document. The spec doesn't mention it because IndexedDB isn't part of the HTML spec. Note that the sentence you cited is non-normative (or rather, it contains no normative statements), so that whether it mentions IndexedDB or not doesn't change anything about what the spec says. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox and indexedDB
Hi, - Original Message - From: "Adam Barth" To: "Ian Melven" Cc: whatwg@lists.whatwg.org Sent: Monday, August 6, 2012 5:12:40 PM Subject: Re: [whatwg] iframe sandbox and indexedDB > 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. thank you for the clarification on why document.cookie is explicitly called out :) thanks, ian
Re: [whatwg] iframe sandbox and indexedDB
On Mon, Aug 6, 2012 at 5:08 PM, Ian Melven wrote: > the spec at > http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-origin-browsing-context-flag > says : > > "This flag also prevents script from reading from or writing to the > document.cookie IDL attribute, and blocks access to localStorage." > > it seems that indexedDB access should also be blocked when this flag is set > (ie when 'allow-same-origin' is NOT specified for the sandbox attribute). 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.) The reason document.cookie needs to called out explicitly is that it doesn't use the document's origin to determine which cookies to access: it uses the document's URL. We need to do that because cookie ignore the port but do care about the path part of the document's URL. (The better pattern for new API is to use the origin, which is what IndexedDB does.) > i intend to implement this restriction in Gecko, feedback from other > implementors is welcome :) Great. Adam
