Add [InsecureContext]

[ddorwin]

To make it clear which (new) APIs are available on insecure contexts and encourage spec authors to make a conscious decision, I propose adding [InsecureContext] as a peer to [SecureContext].

Such an attribute would also enable tools, such as Bikeshed and IDL compilers, to ensure that one or the other has been specified.

[mikewest]

I like the idea of making the choice explicit!

That said, since this is a binary option, it might make more sense to treat what you've called "InsecureContext" as a variant of the existing attribute (e.g. [SecureContext=Nope]). That also makes secureness marginally simpler to type. :)

[tobie]

See #420 (comment).

[annevk]

If we actually think we can manage to do this I'd suggest we flip the default instead as the plan of action seems to be to make most things restricted to secure contexts. That way if you don't think about it it's fine, as you'll be doing the right thing. And if you do think about it and make the wrong choice, it's more easily spotted.

[annevk]

I suspect we want both after all, since sometimes the majority of an interface will be insecure and so having insecure as the default makes sense until it becomes time to flip. Unless it seems reasonable that all existing members get annotated with [LegacyInsecureContext] when you need to add a "secure" one.

[annevk]

Let's duplicate this into #876.