Intent to Experiment: Permissions-Policy: unload

132 views
Skip to first unread message

Fergal Daly

unread,
Sep 20, 2022, 2:17:18 AM9/20/22
to blink-dev, bfcache-dev, Ian Clelland, Daisuke Enomoto

Contact emails

fer...@chromium.org

Explainer

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

Specification

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

Summary

This feature allows pages to disable the running of unload event handlers. The goal is to : - allow sites that have removed all unload handlers to ensure they do not accidentally add new ones - allow sites to remove unload handlers when updating the code is infeasible 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).



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: No signal

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



Goals for experimentation

- Validate that this allows sites using it to improve their BFCache hit rate



Reason this experiment is being extended



Ongoing technical constraints



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

Flag name

enable-experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1324111

Launch bug

https://crbug.com/1357927

Estimated milestones

OriginTrial desktop last109
OriginTrial desktop first107
DevTrial on desktop107
OriginTrial Android last109
OriginTrial Android first107
DevTrial on Android107
OriginTrial webView last109
OriginTrial webView first107


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


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Sep 21, 2022, 8:01:47 AM9/21/22
to Fergal Daly, blink-dev, bfcache-dev, Ian Clelland, Daisuke Enomoto
LGTM to experiment 107-109 inclusive.

--
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/CAAozHLkOeqfqZ0PtzUDdowXbBuMp4oYS%3DQ%2BSQCogY%2BkBpGAYXQ%40mail.gmail.com.

Daisuke Enomoto

unread,
Jan 16, 2023, 3:38:24 AM1/16/23
to Yoav Weiss, Fergal Daly, blink-dev, bfcache-dev, Ian Clelland, Daisuke Enomoto
Hi, API owners,

We had requested this Origin Trial to be run for 3 milestones, specifically from 107 to 109. This was previously approved. We sent the original request without realizing the Origin Trial guideline suggesting 6 milestones.

We would like to extend this OT for another 3 milestones or to 112 inclusive by applying the 6 milestone guidelines we originally missed, to give sufficient time for partners to give us feedback. It would be great if you could review our request.

Thanks!
Daisuke


Yoav Weiss

unread,
Jan 16, 2023, 6:04:58 AM1/16/23
to Daisuke Enomoto, Fergal Daly, blink-dev, bfcache-dev, Ian Clelland, Daisuke Enomoto
Since it's already been a while since this intent was approved, can you send an "Intent to extend experimentation" so it'd get caught in our tooling?

Daisuke Enomoto

unread,
Jan 17, 2023, 1:51:29 AM1/17/23
to Yoav Weiss, Fergal Daly, blink-dev, bfcache-dev, Ian Clelland, Daisuke Enomoto
Yes, I'll send a separate email requesting an extension.

Thanks!
Daisuke
Reply all
Reply to author
Forward
0 new messages