Dan: confused about motivation.. some browsers make it reliable.. is this a point of contention? Cache people vs browser people? Effectively a new entry to fight back against browsers that want to do a certain thing? Or misundersatnding?

Sangwhan: more like if a website sets this it's a guarantee that you can use BFCache. Without having this permission policy opt in the browser cannot safely enable BFCache is what this is tryint to solve. It's a bit indirect, might be unclear.

Dan: the page will set this policy?

Sangwhan: correct

Dan: "hey, I want to be BFCacheable"

Sangwhan: yes. This is one of the many flags that will guarantee you get BFCache

Dan: why do there have to be many flags? Not one flag?

Sangwhan: there are multiple problems when it comes to enabling BFCache for the entire web. a lot of theAPs we have minted in the past do not take into consideration in a document that is not fully active it is unclear what to do about script context frozen holding onto a resource, a hardware device or a file handle, the document is not technically fully deactivated. it can be partially holding on to the file handle for example, it's basically a lock on that file. you can't take a fully deactive.. you cannot use the BFCache. A lot of the FUGU APIs have this problem. That's why it's multiple flags. The condition is it must not use a certain set of APIs, not have an unload handler, and optimally have this opt in to be able to trigger bfcache. It's damage control. The team behind bfcache want us to consider this. They have some design principles they're trying to pull goether. A lot of the APIs are being minted and reviewed without consideration of allowing documents to be not fully active. So they're trying to add extra mechanisms so documents that state that they're okay with not being fully active can explicitly state it. They want to talk to us if we have time during the f2f.

Dan: sounds like a good idea.

Sangwhan: they're in Tokyo so it'll be early for us but can arrange that.

Dan: do we hold off to f2f?

Sangwhan: yes

Dan: not sure what's behind the statement about "browsers have chosen"... doesn't seem very holistic.

