LGTM2 In addition to Yoav's comments I'll also add that it makes sense to me if WebKit and Gecko don't want this. They each have a lot more flexibility in how they avoid unload handlers, and WebKit already just doesn't fire them when they don't want to. Chromium's enterprise customer base means we need to take a more careful and measured approach to reducing reliance on unload handlers, and given the positive experience we've heard from partners for this feature in OT, I think we must ship it despite the lack of alignment with other engines.
Ideally we succeed in deprecating unload over the next few years then we can delete this policy. The important thing for long-term Interop risk is that the engines are aligned on wanting to deprecate unload. We just aren't aligned on the most effective path for doing so in our respective environments. On Fri, Jun 30, 2023, 3:51 a.m. Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM1 > > On Fri, Jun 30, 2023 at 9:27 AM 'Fergal Daly' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emailsfer...@chromium.org, kenjibah...@chromium.org >> >> Explainer >> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md >> >> Specificationhttps://github.com/whatwg/html/pull/7915 >> > > IMO, it's fine to approve this based on this PR, even if it hasn't landed > yet, given the browser positions below. > > >> >> >> Design docs >> >> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md >> >> Summary >> >> This feature allows pages to disable the running of unload event >> handlers. The goals are: - allow sites that have removed all unload >> handlers to not regress (i.e. accidentally adding new ones) - allow sites >> to “remove” (skip) unload handlers (e.g. if updating the code is >> infeasible, or if they have nondeterministic chains of third parties and >> would rather not risk the BFCache benefits over unload handlers in third >> party code). Unload event handlers are problematic for various reasons and >> prevent use of BFCache on Desktop (see >> https://web.dev/bfcache/#never-use-the-unload-event). This is the first >> step to deprecating and removing unload handlers. >> >> >> Blink componentBlink>PermissionsAPI >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/738 >> >> TAG review statusPending >> >> Risks >> >> >> Interoperability and Compatibility >> >> 3rd-party frames that rely on unload may not work as expected when >> navigating away. This is solvable by the frame authors by use of >> alternatives to unload and is unlikely to impact users. See detailed >> discussion. >> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code >> >> >> *Gecko*: Negative ( >> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132) >> FF objects to this similar to sync-xhr and document-domain providing a way >> to cause cross-origin interference with script. Explainer addresses this ( >> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code) >> At a recent TPAC meeting with Mozilla people present, no negative feedback >> was received. Request for formal position is here >> https://github.com/mozilla/standards-positions/issues/691 >> >> *WebKit*: Negative ( >> https://github.com/WebKit/standards-positions/issues/127) Concerned that >> embedders gain a way to turn off a code-path in the embedded frame. >> > > I think it's important to continue those discussions with other vendors > and try to eventually bring them on board, but at the same time, I agree > with your position that we need to put users first. > Unload events are causing real performance harm today, and we should at > least give top-level site owners the ability to stop that harm, even if > created by their third-parties. > > I haven't seen in the above discussions any concrete threats or attacks > enabled by this cross-origin interference. And as you say, we already have > similar policies around sync-XHR and document.write. > > >> >> *Web developers*: Positive Private discussions with devs are positive. >> Sites that have made efforts to remove all unload handlers want to use this >> to prevent accidental returns. Also some providers of 3rd-party iframes >> which have content outside of their control (e.g. ad network) want to >> guarantee themselves to be unload-free. >> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1130401722 >> Also >> positive feedback about using this to deny unload as a source of security >> problems. >> https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1222973324 >> >> *Other signals*: TAG review is here but has no feedback on the API >> itself. https://github.com/w3ctag/design-reviews/issues/738 >> >> 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 known >> >> >> Debuggability >> >> When this header is present, attempts to add an unload event handler will >> result in an error on the console (just as would happen for any other >> Permissions Policy violation). >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> DevTrial instructions >> https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/permissions-policy-unload.md >> >> Flag name on chrome://flagsenable-experimental-web-platform-features >> >> Finch feature name >> >> Non-finch justificationNone >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/1324111 >> >> Launch bughttps://crbug.com/1357927 >> >> Estimated milestones >> Shipping on desktop 115 >> OriginTrial desktop last 112 >> OriginTrial desktop first 107 >> DevTrial on desktop 107 >> Shipping on Android 115 >> OriginTrial Android last 112 >> OriginTrial Android first 107 >> DevTrial on Android 107 >> Shipping on WebView 115 >> OriginTrial webView last 112 >> OriginTrial webView first 107 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> https://github.com/whatwg/html/pull/7915 although it's unclear that we >> can ever spec this. >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5760325231050752 >> >> Links to previous Intent discussionsIntent to prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkvhEtVOkvW4iXCbMf5a84ypGjD4arZtpS%3D0Okx6BPDdQ%40mail.gmail.com >> Ready >> for Trial: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/38Dpu-uhwFc >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkOeqfqZ0PtzUDdowXbBuMp4oYS%3DQ%2BSQCogY%2BkBpGAYXQ%40mail.gmail.com >> Intent to Extend Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e69_hiyb60B9h6d88ccuoDavYnqDg89LUkgcG6iozfD8e0w%40mail.gmail.com >> Intent to Ship: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e69_hiyb60B9h6d88ccuoDavYnqDg89LUkgcG6iozfD8e0w%40mail.gmail.com >> >> >> 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/CAAozHLkuNkx7%3DBfiG2wXsu%2BqqoOb-WD6YN4gxJN%2BuTogT%3DmE3A%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkuNkx7%3DBfiG2wXsu%2BqqoOb-WD6YN4gxJN%2BuTogT%3DmE3A%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/CAL5BFfWCDUGeGYy42L7EbG7qyfrc%2BQJ7_mRywphyyAkg-Nv6tA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWCDUGeGYy42L7EbG7qyfrc%2BQJ7_mRywphyyAkg-Nv6tA%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/CAFUtAY9pAije6Udz3xiyz_3LakrCUCbFh8pRR-%2BhUMxwfdzXcg%40mail.gmail.com.
