[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 #46 from Patrik Persson <patrik.j.persson at ericsson.com>  2009-11-18 12:35:38 PST ---
(In reply to comment #45)
> (In reply to comment #44)
> > I haven't tested this, but I suspect it would be as simple as a
> > sandbox check in DOMWindow::localStorage()/sessionStorage().
> 
> Sure, makes sense.
> 
> So you changed the equal function for some reason relating to storage and
> database. What was the design you were trying to implement? What did you expect
> storage-wise and database-wise? Did you expect a separate store that only lived
> as long as the sandboxed frame? If so, then where is the code to delete the
> storage and database when the frame goes away? Did you expect to prohibit
> storage and database access in the sandboxed frame?
> 
> We need to design before we can nail down the implementation.

I understand we should have been clearer in how we interpreted sandboxed
storage and databases. 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. Your points above are very valid and suggest that we
may need to think more about that alternative, if you want us to pursue it.

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.

I absolutely agree that we should reason about design rather than
implementation details. We're still learning about WebKit on our side, and we
need to try design alternatives to understand them. I understand this makes for
frequent patches to review. Any feedback on how we can streamline the review
process is welcome.

Thanks for enduring our patches and cocky comments. We appreciate your work.

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