[whatwg] How do sandboxed iframes interact with localStorage / sessionStorage / databases / etc?

On Sat, 9 Jan 2010, Adam Barth wrote:
>
> The following question came up in implementing the sandbox attribute in WebKit:
> 
> [[
> Description From Patrik Persson 2009-12-10 02:18:50 PST (-) [reply]
> This is a followup to bug 21288, which concerned the implementation of
> the HTML5 iframe sandbox attribute.
> 
> How should WebKit interpret the HTML5 spec regarding sandboxed storage
> and databases?  I believe the HTML5 spec does not say much explicitly
> on this, but rather relies on the origin sandboxing.  Here is my
> interpretation.
> 
> * I think sessionStorage would make sense with sandboxed origins.
> 
> * I think localStorage would end up equivalent to sessionStorage in a
>   sandboxed frame, making it somewhat less useful. (The unique origin
>   of a sandboxed frame means, in my interpretation, that the same
>   frame would not be able to access its own localStorage in another
>   session.)
> 
> * Similarly, I think a sandboxed database would be useful only within
>   a session.  The database could be reclaimed when the session ends.
>   This defeats much of the purpose of databases, but perhaps it would
>   still be useful for compatibility.
> 
> The current implementation disables storage and databases in sandboxed
> frames.  There is some more discussion in the thread for bug 21288,
> comments 43..49:
> ]] -- https://bugs.webkit.org/show_bug.cgi?id=32369
> 
> I think that disabling access to these APIs makes sense given that we
> disable access to cookies.

They now raise a SECURITY_ERR if called when the origin is not a 
scheme/host/port tuple. (This also affects other times that the origin is 
a unique ID, e.g. data: URLs in some situations.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 12 January 2010 19:11:13 UTC