[Webkit-unassigned] [Bug 21288] Implement HTML5's sandbox attribute for iframes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21288





--- Comment #47 from Darin Adler <darin at apple.com>  2009-11-18 16:24:17 PST ---
(In reply to comment #46)
> Our intention was to implement sandboxed frames to have
> a unique origin, like Adam Barth's comment suggests. In particular, the same
> frame at a later time would have a new origin and not be able to access data
> from a previous session.

Seems OK. And Adam had some ideas about how to implement that correctly.

> However, if you would prefer sandboxed frames to simply receive Undefined from
> window.localStorage()/sessionStorage(), then I think the equal() discussion is
> solved. (We were able to easily move all other sandbox checks away from
> SecurityOrigin equality except database/storage access.) I'm sorry for not
> presenting this alternative earlier, and wasting your time in the meantime.

Is this really only about storage, not databases? I guess we already sandbox
databases with some other change I forgot?

It's not really my preferences that are important here; as I’m sure you know,
issues that matter are cross-browser compatibility, matching the standard, and
making sure the features are useful and work together well. What do you think
HTML5 suggests for this?

Do you think it's important to allow ephemeral storage that's limited to a
single sandboxed frame tree? Will we make some helpful use cases impossible if
we don't allow this?

I think an initial version that simply blocks localStorage and sessionStorage
would be a fine start; there's no need to hold the entire thing up until this
is resolved.

Refining further should be straightforward.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.