Rationale for requring a secure context

[purplesyringa]

As I understand it, Sanitizer API does not provide any more features than any other pure-javascript sanitizing library cannot provide. Please correct me if I am wrong on this point.

Why is it marked SecureContext then? The only mention of the attribute I see is a random comment on a PR without any explanation and a single sentence in the security questionnaire which almost literally says "Sanitizer API is safe because you can't use it on HTTP domains" which sounds like nonsense to me.

[Sora2455]

Google and Mozilla have a "require secure contexts by default for new features" policy, to encourage more sites to adopt HTTPS. (https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features, https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/).

In addition, if your site is not served over HTTPS, then a MITM attack can alter, remove, and inject scripts onto your page and render the protection of the Sanitizer API completely meaningless.

[purplesyringa]

Google and Mozilla have a "require secure contexts by default for new features" policy, to encourage more sites to adopt HTTPS.

First, there are browsers other than Chrome and Firefox. Keep your corporate policies out of web standards. Second, your links contradict your statement. Google doesn't say "all new features", it says "all dangerous new features". Mozilla does not directly say "all new features", it says "some new features, dangerous features first".

There's no point in requiring every single new feature to require HTTPS. Camera and microphone access may be insecure in the case of MiTM--it's meaningful to require HTTPS in this case, right. Sanitizing HTML? Not so much.

In addition, if your site is not served over HTTPS, then a MITM attack can alter, remove, and inject scripts onto your page and render the protection of the Sanitizer API completely meaningless.

If you are MiTM'ed, you're already pretty much screwed, whether you are using Sanitizer API, a JS sanitizer library, or neither. Saying "MiTM can render Sanitizer API meaningless" is no different from "MiTM can render JS sanitizing meaningless" or "MiTM can remove CSP headers and embed a malicious script".

Believe it or not, there are valid uses for HTTP without TLS, e.g. on LANs. Don't impose nonsense artificial limitations.

[Sora2455]

I am not a Mozilla/Google employee, but a web developer who was trying to answer your question based on the policies I linked and discussions I have seen in repositories for other features. I can see that my attempt at helping was entirely unappreciated, and won't try to help you in the future.

[mozfreddyb]

Please keep the tone in this conversation polite and in accordance to the W3C Code of Ethics and Professional Conduct. I will lock this issue if my warning has no effect.

To the actual point:
Other new web security features like Trusted Types also require a Secure Context. I consider this in alignment with our commitment to a secure-by-default HTTPS web platform.
We may revisit things in light of new facts, but I don't expect things to change.

[koto]

Small correction: Trusted Types don't require Secure Context

[mozfreddyb]

Oh, I missed that. Thanks.

[purplesyringa]

I can see that my attempt at helping was entirely unappreciated, and won't try to help you in the future.

I am sorry if it sounded that way. I did not intend to offend you and I am shocked you felt so. I am not arguing with you in particular because of your views or whatever--the 'you' in my post stands for 'you all', not 'thou'. I am arguing with the standards and the status quo because I think it is wrong.

I do not want to sound rude, but I am tired of people dodging genuine arguments in good faith by appealing to wording. I am not a native speaker, you cannot expect me to convey the exact right tone.

Other new web security features like Trusted Types also require a Secure Context. Small correction: Trusted Types don't require Secure Context

I am reading the linked issue and I see similar arguments repeated over there too, and they didn't get any traction.

The only W3C statement I can find is here. It says that maybe some of the privileged features will be investigated and disabled for HTTP domains. It does not say anything about disabling all new features.

Chromium's statement even directly opposes that:

The Chrome Security team and I propose that, for new and particularly powerful web platform features, browser vendors tend to prefer to make the the feature available only to secure origins by default. [...] “Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category.

However, the Mozilla discussion says that Mozilla's goal was about disabling all new features.

So, why does this 'innocent' feature require a security context, even when both the Chromium and the W3C statements indicate that the preference doesn't apply in this case? Does Mozilla decide for everyone?

Does the W3C itself officially support the position of "we do not add any new features for HTTP-only websites"? Because it does by the looks of it, and it would be very appreciated if this statement was published somewhere on the W3C website.

[dveditz]

Does Mozilla decide for everyone?

One of the editors works for Mozilla and it's not unusual for draft specs to reflect the biases of its authors -- that's one reason affiliations are clearly marked on specs. This is an 'Incubation' community group proposal so there's plenty of time for feedback to see if that reflects the general consensus or is, indeed, a one-company view. This spec has a long way to go to become "official": first it needs to be formally adopted by a Working Group (Web Application Security WG is interested) and then it must go through several formal "Call for Comments" periods at different stages.

All of the discussions you linked to—Mozilla's, Chrome's, TAG's—were from 2015-ish (don't be fooled by the date on the draft TAG document: you can check the commits and see it's essentially unchanged from the published 2015 version). At that time TLS was used on barely more than a third of page views and things looked dire. Things are looking much better now: https://letsencrypt.org/stats/#percent-pageloads

Does the W3C itself officially support the position of "we do not add any new features for HTTP-only websites"? Because it does by the looks of it

What is the "W3C itself"? The W3C is its members, and their opinion is reflected in the specs produced by various Working Groups that reach Recommendation status (voted on by all members). I believe the CSS working group has explicitly said they were not going to restrict new CSS directives to HTTPS only, because it would be confusing to have stylesheets work differently depending on transport. The JavaScript standards group (not part of W3C) has made the same determination. (FWIW: Mozilla members of both those groups agree that's appropriate.)

On the other hand, many other new web features have explicitly limited themselves to secure transport. As the spec progresses it's fair to discuss whether this feature is more like a basic part of the DOM API (like the .innerHTML it aims to help secure, for example) or a security-focused tool that gives a false sense of security when used in an insecure context? By the latter I mean, choosing to use sanitizer API indicates someone cares about the security of their site, so maybe having the API be missing would offer a helpful clue that there's not much point to sanitize the input when the page contents themselves could already be compromised.

it would be very appreciated if this statement was published somewhere on the W3C website.

true! But for now all we've got is a seven-year-old TAG guideline (plus the TAG's more recent feedback on individual spec proposals).

[dveditz]

If we're taking votes, my personal opinion is that the Sanitizer API (and especially the .html() method it includes) is more like the existing DOM apis it secures and less a "powerful feature" that needs to be restricted. Disclaimer: I work for Mozilla, but we don't all think alike.

[mozfreddyb]

The spec editors have received feedback from sites that need to support HTTP. Those are indeed concerned about Sanitizer adoption when it is not always available. I'll bring this up again at Mozilla, but it will take some times.

[otherdaniel]

I'd like to second the "more like existing features" view.

My main concern is existing sites that use a home-grown sanitizer and might like to upgrade. For those, the secure context restriction creates a dependency to migrate their site first. I've come across one such case already, where the non-secure usage was in their testing environment. Using Sanitizer API would then require them to upgrade their testing envirnoment first, or to loose testability. The (predictable) outcome was to not consider the Sanitizer (for now).

That said, I do acknowledge that our (Chromium) policy refers to any new feature, but leaves some wiggle room for the non-powerful ones. I prefer to allow non-secure origin usage, but am happy to go with the majority.

[mozfreddyb]

We have discussed this again internally at Mozilla. With the upcoming API shape #193 being integrated into parsing, we at Mozilla agree that it would be best if the functionality was available in secure and insecure contexts.

[mozfreddyb]

Fixed.