- From: Justin Rogers <justrog@microsoft.com>
- Date: Mon, 8 Jun 2015 18:45:34 +0000
- To: Boris Zbarsky <bzbarsky@mit.edu>
- CC: Ilya Grigorik <igrigorik@google.com>, Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Przemysław Pietrzkiewicz <ppi@google.com>
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:bzbarsky@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
Received on Monday, 8 June 2015 18:46:04 UTC