Intent to Ship: Permissions-Policy: unload

230 views
Skip to first unread message

Fergal Daly

unread,
Jun 30, 2023, 3:27:58 AM6/30/23
to blink-dev, Daisuke Enomoto

Contact emails

fer...@chromium.org, kenji...@chromium.org

Explainer

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md

Specification

https://github.com/whatwg/html/pull/7915

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 component

Blink>PermissionsAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/738

TAG review status

Pending

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.

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?

Yes

DevTrial instructions

https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/permissions-policy-unload.md

Flag name on chrome://flags

enable-experimental-web-platform-features

Finch feature name



Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1324111

Launch bug

https://crbug.com/1357927

Estimated milestones

Shipping on desktop115
OriginTrial desktop last112
OriginTrial desktop first107
DevTrial on desktop107
Shipping on Android115
OriginTrial Android last112
OriginTrial Android first107
DevTrial on Android107
Shipping on WebView115
OriginTrial webView last112
OriginTrial webView first107


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 discussions

Intent 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.

Yoav Weiss

unread,
Jun 30, 2023, 3:51:19 AM6/30/23
to Fergal Daly, blink-dev, Daisuke Enomoto
LGTM1

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 component

Blink>PermissionsAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/738

TAG review status

Pending

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.
    
--
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/CAAozHLkuNkx7%3DBfiG2wXsu%2BqqoOb-WD6YN4gxJN%2BuTogT%3DmE3A%40mail.gmail.com.

Rick Byers

unread,
Jun 30, 2023, 8:10:55 AM6/30/23
to Yoav Weiss, Fergal Daly, blink-dev, Daisuke Enomoto
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.

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.

Mike Taylor

unread,
Jun 30, 2023, 10:17:29 AM6/30/23
to Rick Byers, Yoav Weiss, Fergal Daly, blink-dev, Daisuke Enomoto

LGTM3

Reply all
Reply to author
Forward
0 new messages