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 <lukewarlow...@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. > > On Tuesday, 15 August 2023 at 20:30:06 UTC+1 sligh...@chromium.org 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 < >>> blin...@chromium.org> wrote: >>> >>>> 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. >>>> >>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Monday, August 7, 2023 at 6:35:16 AM UTC-7 Daniel Vogelheim wrote: >>>>> >>>>>> Contact emailsvoge...@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 >>>>>> >>>>>> >>>>>> 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 blink-dev+unsubscr...@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 >>>> <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 blink-dev+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9541b09f-1873-4f84-a5dd-ce284a2ebdean%40chromium.org?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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3DFt0ETfstY66vRCPYMObhUrSt8psS_m16wXoau%2B5%3DYRQ%40mail.gmail.com.
