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.