Sangwhan: that's a different problem, this is opting out of on unload. Ohh.. maybe could be problematic. Talk about this next week. Unload handler problems has been long standing on all browsers. Architectural issues. Multiple weird mitigations like html ping attribute.. ?? api that is also very limited.. so offer a feature to disable it.. but architectural discussion is is there any way to fix this?

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](https://groups.google.com/a/mozilla.org/g/dev-platform/c/3pQRLPZnQgQ/m/dsA1w4iiAwAJ), 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?

Sangwhan: we were upset about their "!!!" in security and privacy..

Dan: they removed them

Sangwhan: I'm okay with this proposal

• Breakout Rollup
• Issue Triage

Dan: status is - I asked for what they wrote into the issue to be reflected in the explainer... they've made some revision. Checking multistakeholder.. Negative signal from firefox.. ambiguous argument in May. [replies]

Sangwhan: I don't see a down-side... The permission policy is a choice of the origin... to disable unknown handlers... They should be aware of the breakages that can happehn when load handlers don't kick in. If you have foreign content that ... an origin can take in foreign scripts and iframes -- if that taps into the unload handler and tries to block user from navigating away from the page then it's a bad thing. Not an origin choice to make... One antipattern - a site hooks into unload to do weird stuff - shoot off a beacon or try to block it.

Dan: Malicious site?

Sangwhan: this changes nothing for those cases - but if you have a modal ad - as long as the ad network script is running on the browser context... giving the origin control over that is probably not a bad thing. This gives the origin the option to block the unload handlers...

Sangwhan: so personally LGTM. Also makes bfcache less painful. When you have an unload handler you can't bfcache the page... so in that sense this is good... If you have the permission policy in then the unload handler will be a no-op.

Dan: multi-stakeholder... in Sept Mozilla was asked for position, still no information

Sangwhan: Mozilla standards positions in the abyss.. new person working on that.. have suggested a connection

Dan: I'm worried from multi-stakeholder pov. Satisified with concerns?

Sangwhan: there's no harmful signal - but for cases where browser vendors are not responding, should we be concerned about it?

Amy: well concern is that if there's no implementer interest and it only gets implemented in one browser then what are the risks of fragmentation...

Sanwhan: e.g. mozilla have been vocal about if something is actively bad. On the fence about pushing due to Mozilla staffing issues. Chromium have contributed tests to Mozilla that have landed.

Dan: leaves note

bumped to plenary

Dan: we have new information about webkit position..

Sangwhan: I see pushback about the layering, not the feature itself

Dan: Mozilla position discussion also notes "worryisome" concerns.

Dan: people in this issue are posting without name or affiliation - in this case from Mozilla - assuming that people know who they are - which is a problem across the web community. I wish people would put their name and affiliation in their githib profile when they are acting on behalf of their employer.

Sangwhan: I'm okay with this. There are concerns, it's not mutual in a sense of an iframe that is legitimate and the parent is bad. Permission policy enabled and the nested browsing context, the iframe, doesn't get to have an unload handler. That means that if the parent decides to nix it unload handler will never kick in and if for some particular case the nested context requires to saves state it wouldn't have a change to do that, so it would break. The concern is that there's no mechanism for the nested context to say no I don't want that please let me have my unload handlers

Dan: is there a mechanism for the nested context to know its unload handler won't kick in?

Sangwhan: no, not until we unload. You would still have a slot in the document level as a function.. if you define a handler for it it will still register. If you look it up the function will be there, it will just do nothing.

Dan: is there a chance for the child document to do something to gracefully fail at that point? Can it tell my unload handler didn't run?

Sanwhan: probably not

Dan: I think this is problematic. Just in terms of.. if you've got a child doc that's expecting some kind of behaviour and we're encouraging some kind of fail gracefully approach and you can't feature detect whether something has been disabled by the top level context that kind of defeats that feature. Or it's only used by "evil" child docs so we don't care?

Sangwhan: most cases are to prevent users from navigating away. There are legimitate cases. I don't know how permission policy propagates down and if it's available to the nested context - I'll take a look at that - but if that's not available..

Dan: we could leave a comment about that. Feels like the nested context should be aware that this is not going to work. I don't think tht will create an unfair advantage for the nested context. If anything it will discourage the nested context from using the pattern of doing something to distract the user on unload?

Sangwhan: yes and no.. For malicious cases they would probably find alternative ways to work around. So whether or not exposing that information is useful remains to be answered. Legitmiate cases, fi we don't provide a way for the nested context to beg for permission there's no point in providing this information

Amy: surely the middle ground is just so they know to gracefully fail ... still seems useful to me.

Sangwhan: having context so graceful failure is possible is useful. If you're a text editor... timer that kicks in... if you don't have an unload handler to hint the user they need to press the "send" button then this could have bad consequences. Concerns might be less of an issue than Moz and Apple are saying.

Amy: an opportunity for that form to present a warning at the top of that frame...

Sangwhan: most of the time the parent is goign to be aware of what is embedded and isn't going to block it with permission policy

Amy: if there's composed web pages... arbitrary services... wouldn't rule that out

Sangwhan: "ad doesn't let the user navigate away from the ad" use cases -- malicious patterns used aggressively. I don't think this will solve all the problems but will solve that problem. Corner case is also valid... [will leave a comment]

bumped

Fergal: main concern raised - stops the inner page from executing code that may be imported... I need to update .. in the last few days I've written a change that flips to to default off and you can opt back in to unload working again. Could be quite disruptive... The main concern raised there .. there may be sites that depend on the unload handler executing in subframes.. logic that should fire when those subframes are destroyed. We're adding code to see how often that happens... hopefully it will be small and we can document that. then we would like to gradually roll it out so by the end of the year unload handlers are off by default..

Tess: and some kind of Telemetry of opting back in.

Fergal: spec: you run unload handlers unless the page goes into bfcache... So firefox, chrome, safari on mobile all skip unload if page goes into bfcache... we don't see an easy way to transtiion 99% we will load the unload handler to 60%... it's unpredictable ... something in the subframe would block bfcache...

Dan: end user experience of failure mode?

Fergal: all the documentation pushes you away from using unload handlers anyway... Most unload handlers don't do anything visible for the end user.. people are sending back telemetry... it's not users seeing an impoact from this. It's sites, ad networks... we've pushed the major vendors away from unload... 10 t 20 % pages on desktop that ...

Sangwhan: any common libraries?

Fergal: we worked with facebook.. we talked to a lot of the third party libraries... One answer is to make it unreliable... but getting there from where we are is not pleasant.. if we're gonna end up breaking things let's break them more visibly so people who do care will get a signal that the thing is broken... Where unload is now opt in.

Tess: in webkit we did make this change and we didn't have any blowback...

Fergal: it can do weird things like bias your data in weird ways...

... tried to find out from vendors if they noticed any skew... in data... it should give them more accurate data. don't have any responses yet..

Dan: they have indicated a change - i've asked them to update this review and let's keep going in this one rather than opening a new review.

Max: This proposal permission policy to disable upload handler... Long history of discussion... Recent comment 3 weeeks ago... They've provided a link... also said they highlighted the differences:

• 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

Dan: both Firefox and Safari have come back negative on it according to Chromestatus. Asking about multi-stakeholder if it's shifted.

Dan: fergal's latest comment

Sangwhan: fergal wants to have a consistent developer story with bfcache. he's trying to find common ground and not getting support... As a developer right now you have every motivation to avoid being bfcached because of the inconsistencies in implementations. Similarly if we give developers control over bfcache - developers might choose not to cache...

Dan: can we intervene to bring people together? ask for consistency. We want developers to use bfcache, it is good to have consistent behaviour from a developer perspective. What can we do to encourage that?

Sangwhan: reinforcing that it's good for the web to have consistency

Dan: there's not controversy about whether bfcache should exist, just the behaviour. For functionality where there's consensus that it should exist, it should behave similarly. An example is private browsing modes.

Sangwhan: bfcache is more impactful when it's user facing, and inconsistencies do more harm. Web application is half broken or reloads when you switch to a tab. Affects users a lot - should be a priority for the web.

Dan: what about adding material to the bfcache principle to reinforce this?

Sangwhan: that's easier than a finding

Yves: interesting discussion in mozilla standards proposal discussion about reliability : https://github.com/mozilla/standards-positions/issues/691 - the issue is about subframe navigation.

Sangwhan: [re the previous discussion at the f2f] I can get started on a design principle on this...

Sangwhan: I think the [multi-stakeholder situation is improving] - mozilla although they only have partial support for permission policy...

bumped 2 weeks

Sanghwan: to follow up with Fergal

dan asks for an update from requester

Dan: reached out to Martin async.

Matthew: a lot of articulated reasons...

we agree to close Permission Policy Unload