[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 #52 from Darin Adler <darin at apple.com>  2009-11-19 11:21:35 PST ---
(In reply to comment #48)
> (In reply to comment #43)
> > (In reply to comment #42)
> > > W.r.t. the equal() issue: The way a sandboxed origin is modeled in HTML5 is as
> > > a "unique value," which you can think of as a random string for each instance
> > > that's not equal to anything except itself.  We might improve our
> > > implementation of sandboxed SecurityOrigins by representing them this way.  If
> > > we do that, it's clear that two sandboxed origins are equal if, and only if,
> > > they are the same physical object.
> > 
> > That sounds like a good design. When sandboxed, a SecurityOrigin would not
> > check anything except object identity to determine equality and to do hashing.
> 
> I'm a bit confused. That was what we were trying to do, an equal()
> implementation that always returns false if one or both of the
> SecurityOrigins is sandboxed (unless we compare an object to itself).

Yes, it was my misunderstanding from the start, not something wrong with the
patch.

The code you added only kicked in after comparing all the other aspects of the
security origin, so I think it obscured the fact that you were implementing
this rule and in fact all other aspects of the origin were irrelevant.
Similarly, you updated the equal function but not the hash function originally,
which further confused me. I think a comment might have made the difference,
explaining the model.

It's possible this could be the right direction in the future, but to make it
more clear why things work this way I think the sandboxing check could be
earlier in the function. Or there could be a comment about why not.

I worry about the security origin having other data that's misleading. Data you
should never look at in a sandboxed origin. Who cares what the host name is if
it really has no effect on the security policy. Perhaps it should be illegal to
even get it from the security origin for a sandboxed origin. Maybe it's useful,
but only for debugging?

> I think sessionStorage would make sense, as long as sandboxes are
> respected. I think localStorage would end up equivalent to
> sessionStorage in a sandboxed frame, making it somewhat less useful. I
> don't think a sandboxed database would be very useful: it wouldn't
> survive beyond a session.
> 
> Our idea with previous patch was to sandbox localStorage and
> sessionStorage with respect to origin, and to disable databases in
> sandboxes entirely. I should have been clearer about this assumption
> from the start.

We should communicate our plans to the others implementing HTML5. Maybe we
*should* have non-useful sandboxed databases that are deleted when the frames
are. And have local and session storage that only lives the life of the
sandbox.

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