Intent to Experiment: Permissions-Policy: unload

[Fergal Daly]

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 last	109
OriginTrial desktop first	107
DevTrial on desktop	107

OriginTrial Android last	109
OriginTrial Android first	107
DevTrial on Android	107

OriginTrial webView last	109
OriginTrial webView first	107

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWov9LkezrWa6wV%2BGH9bKAC1_dPYRH7yyUTvjmSS%3Dv84w%40mail.gmail.com.

[Yoav Weiss]

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]

Yes, I'll send a separate email requesting an extension.

Thanks!

Daisuke