Re: More on workerStart

On 6/8/15 2:45 PM, Justin Rogers wrote:
> For comparison, the few methods/properties that are cross domain on window we represent as [msDoNotCheckDomainSecurity].

Yes, Gecko has something similar.  In spec terms right now, this is all 
defined in prose in the HTML spec, which is actually rather suboptimal.

> (whereas on a parameter it means don't check anything and just store it).
>
> Currently, event constructors and event init methods seem to be the lion's share of things that take a Window for the viewArg.

So that's an interesting discussion.  See 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27128

In particular, MessageEvent is defined in the HTML spec as taking 
WindowProxy, not Window and just stores the object.

It might make some sense to me to just use _that_ as the differentiator: 
a WindowProxy arg is just stored and must not be touched without a 
security check later, while a Window arg gets security-checked and can 
then be used for stuff.

The other semi-interesting case is Location, of course; I don't know 
what the situation is for that one right now and it doesn't have the 
convenient WindowProxy thing... but security checks for Location are 
pretty weird too.  https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 
is relevant here and has been for a while.  :(

> I suspect those would have to be upgraded to [AllowCrossOrigin] since there are likely no restrictions today.

Actually, Gecko will throw a security exception right now if you pass in 
a cross-origin viewArg to an event constructor.

> Note: This was a tiny canvasing, I didn't account for object or any types to see if there would be an "additional" security check needed for those cases.

Object or any would just get stored as-is (storing the WindowProxy). 
Then if you ever try to get a Window out of it later whoever does that 
should security-check imo.

-Boris

Received on Monday, 8 June 2015 20:01:50 UTC