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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 18 07:51:31 PST 2009


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





--- Comment #41 from Darin Adler <darin at apple.com>  2009-11-18 07:51:25 PST ---
(In reply to comment #40)
> I understand your concerns regarding SecurityOrigin::equal(). We had a
> closer look, and think that SecurityOriginHash is a better place for
> this check. The check now explicitly concerns hash table equality (for
> same-origin comparisons). The change also fits nicely with a FIXME in
> SecurityOrigin calling for similar refactoring.

I don't think that's right. I appreciate your efforts, but this is still wrong.

> I am currently
> unable to see how to get around this without a re-design of the local
> storage database. (As long as the database uses hash tables for
> same-origin comparisons, there has to be an equals() somewhere that
> compares two SecurityOrigins and accounts for sandboxing.)

That's incorrect.

There's no reason we can't do security checks either before or after looking in
the hash table. There's no reason to put sandboxed security origins into the
table in the first place. More importantly, the sandboxing state could change
on a security origin once it's in the hash table.

The point of the hash is to be able to store per-security-origin data such as
the quota, database origin, usage, and storage area. There's no reason the
hash's equality function also has to perform the security check.

There's no need for the equality function of the hash table itself to consider
the sandbox flags. There's no need to look at the hash table at all if the
origin is sandboxed.

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



More information about the webkit-unassigned mailing list