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

@bzbarsky: Could you help me figure out whether or not the current patch is sane?

@annevk: I suspect we can only tag new APIs with this flag, or APIs that were new at a time when developers were consistently checking whether they existed (e.g. ServiceWorker). You're right that that might give us more of an opportunity to guard against `document.domain`, but at the same time the usage numbers are fairly hopeless: https://www.chromestatus.com/metrics/feature/timeline/popularity/739 shows ~5% of page views. Some chunk of that is Facebook, some other chunk of it is cargo-culted scripts that aren't actually used, but I'm sure some chunk is used and isn't going away. *shrug* I'm not sure that fight is the right place to spend our time.

@esprehn: The argument that @bifurcation, @martinthomson, @travisleithead, and others have advanced here and elsewhere is that secure context restrictions ought to fall into developer's feature-detection-handling paths, and not into their error-handling paths. That is, developers are already writing feature-detection code to determine if they can do the thing they'd like to do: `if ('serviceWorker' in navigator) {` and the like. Removing the API from the surface area we offer developers would be an honest depiction of the feature's availability in a context.

The fact that the APIs might change behavior from context to context is a given; the question is how we help developers understand those changes. *shrug* The Mozilla and IE folks who have weighed in seem to have preferred this approach, and I don't feel strongly enough about throwing to find it worthwhile pushing back against arguments that just don't match my preference (but seem otherwise sane). :)

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