Yep, we need the or clause to account for WorkerGlobalScope, thanks for fixing 
that!

For the same/cross origin attribute we'll have to do a quick check of all the 
APIs (I've done one quickly, with notes below). If [SameOrigin] is the most 
common so having an attribute for [AllowCrossOrigin] might be smarter. For 
comparison, the few methods/properties that are cross domain on window we 
represent as [msDoNotCheckDomainSecurity]. I could see us adopting 
[AllowCrossOrigin] instead if it existed. And the new attribute would be 
applicable to both members and to parameters with slightly different semantics 
for each (AllowCrossOrigin on a property or method returning a window, 
generally means both don't check incoming and wrap the result securely, 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. I suspect those would have 
to be upgraded to [AllowCrossOrigin] since there are likely no restrictions 
today. Some test cases here would help out to see how tolerant the various 
browsers are. This is awesome, I love getting rid of our custom WebIDL 
attributes ;-)

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. I 
don't believe there is though. And that doesn't affect this discussion so much 
as it does general improvements to WebIDL and how we decorate APIs in the 
future.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbar...@mit.edu] 
Sent: Monday, June 8, 2015 11:29 AM
To: Justin Rogers
Cc: Ilya Grigorik; Jonas Sicking; public-web-perf@w3.org; Przemysław 
Pietrzkiewicz
Subject: Re: More on workerStart

On 6/8/15 2:14 PM, Justin Rogers wrote:
>      DOMHighResTimeStamp computeWorkerStart([SameOrigin] optional 
> Window timeOriginBasis);

It would need to be:

   optional (Window or WorkerGlobalScope) timeOriginBasis

for the argument, right?

> This is under the assumption that we add [SameOrigin] or similar 
> annotation capabilities to WebIDL

I'd think the [SameOrigin] behavior would just be the default behavior for 
WebIDL.  The other behavior really doesn't make much sense.

> The only thing I could think is if you are using postMessage to funnel all of 
> your time deltas into a single cross origin logging domain.

Yeah, opting in to communicating offset info cross-origin might be nice; I'm 
not sure how best to do that.

-Boris

Reply via email to