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: Permissions Policy unload w3c/webappsec-permissions-policy#444
• Major unresolved issues with or opposition to this design: Permissions Policy unload w3c/webappsec-permissions-policy#444 (comment)
• 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?

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