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.
On Tuesday, 15 August 2023 at 20:30:06 UTC+1 [email protected] wrote: > 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 > > > On Monday, August 14, 2023 at 8:38:17 AM UTC-7 Chris Harrelson 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? >> >> On Fri, Aug 11, 2023 at 7:45 AM 'Daniel Vogelheim' via blink-dev < >> [email protected]> wrote: >> >>> Hi Alex, >>> >>> On Mon, Aug 7, 2023 at 8:13 PM Alex Russell <[email protected]> >>> 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. >>> >>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Monday, August 7, 2023 at 6:35:16 AM UTC-7 Daniel Vogelheim wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> 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 >>>>> >>>>> >>>>> Specificationhttps://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 componentBlink>SecurityFeature>SanitizerAPI >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ESanitizerAPI> >>>>> >>>>> 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 proposalNone >>>>> >>>>> TAG reviewNone >>>>> >>>>> TAG review statusNot 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?Yes >>>>> >>>>> Flag name on chrome://flagsCurrently none. Would be happy to >>>>> re-implement the chrome://flags flag if it helps. >>>>> >>>>> Finch feature nameSanitizerAPI >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Tracking bughttps://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 >>>>> <https://chromestatus.com/>. >>>>> >>>> -- >>> >> 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 [email protected]. >>> >> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPN-OU7ZxZ-Zu2D0Ni3RDwpDSGmvZyaUt-JQxkUAsO1hTA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. 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.
