Intent to Deprecate: Remove "Sanitizer API MVP"

[Daniel Vogelheim]

Contact emails

voge...@chromium.org

Explainer

• Old explainer, API as implemented in "MVP" since M105: https://github.com/WICG/sanitizer-api/blob/e72b56b361a31b722b4e14491a83e2d25943ba58/explainer.md
• New explainer, still in progress, API that we expect to implement eventually: https://github.com/WICG/sanitizer-api/blob/main/explainer.md

Specification

https://github.com/WICG/sanitizer-api

Summary

The Sanitizer API (https://chromestatus.com/feature/5786893650231296) aims to build an easy-to-use, always secure, browser-maintained HTML sanitizer into the platform. It is a cross-browser standardization effort starting in Q2/2020. We shipped an initial version of the Sanitizer API in M105, based on the then-current specification draft. However, the discussion has meanwhile moved on and the proposed API shape has changed substantially. In order to prevent the current API from becoming entrenched we would like to remove the current implementation. We expect to re-implement the Sanitizer API when the proposed specification stabilizes again.

Blink component

Blink>SecurityFeature>SanitizerAPI

Motivation

Since the final version of the standard will look different from our initial implementation, the goal is to prevent an API from becoming entrenched. According to use counters, the Sanitizer API is currently used on 0.000000492 % of page visits.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Sanitizer API is currently used on 0.000000492% of page visits. Since presently no other browser supports this API (in any release version) we expect the compatibility impact to be negligible.

Gecko: Positive (https://mozilla.github.io/standards-positions/#sanitizer-api) (Note that the Firefox position presumably applies to the eventual result of the standards effort, not to our current implementation.)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/86)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Is this feature fully tested by web-platform-tests?

Yes

Flag name on chrome://flags

Currently none. Would be happy to re-implement the chrome://flags flag if it helps.

Finch feature name

SanitizerAPI

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1428276

Estimated milestones

Shipping on desktop

118

Shipping on Android

118

Shipping on WebView

118

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5115076981293056

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Daniel,

Hrm, this isn't how things are supposed to work.

The API OWNERS set a high bar to ship exactly to prevent this sort of bikeshedding after shipping. Is it possible to make compatible additions instead?

Best,

Alex

[Frederik Braun]

Hi,

let me give my 2 cents as someone from Firefox who works closely with Daniel on this. We have received valuable feedback that led to spec changes where exposed functionality, API shape as well as security guarantees are changing. Part of this feedback came a bit later than initially hoped due to parallel developments with declarative shadow DOM and we wanted to make sure that shadow roots are parsed and sanitized correctly. But we have also agreed on different functions as part of this evolution.

I do not think that this situation could be handled with compatibility fixes and I would personally prefer that Blink unships the previous implementation before pages or frameworks start relying on this too much.

Thanks,

Freddy

Am 07.08.23 um 20:13 schrieb Alex Russell:

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5eacc772-6d70-41b0-9ab4-0262c42a9c50n%40chromium.org.

[Daniel Vogelheim]

Hi Alex,

On Mon, Aug 7, 2023 at 8:13 PM Alex Russell <sligh...@chromium.org> wrote:

Hey Daniel,

Hrm, this isn't how things are supposed to work.

The API OWNERS set a high bar to ship exactly to prevent this sort of bikeshedding after shipping. Is it possible to make compatible additions instead?

I agree that this isn't how things are supposed to work, and I certainly didn't plan it this way. The Sanitizer launch in 105 was based on the then-current spec. The feedback we have gotten since is that there are blocking concerns with that API. We worked through them and landed on a different API shape, which other engines now seem committed to. They're unwilling to support the old API.

It would be possible for Blink to add the new APIs in addition to the old, and to retain backwards compatibility. However, given that no other engine is likely to support the old APIs as well, it was recommended to me to not do that. The main argument is the impact on the developer community: Are we helping developers by supporting an API shape that has little current usage and is highly unlikely to see a second implementation?

I'm happy to follow whatever API Owners recommend: What I'm asking for here is to retire the current API before adding the new one. The alternative would be to retain the existing API and implement the new one on top of it. Either way can work.

[Chris Harrelson]

I think it's fine to consider removing the current API given usage is extremely low, and if there is a more plausible path to interoperability via a new version.

Is there consensus on a new API shape yet, or is that an open discussion?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPN-OU7ZxZ-Zu2D0Ni3RDwpDSGmvZyaUt-JQxkUAsO1hTA%40mail.gmail.com.

[Alex Russell]

Sorry for the slow reply; was OOO for a few days.

A lot of this is concerning. It's bad for us to be taking such deprecations on-board when the I2S was executed in good-faith, and arguemnts like those from Freddy are wholly unconvincing. This is a cost to Chromium to accomodate a new API shape, and so the bar to doing so must be very high. That said, Daniel and Chris are both right that removing while use is very low is the right thing to do if this can't possibly live. I've reviewed the issues and both designs, and I'm not convinced that there's a compelling case for the API change in a non-additive way, so we're into waters we should prefer not to swim in.

In light of the above, I propose a compromise: we allow this deprecation, but do not allow the replacement to ship without a new Origin Trial, and we will have a discussion of whether or not this team is allowed to ship this API before other vendors do at a later date. My inclination is to say "no", which is to say, the API OWNERS staked the claim of this group to take risks through our codebase once, and I'm not convinced we should again. If Mozilla is so convinced that this new API shape is heavily superior, let them take the risk of shipping first.

As an alternative, I'd happily greenlight an OT for compatible additions to the existing API in lieu of this deprecation.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Luke]

Just to chime in here. If there's a chance this API is going to be removed or even heavily changed its potentially worth making an effort to take down any documentation regarding it to try to prevent any chance of its usage going up. For example the mdn page on it seems an easy one to remove. Likewise the web.dev article. This may not be as important if the usage is far below any thresholds.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Thomas Steiner]

Adding in Jack as the author of the mentioned article at https://web.dev/sanitizer/. It might be worthwhile to add a big red warning aside. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9541b09f-1873-4f84-a5dd-ce284a2ebdean%40chromium.org.

[Daniel Vogelheim]

Hi Chris,

On Mon, Aug 14, 2023 at 5:38 PM Chris Harrelson <chri...@chromium.org> wrote:

I think it's fine to consider removing the current API given usage is extremely low, and if there is a more plausible path to interoperability via a new version.

Is there consensus on a new API shape yet, or is that an open discussion?

It's in active discussion. The new design is being circulated to a wider audience, including the HTML WG (1), where this is meant to land eventually. Every PR that defines the new API shape (1, 2) has been reviewed by engineers from other browser engines. We are certainly trying to get consensus here. That said, I can't speak for other people or projects.

Daniel

[Daniel Vogelheim]

Hi Luke & Thomas,

On Wed, Aug 16, 2023 at 12:49 PM Thomas Steiner <to...@google.com> wrote:

Adding in Jack as the author of the mentioned article at https://web.dev/sanitizer/. It might be worthwhile to add a big red warning aside. 

On Tue, Aug 15, 2023, 23:37 Luke <lukewa...@gmail.com> wrote:

Just to chime in here. If there's a chance this API is going to be removed or even heavily changed its potentially worth making an effort to take down any documentation regarding it to try to prevent any chance of its usage going up. For example the mdn page on it seems an easy one to remove. Likewise the web.dev article. This may not be as important if the usage is far below any thresholds.

Yes, noted and agreed. Adjusting or even removing the docs has come up before, and I hesitated to act on it because we didn't yet have clarity on how to proceed with the Sanitizer API. The reason for writing this intent-to-deprecate is to get agreement on how to proceed, and to decide whether we'll keep supporting the current API in the future or not. If it's okay with you, I'd like to let this discussion run its course, and then adjust the docs depending on how api owners have decided here.

[Chris Harrelson]

LGTM1 to remove in favor of a revised, interoperable AIP in the future.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMrdkH5Br_useiWyt3b8gXVWkzYi9tdL2DSJ9MTwefTjA%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bxEMv20aYBqJoquxdty_2_-6EnszXipt1CP6MN7LqWQ%40mail.gmail.com.

[Rick Byers]

Note that our compat principles say "Generally we avoid breaking any use cases which cannot be shown to have a reasonable alternate implementation". While 0.000000492% is tiny, it's still non-zero. Is it possible that there's some real-world site benefiting from this API? I suppose the fallback of a JS library isn't that much worse, so perhaps we're OK from a "reasonable alternate implementation" perspective. 

I also want to get to an interoperable implementation quickly and am more supportive than Alex is of the idea that API shapes sometimes need to change to get to consensus. Our compat principles also say "Sometimes Blink chooses explicitly to ship despite higher interop risk, and we accept responsibility for that risk by being more willing to take on compat risk in the future if the consensus of the web platform community is that the API should change.". 

But, like Alex, I also don't like the precedent of unshipping an imperfect API while the replacement is still under design debate and also not shipped in any other engine. Typically the above principle is used to apply after some other engine has shipped an API they feel is better, and we move to it in the name of interop. How quickly do we think we could ship the new API and Frederik, do you have a timeline for when you think Firefox might be able to ship it too? To what extent would it increase the engineering costs for your team Daniel to have both forms shipping simultaneously vs. removing the old one prior to shipping the new one?

Is this the right graph for the Sanitizer API UseCounter? Other than a temporary bump (one popular site perhaps?) it doesn't seem to be growing too quickly despite being in Chrome for a year. If we're actually on a near-term path to consensus and multi-engine support, would a couple more months of the old API existing really add much risk? If usage is non-zero (regardless how small) I always think it's a more defensible position with web developers to say we're removing something because a better alternative has shipped in Chrome for at least one milestone (even if "better" is mostly limited to "likely to also have support in Firefox"). 

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVNC%2BqEMqMQ1UofPsN23_34y9kEc8MoZtJXLG_rQib%3D3g%40mail.gmail.com.

[Jack J]

> Adding in Jack as the author of the mentioned article at https://web.dev/sanitizer/. It might be worthwhile to add a big red warning aside. 

Yes, It's easy for me to add red warning to article "do not use". But we need more concrete details for developer.

Is this deprecation will have Deprecation Trials ? It would provide detailed insight into the actual usage of the API in the real world.

It also provide transition period for API user, and once problems are found that cannot be ignored, the plan itself will need to be changed.

If deprecation trial will happen, we'd need to write one more article about it like below

"Breaking change for Sanitizer API and what you need to do"

- what happening on current API

- why it's deprecated

- how / where to transition

- OT plan schedule

- when the new API coming

- etc

Old article will have link to New article in red warning. Only a link to this I2D would not be sufficient.

Jack

[Alex Russell]

Hey all,

We had a long conversation about this in today's API OWNERS meeting, and per my previous note, I'm going to LGTM3 this with conditions because:

• Usage is low, but growing
• The spec changes have been merged into HTML, reducing risk for moving to the new API somewhat
• While we could require compatible additions only, and I think that's the better path, that's a policy question for Chris Wilson or Jeff Yasskin (cc'd) as I'm not your Standards TL

On conditions, there is still a diversity of views around how to proceed. I'm not inclinded to allow the new spelling of this feature to ship without significantly less risk than last time, and that may mean that we may ask you put the new design into OT until other vendors' implementations hit stable (assumign you'd like to make it simultaneously available as other vendors ship). 

Obviously, I dislike this as it hands the pen to vendors who weren't willing to engage in the design early enough to prevent this sort of bikeshedding in the first place. You'll need to be prepared for a longer dicussion about how to proceed at I2E/I2S time for the replacement. For continuity's sake, I'd also encourage y'all to get an OT for the new design into place ASAP so that sites that depended on the old design can migrate while we sort out the ship plan in conversation.

Best,

Alex

[Elijah Grey]

Hey all,

Note: If future versions of this API re-use the Element.prototype.setHTML method in new ways, there may be potential for breakage. Transcend ships a popular client-side firewall tool called airgap.js that regulates (wraps) setHTML. We don't plan to unship this integration soon and even if we did, our customers choose when to upgrade their airgap.js SDK version. We regulate setHTML as it is a unique network sink by itself, and thus is in need of our network regulation controls.

Eli

This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

[Elijah Grey]

Ignore that confidentiality notice if it came from my client.

[Daniel Vogelheim]

On Wed, Nov 1, 2023 at 2:41 AM Elijah Grey <eli...@transcend.io> wrote:

Hey all,

Note: If future versions of this API re-use the Element.prototype.setHTML method in new ways, there may be potential for breakage. Transcend ships a popular client-side firewall tool called airgap.js that regulates (wraps) setHTML. We don't plan to unship this integration soon and even if we did, our customers choose when to upgrade their airgap.js SDK version. We regulate setHTML as it is a unique network sink by itself, and thus is in need of our network regulation controls.

Thanks for the note. I expect the future setHTML to follow the current Sanitizer explainer, and to be quite similar to the one we now remove. While I don't fully understand your use case, I suspect you can treat them largely the same. That said, I understand there's a risk to this.