Consider restricting to secure contexts

[jeremyroman]

Based on feedback from @annevk.

We could consider promoting the use of TLS (and further limiting the attack surface slightly) by limiting the feature to secure contexts. This would permit use on HTTPS and, if the UA wishes, loopback HTTP and local file: URLs, but not to unsecured HTTP.

See also https://w3c.github.io/webappsec-secure-contexts/

One point raised in favour of this is that it's easier to remove this restriction retroactively than to add it.

[lucasgadani]

Does this means that both the tag would only be available in HTTPS contexts, as well as portal browsing contexts only being able to navigate to HTTPS contexts?

What would happen if the parser encounters a tag from a non-secure context? Would we just default to HTMLUnknownElement in that situation?

[jeremyroman]

Does this means that both the tag would only be available in HTTPS contexts, as well as portal browsing contexts only being able to navigate to HTTPS contexts?

That symmetry seems kinda natural given the existence of adoptPredecessor, yeah. Though would we also want to ban redirects through plaintext HTTP, or simply only commit responses that are potentially trustworthy?

What would happen if the parser encounters a tag from a non-secure context? Would we just default to HTMLUnknownElement in that situation?

It's a fair question. On the Chromium side recently our branching in HTMLPortalElement::Create was actually torn out in favour of a specific "enabled-by-feature-flag" thing, so this would require adding an additional condition in there.

The alternative, which I think I'd prefer, would be to simply refuse to load a BC inside an HTMLPortalElement that's not in a secure context, in a similar way to what happens if you try to load a BC in a nested browsing context.