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

I believe I'm on the same page now--yes, incumbent settings object seems appropriate for that scenario. And yes, checking incumbent script context is non-trivial for us and involves a stack walk :( So, no, I'm not a fan. :)

This may not be the right place, but I want to pop-up a level to the principle of the problem (perhaps we can take this offline if you wish). Considering you cite Netflix's workaround in the doc as a general basis for needing slightly stronger protection than simply same-origin isolation, and in section 5.1 you talk about incomplete isolation which is broken by the new window scenario--then incumbent settings object will work against you in that case--and you probably already realize this. (The secure context HTTPS top-level window will call back through the opener property to the HTTPS-but-insecure-context iframe, and be able to execute it's secure context APIs.) 

What is it that makes the new window popup that much more of a deterrent than the simple iframe case cited for Netflix? I'll be Netflix for a second under the new rules of the game: now, I popup a new window when the user clicks the play button (or selects a movie) so that I work around the pop-up blocker, I manipulate focus to that the window popup is behind the main window (if it wasn't opened in a new tab), and I carry out my secure operation there. If it's a short term crypto-related use, I can have the window closed before users even know what happened. Otherwise, I can put it in the background--but generally, I'm implying that using a new window vs. an iframe is inherently (from a security standpoint) no different. Why then is it OK to have this loophole?

I apologize if you've been though this discussion before; I'm just concerned about the implementation burden this will have and want to be sure all angles have been thoroughly considered.

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