Re: [webidl] Add a [SecureContext] operator attribute (#65)

Took a bit of time to spool-up on the terminology and impact here. :)

We would _really_ prefer being able to setup a static backing implementation for the ```[SecureContext]``` operations, so that we can generate the throwing or Promise-resolving backing behavior when we first build the script context for a new browsing context. To enable this, we'd like to have the check be based on the origin of the callee's global object (which can be implemented as a static-check vs. a runtime check). Honestly, I'm not quite sure how callee's origin differs from incumbent's origin? Maybe an example would help :)

In discussing this, however, it occurred to us that any access from a non-secure context to a secure context and vice-versa would go through a security wrapper at the window/document which would deny access so the APIs in the first place. E.g., an http**s** and http URL are always considered different origins, correct? Same-origin policy would not even allow you to get far enough into the destination origin for your proposed security check to ever be executed, right?

---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/65#issuecomment-149347650