early design review: Permissions-Policy: unload

[fergald]

Braw mornin' TAG!

I'm requesting a TAG review of Permissions-Policy: unload.

This is a proposal for a new Permissions-Policy entry that will disable unload handlers. Permissions-Policy is a mechanism for controlling individual page's access to features. This proposal would add a way for a page to opt out of firing unload handlers while allowing exceptions.

• Explainer¹ (minimally containing user needs and example code): https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md
• User research: currently only private feedback from sites that want to use this
• Security and Privacy self-review²: https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#self-review-questionnaire-security-and-privacy
• Primary contacts (and their relationship to the specification):
  • Fergal Daly (fergald), Google - designing/specifying/implementing in Chrome
• Organization/project driving the design: Google (BFCache team)
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5760325231050752

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/w3c/webappsec-permissions-policy/issues/444
• Major unresolved issues with or opposition to this design: https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify fergald rakina domenic

@rakina @domenic

[fergald]

Do you have an ETA for this?

[torgo]

Hi @fergald you've answered !!! to point 9 of the security & privacy questionnaire - it seems evident that this is a "no" considering the context we're in but just double-checking this is the case.

[fergald]

Sorry. I must have meant to come back to that but I've updated it to "No.".

[torgo]

So we're just discussing in our breakout this morning. And @cynthia has given some further detail and how it fits into bfcache. I was a bit confused by this "Some browsers, like Desktop Chrome and Desktop Firefox, have chosen to keep the unload event reliable, so the existence of unload handlers makes a page ineligible for BFCache, hurting performance. In others like Android Chrome & Android Firefox, and WebKit-based browsers (Desktop Safari & all iOS browsers), if the page is eligible for BFCache, the unload handlers will not run, further increasing the unreliability of unload handlers." because it sounds like part of the motivation here is to patch a problem with current implementations? Can you clairfy?

We're having our f2f meeting next week and we will further discuss there and hopefully be able to close this. Thanks for bearing with us!

[fergald]

Unload is inherently unreliable on mobile because if a tab goes into the background, all kinds of things can occur that can result in the document being discarded without unload handlers running. E.g. it's common for the OS to kill a browser background process to reclaim memory, many people are in the habit of swiping apps closed when they are done with them to reduce background memory usage, this does not give the browser app time to correctly unload documents. This is quite different to desktop where the browser process is often alive for days or weeks and has an opportunity to run unload handlers if they exist when shutting down.

Unload is incompatible with BFCache. If a page enters BFCache, we can't run unload as the page enters BFCache because it might come back. If the user never comes back we will eventually evict the entry but we can't run it in the background then because that raises privacy problems. The page that they navigated away from minutes ago is suddenly running JS, maybe grabbing location information or making network requests etc.

The resolution on mobile was that anyone relying on unload was already broken, so it's fine to BFCache a page with unload, we just don't run it. Things get a bit more broken.

The resolution on desktop (for Chrome at least) was that things are still relying on unload and we should not unilaterally break it. Right now, for 16% of history navigations the only reason blocking from entering BFCache is that they have an unload handler in some frame. There are lots more pages blocked by unload+some other reasons, so other browsers could be seeing far higher than 16% that are only blocked by unload. If we were to just ignore it and BFCache anyway, we would be dropping the reliability of unload from something close to 100% down to 84% and even further as we make more and more features compatible with BFCache.

[torgo]

Thanks for the detailed explanation @fergald! I would suggest putting this material into the explainer itself to make it a bit more clear what's going on.

[fergald]

A good chunk of what I wrote above was in the doc already (or in the links) but I made some revisions and additions to the motivation section.

Was there any further outcome from the F2F?

[torgo]

Hi - thanks for that - just coming back to this issue today and it appears there is also some issue with lack of multi-stakeholder support. Has there been any update since the discussion linked from Chrome Status in May on this?

[fergald]

We have private feedback from sites that want to use this. There is also one positive public comment.

We have asked Mozilla for their position.

[fergald]

