Consider inverting the [SecureContext] model.

[mikewest]

By default, IDL constructs are exposed to both secure and non-secure contexts, subject only to the Exposed attribute. Developers can opt-into stricter checks by adding [SecureContext] to their constructs, which limits exposure to secure contexts. This setup made a lot of sense when we introduced the concept, as secure contexts were rare and most APIs wouldn't want to restrict themselves. Given recent trends, these assumptions no longer hold: secure contexts are plentiful given user browsing habits, and many (most?) new features require secure contexts.

With this in mind, it seems reasonable to me to flip the way we talk about things in IDL around, such that constructs are limited to secure contexts by default, and only those which need to be exposed to non-secure contexts need to annotate themselves.

That is, given the following IDL:

[Exposed=Window]
interface NonSecureThing {
  ...
}

[SecureContext,Exposed=Window]
interface SecureThing {
  ...
}

I'd suggest that we instead ask ourselves to write something like the following with the same meaning:

[UnsafelyExposedToNetworkAttackers, Exposed=Window]
interface NonSecureThing {
  ...
}

[Exposed=Window]
interface SecureThing {
  ...
}

Making this change would involve a lot of churn in specs, which is unfortunate. But it seems to me to be the right direction for the future.

WDYT?

/cc @annevk (also @domenic and @wanderview, who I think are skeptical of this proposal)