[Sanitizer] Should JS URL attribute removal be part of the configuration?

[noamr]

What is the issue with the HTML Standard?

Currently, removal of JS URL attributes is done only in setHTML etc. ("safe" mode). See the last argument in the inner sanitize steps.

However, since this process is not part of the sanitizer config, it wouldn't happen when calling setHTMLUnsafe on a sanitizer that had unsafe options removed using removeUnsafe.

This makes this option somewhat inconsistent as it's a "configuration outside the configuration", and can create confusion as it means that removeUnsafe doesn't remove all the unsafe options.

Suggesting that instead of having this as an out-of-band boolean, it becomes a part of the configuration

[noamr]

@evilpie @otherdaniel @annevk @mozfreddyb

[annevk]

I guess I could see us adding another boolean, but this one is rather murky. However, it is a fair point that removeUnsafe() not providing parity will be a source of confusion and annoyance.

Do we have to address this now or could we conceivably add this later if it becomes a pain point?

[noamr]

I guess I could see us adding another boolean, but this one is rather murky.

Maybe it can be something a bit more encompassing like removeUnsafeValues that effectively maps to safe vs. unsfae and cannot become false when calling the "safe" variants.

Do we have to address this now or could we conceivably add this later if it becomes a pain point?

It might bring some web compat issues later to make removeUnsafe more strict in the future. But probably not huge ones.

[evilpie]

At least from my point of view there was always a desire to have some way of sanitizing any attribute value in a hypothetical v2. Moving the JavaScript protocol handling to be implemented in those terms would be a nice proof of concept.

[mozfreddyb]

Totally agree that removeUnsafe() being incomplete for setHTMLUnsafe() can be a bit of a footgun. Maybe that's worth at least documenting or pointing out otherwise such that people aren't bit by this too hard.

But as a better solution, I agree it would be good to have a more specific attribute-value API to ensure we can fit all use cases.

[noamr]

Maybe a non-murky boolean for this can be javascriptURLs. It's clear what it does and it's consistend with dataAttributes and comments.