[Bug 27196] Blob URL origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27196

--- Comment #5 from Boris Zbarsky <bzbarsky@mit.edu> ---
> What is legacy about a base URL?

The insane way it's computed for things like setting location.href.

And then we wanted to be consistent with that elsewhere, so we have the same
insane base URL computation scheme everywhere.

> HTML uses the entry settings object for a bunch of origin checks

I thing HTML is buggy if it's doing that.  I just looked, and it looks like it
does it for the following (I'm ignoring things like referrers and base URIs and
whatnot, just looking at origins):

1) Canvas tainting bits.  Does this actually match implementations?  Does it
make sense to do it that way?

2) .frameElement, looking at effective script origins.  This is not too
unreasonable, since effective script origins end up needing to match the
effective script origins of everything else you're dealing with, pretty much,
so it doesn't matter too much which settings object you use here.  At least in
browsers that implement security membranes (which of course doesn't match the
HTML spec, but I consider that a bug in the HTML spec).

3)  A check in replaceState which I'm totally unclear on.  It claims to
restrict sandboxed content, but there's nothing to indicate that the entry
settings will be the sandboxed thing!

4)  Location security checks.  That stuff is all broken as written up right
now; see bug 20701.

5)  Origin check in registerProtocolHandler.  Again, it's not clear to me why
using the origin of the entry settings object is the right thing here.  I don't
think it is.

6)  Something in IsSearchProviderInstalled.

7)  createImageBitmap.  This is similar to canvas tainting.  Except ignores
CORS?

8)  For EventSource, setting the origin for CORS purposes to that of the entry
settings object.  That makes no sense to me.

9)  For websocket, checking the scheme of the origin of the entry settings
object, and using its origin in the websocket connection.

10) A sanity check that all origins match in postMessage.  This part is not too
unreasonable.

Note that really the only case in which it matters which exact settings
object's origin you use are document.domain cases (because otherwise the entry
and incumbent settings objects have to match, and both must match the Realm of
the caller, modulo whatever weirdness happens with Location).  So it's no
surprise that this stuff is not exactly well-tested, and probably not that
well-thought-about.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 31 October 2014 07:58:40 UTC