Re: [whatwg/dom] Declarative Shadow DOM (#831)

Earlier in this thread, @rniwa raised the idea of using an "opt-in" mechanism for declarative shadow DOM; @mfreed7 asked, "Do you have a recommendation for a way to opt-in to declarative shadow dom that doesn’t come in-band with the (dirty) HTML being sanitized?" and @rniwa replied "Not off the top of my head."

I'd like to argue here that the only possible opt-in mechanism would be an HTTP header, but using an HTTP header for this would be a really bad idea. If such an opt-in mechanism existed, it would be a footgun.

The web has only one out-of-band mechanism for expressing security related opt-ins and opt-outs, and that's the HTTP Headers. For example, today in Chrome, you can opt-in to `SharedArrayBuffer` by using the `Cross-Origin-Embedder-Policy` and `Cross-Origin-Resource-Policy` headers (COEP/CORP), opting-in to cross-origin isolation. Other security-related headers include `Content-Security-Policy` (CSP), HTTP `Strict-Transport-Security` (HSTS), `X-Frame-Options`, `Expect-CT`, `X-Content-Type-Options: nosniff`, and `Feature-Policy`.

Headers are the _only_ out-of-band security feature the web has. There's really nothing else, at all. And you'll notice that all of these headers _add restrictions_ to improve security over the default (where the default behavior can't be changed for backwards compatibility reasons).

We do have some headers that add access to powerful features, COEP and CORP, but those work by restricting some features in exchange for access to new features which we believe are provably safe when the legacy features are disabled.

We don't ask developers to prove that their site is safe before they turn on COEP and CORP. We believe that the _default_ is safe (because `SharedArrayBuffer` and other high-resolution timers are disabled), and that websites that use COEP and CORP are also safe.

As a result, all developers have to do when they turn on COEP and CORP is do a functional test of their site's _features_. If you turn on COEP and CORP and your QA team says your website still works, then you're OK to deploy the change.

If there were a `Feature-Policy: declarative-shadow *` header, in order to use it, I'd have to prove to myself that whatever HTML sanitizer I was using was compatible with Declarative Shadow DOM. I'd have to prove that my sanitizer _is safe_ and _remains safe_ in order to opt-in to the feature.

Proving that code can work at all is relatively easy: just use it in the same way a user would. If it works, the test passes, and you're ready to go. Proving that code _is safe against arbitrary hostile inputs_ is much, much harder. In practice, developers would almost certainly use the opt-in to enable declarative shadow DOM without proving that their HTML sanitizers are fully compatible, and get pwned.

For this reason, I recommend against having an opt-in HTTP Header (or any other opt-in mechanism) for this feature. Opting in to tighter security is OK, but opting in to decreased security in order to gain feature access is not.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-716078525