This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27203 - Evaluate entry settings object usage
Summary: Evaluate entry settings object usage
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Domenic Denicola
QA Contact: contributor
Whiteboard: blocked on dependencies
Depends on: 27204
  Show dependency treegraph
Reported: 2014-10-31 08:09 UTC by Anne
Modified: 2016-06-15 19:27 UTC (History)
5 users (show)

See Also:


Description Anne 2014-10-31 08:09:51 UTC
From bug 27196 comment 5 by bz:

> 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
> 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.
Comment 1 Ian 'Hixie' Hickson 2014-11-04 00:34:48 UTC
I'm unclear on what you want me to do here.
Comment 2 Anne 2014-11-04 08:50:43 UTC
Per bug 27204 comment 1 we need to check whether these actually use the correct concept.
Comment 3 Ian 'Hixie' Hickson 2014-11-06 00:36:35 UTC
I've checked these multiple times. By definition, anything in the spec is something I've checked; I don't write the spec blindly. :-) Is there someone else who would like to check them also?
Comment 4 Anne 2014-11-06 08:39:39 UTC
From comment 0, #3 and #5 seem potentially problematic.

I was hoping that we could revisit this list once we dealt with bug 27204.
Comment 5 Domenic Denicola 2016-06-15 19:27:53 UTC