FYI, request for WebKit position is here https://github.com/WebKit/standards-positions/issues/127 .

[cynthia]

We discussed this today; in particular around the concerns from the other implementors. We'll need some time to digest and think about the usage patterns, and it does raise an architectural question about PP in general that we would like to think about and discuss as a group before providing a full review.

[fergald]

@cynthia could you elaborate on the architectural question? There's already https://github.com/w3c/webappsec-permissions-policy/issues/480 which may be what you're discussing but if not, I'd like to hear what it is.

[cynthia]

Yes, it is related - the discussion is sort of captured here: https://github.com/w3ctag/meetings/blob/gh-pages/2023/telcons/02-13-minutes.md#early-design-review-permissions-policy-unload---cynthia-torgo

But also whether or not PP (as a framework) should have functionality for subdocuments request permission in cases like this. I haven't hashed out my thoughts yet, but this is a different case from disabling an originally permission gated feature, as it is unconditionally available or unavailable (with no way to request for access). (Use case that came to mind was something in a subdocument that would need to synchronize state back upon unload, like a form or editor.)

[fergald]

I'll just add some more context here, unload is a bit of a special case. It's a footgun, there is arguably no correct usage of unload. The recommendation is to never use it. For example, synchronising state in an editor should be done on visibilitychange because on mobile, if you are not the foreground tab of of the foreground app, you can be killed at any time to reclaim memory.

Try to think of any usage of unload, then consider mobile process killing and also the fact that the HTML spec says unload handlers should only run if the page is not entering BFCache (only WebKit actually implements that on desktop, Chrome and Mozilla block BFCache when they find an unload handler, in Chrome's case this is because we believe it's too disruptive to just suddenly stop running unload handlers). If you can come up with a legit use of unload, please let me know.

Even something like 3rd party iframes beaconing data at the end of page life is questionable because on whether the handler runs depends on whether the embedding page is going into BFCache. This will result in data loss that cannot be compensated for because it's is heavily biased The handler will run 100% of the time on some sites and almost 0% on others. We are developing the pending beacon API to fill that need

So this permission policy should not be thought of as a way for pages to give selective access to unload, it's a way for pages to opt out of unload as a footgun of the web platform (similar to syncxhr). There is no perfect way to retract a bad feature but we think that the embedding page should know and care about whether it's safe to disable unload and is in a position to push embedded pages to make it safe if it's not already.

[fergald]

This proposal has shifted to one where we disable unload by default and make it possible to opt-in. There's a lot of overlap with the previous version. I can file a new TAG issue or keep going in this one. Update explainer is here

[torgo]

Let's keep going here. @fergald can you please update the issue with the new link(s) and leave some explanation here about what the change is so that we can re-review?

[fergald]

The link is here. It may have looked very similar to the original.

The diff is

• unload is disabled by default but can be enabled by Permissions-Policy
• it's too dangerous/disruptive to just go straight there, so we would start with a default of enabled and gradually flip the default until 100% of pageloads have unload disabled by default

[torgo]

Hi @fergald thanks for that - I'm noting negative signals from Firefox and Webkit. Has there been any change in those since the change in proposal?

[cynthia]

Re: gradually flipping; I'm a bit unsure how that would work in terms of spec text. Wouldn't that be requiring a level of Chrome-isms in other implementations? I believe other implementations either support something or don't, with not much a gradient in between.

[fergald]

Yes, there's no way to coordinate among browsers. The end state is what we want to standardise on. However the details of how to get there are important.

[torgo]

@fergald has there been any update you can share on this? Where do we currently stand? How can the TAG best help you?

[fergald]

The update is that Chrome has started experimenting with turning off the ability to add unload event handlers.

I think the only way TAG can help is to point out a fatal problem with the end-state where unload no longer exists. If there's some reason the web absolutely requires unload handlers, we would like to know so we can try to figure out what functionality we need to add.

[torgo]

Noting that this proposal seems to have been withdrawn, we're closing this review. @fergald please open up a new review request for the new proposal you mentioned in that comment when appropriate.