Hi Rick, Thank you for your review and feedback. On the enterprise engagement, we have informed them about these upcoming planned changes back in March and have continued the engagement with them to ensure enterprise visibility <https://www.chromium.org/developers/enterprise-changes/#1-give-enterprises-visibility>. Specifically, the planned change was mentioned in the enterprise release note for M113 <https://support.google.com/chrome/a/answer/10314655?sjid=2890549262726159237-AP#112&zippy=%2Cchrome> , M114 <https://support.google.com/chrome/a/answer/7679408?sjid=2890549262726159237-AP#skpUnload114> and M115 (in draft). This is all on top of the launch process and the group policy availability.
That said, I will double check with them to ensure they have the correct understanding of our plan and get back to this thread. Daisuke On Thu, Jun 29, 2023 at 1:16 AM Rick Byers <rby...@chromium.org> wrote: > Hi Fergal, > Thanks for pushing through this contentious and challenging deprecation. > We discussed this in the API owners meeting today and were worried that > this plan seemed likely to be seriously problematic for enterprises (policy > opt-out is helpful, but far from a silver bullet unfortunately). To what > extent have you engaged with them and worked to follow the enterprise > breaking change policy > <https://www.chromium.org/developers/enterprise-changes/>? Our hunch is > that at 1% or 5% we'd get escalations forcing us to abandon this plan. Of > course, if the enterprise team is OK with it, we could always try anyway > and see if our hunch is right. It's possible I'm over-indexing on past > experiences like deprecating sync XHR in unload handlers > <https://groups.google.com/a/chromium.org/g/blink-dev/c/LnqwTCiT9Gs/m/tO0IBO4PAwAJ> > and that the enterprise world is different now, but I doubt it :-). > > In general Yoav and I disagree with the WebKit and Gecko feedback here and > suspect that your original PP default-on proposal is far more likely to be > a successful deprecation path for Chrome (and, should they choose to > follow, Edge). I can understand why Firefox and WebKit don't have the same > constraints around enterprises and so would choose differently for > themselves. Yoav and I are happy to help in the standards discussions. I'm > about to go on vacation for 2 weeks but Yoav said he'd follow up with you > privately to brainstorm next steps. Sound good? > > Rick > > > On Wed, Jun 28, 2023 at 4:07 AM Fergal Daly <fer...@google.com> wrote: > >> Hi API-owners, >> >> >> I am now asking for permission to go ahead with the following concrete >> unload deprecation plan below. >> >> >> >> - >> >> Tools and outreach >> - >> >> M115 Enable `Permission-Policy: unload` (PP:unload) with the >> default being enabled. This allows sites to opt-in to unload >> deprecation. >> - >> >> Outreach to 1st/3rd parties, to migrate away from using unload and >> to enforce this with PP:unload. >> - >> >> Deprecation >> - >> >> M117 change the default for PP:unload so that unload handlers are >> skipped by default for 1% of page loads >> - >> >> M118 increase to 5% of page loads >> - >> >> M119 (last of 2023) increase to 10% of page loads >> - >> >> Evaluate progress on reduction of the use of unload >> - >> >> M120-128 increase +10% gradually to 100% of page loads >> >> >> Enterprise policy would allow opt-out entirely. >> >> >> Obviously, the deprecation timeline is contingent on unload usage coming >> down in response to the earlier steps. >> >> We expect that 10% of page loads will provide a noticeable signal to >> sites that use unload. Also, if we were to just follow the current spec and >> not run unload when we can BFCache (as happens on Clank/Firefox mobile and >> all WebKit) we expect that we would skip 30-40% of unload handlers when the >> main frame navigates. >> >> Decisions: >> >> - >> >> Timeline >> - >> >> All navigations vs main-frame navigations only >> >> >> Standardising >> >> We have some new data and have had some further discussions with browser >> vendors. There's no consensus. TL;DR WebKit are opposed to any >> Permissions-Policy but support removing unload eventually. Mozilla are >> still discussing. >> >> Both Mozilla <https://github.com/mozilla/standards-positions/issues/691> >> and WebKit <https://github.com/WebKit/standards-positions/issues/127> >> were opposed to standardising `Permissions-Policy: unload` (defaulting to >> on) because they worried that a containing frame might selectively disable >> unload handlers in a child frame for malicious purposes (no specific cases >> were discussed). >> >> So we flipped to the idea of having PP:unload with the default being >> disabled. We cannot suddenly do that. We need to roll it out gradually. >> WebKit folks are opposed to this and have suggested >> <https://github.com/WebKit/standards-positions/issues/200#issuecomment-1596385073> >> we do a reverse origin trial instead. If our plan works out, eventually we >> would ROT as the final nail but ROT starting now has downsides for users >> and sites and no upside for the implementer. >> >> Mozilla has so far not been negative >> <https://github.com/mozilla/standards-positions/issues/691> on the >> Permissions-Policy off-by-default approach but they are still discussing. >> They are concerned that disabling unloads when subframes are navigating >> could be a problem. We found that about 1/4 of subframe navigations involve >> an `unload` handler (most seem to involve handlers in cross-site and >> same-site site frames). We don't have examples of sites that rely on >> `unload` handlers in this way, although they probably do exist. Migrating >> to `pageshow` or using PP:unload for these sites should be trivial. >> >> We have the option to say that PP:unload only applies to main frame >> navigations. This would mean these sites would be completely unaffected >> however that has some downsides. It is harder to explain and does not end >> with full removal of `unload`. We would prefer to have this apply to all >> navigations unless we find a good reason not to. If we were to change >> part-way, there would be no breakage. We hope that once we drive down usage >> in 3rd-part iframes with PP:unload that the number of unload handlers >> running in subframe navigations decreases significantly. >> >> Finally there was some discussion >> <https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739> >> about how Permissions-Policy off-by-default should work. Our current >> version requires every page to set the header and every parent to set the >> iframe `allow` attribute. This is maximally conservative. If at some point >> later on there is agreement to standardise on something less conservative, >> it will not break pages that have already re-enabled `unload`. >> >> >> Overall it seems hard to standardise in advance but if we succeed in >> driving down `unload` usage, other browsers are on-board with removing >> unload. The worst case scenario would be where we implement PP:unload >> (which the others do not agree with) but make no noticeable progress on >> `unload` usage. If that happens we can just go with the currently specced >> behaviour (don't run `unload` if BFCaching is possible) and maybe revert >> the PP:unload, >> >> F >> >> On Tue, 9 May 2023 at 16:01, Fergal Daly <fer...@google.com> wrote: >> >>> On Mon, 8 May 2023 at 17:51, Rick Byers <rby...@chromium.org> wrote: >>> >>>> Hi Fergal, >>>> It's exciting to see this moving forward! Just to clarify, this is >>>> effectively an I2S for the unload permissions-policy, is that right? Or are >>>> you also requesting permission to stop firing unload events now too? The >>>> latter is going to require some significant compat analysis, but could be >>>> greatly informed by the experience of having some top-level sites opt-out >>>> of unload for their frame tree. >>>> >>> >>> Thanks. >>> >>> We're not requesting permission to stop firing at this point. It is the >>> far-away end-point. >>> >>> >>>> >>>> Any plan to trigger a deprecation warning / report for the installation >>>> of unload handlers? It might be tricky to find a good balance of useful >>>> warnings without being too spammy. >>>> >>> >>> Permission policy will do this as is with a console warning and >>> Reporting-API if you attempt to install a handler that is disallowed by >>> policy. >>> >>> >>>> >>>> A couple more questions / comments inline: >>>> >>>> On Mon, May 8, 2023 at 7:43 AM Fergal Daly <fer...@chromium.org> wrote: >>>> >>>>> Contact emails >>>>> >>>>> fer...@chromium.org, kenjibah...@chromium.org >>>>> >>>>> Explainer >>>>> >>>>> >>>>> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md >>>>> >>>>> Specification >>>>> >>>>> https://github.com/whatwg/html/pull/7915 >>>>> >>>> >>>> This is still marked as draft. Can you get this ready for review? If >>>> it's blocked only on having a 2nd implementor show support, then I'd be >>>> fine shipping based on a PR. But we should at least do what we can to >>>> solicit feedback on the spec change prior to shipping. >>>> >>> >>> Yes. There's nothing in the spec change that isn't in the requests for >>> positions but since neither of those are supportive yet, I have not asked >>> for review of the PR. I'm hopeful that once we have data on use on unload >>> in subframe navigations as discussed here >>> <https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320> >>> that >>> Mozilla will be supportive. Those metrics are in 113 but based on the data >>> from beta, we need to change how we record them. >>> >>> >>>> Summary >>>>> >>>>> A Permission-Policy for creating unload event listeners will be added. >>>>> >>>>> Initially, the default policy will be set to allow. From there, >>>>> Chrome will gradually migrate the default policy to deny (i.e. >>>>> increasingly disallow the creation of unload event listeners, eventually >>>>> reaching a state where deny fully becomes the default policy). The >>>>> ultimate goal is to remove support for unload event. >>>>> >>>>> Blink component >>>>> >>>>> Blink>PermissionsAPI >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPermissionsAPI> >>>>> >>>>> Motivation >>>>> >>>>> The unload event is extremely unreliable. It is ignored in most cases >>>>> by all mobile browsers except Firefox on Android. Furthermore, in Safari, >>>>> the unload event is ignored on both desktop & mobile platforms. >>>>> >>>>> In the current state, unload is a major BFCache blocker (~18 >>>>> percentage points reduction of hit rate for Chrome). >>>>> >>>>> The change will unlock a large fraction of that hit-rate while >>>>> providing an opt-out for those who need more time to migrate. It also >>>>> sends >>>>> a clear signal that unload should not be used in new development. >>>>> >>>>> Sidenote: the spec was changed to say that unload should only run if >>>>> the page cannot enter BFCache, which reflects Safari’s behavior, However >>>>> neither Chrome nor Mozilla have implemented this behavior. In Chrome's >>>>> case, we believe that this would suddenly break various sites and would >>>>> make it hard for developers to know if/when unload may run. >>>>> >>>>> >>>>> Initial public proposal >>>>> >>>>> None >>>>> >>>>> TAG review >>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/738 >>>>> >>>>> TAG review status >>>>> >>>>> Pending >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> If no other browsers implement this, there is a risk that devs >>>>> continue to use unload widely and pages malfunction on chrome. However >>>>> given that alternatives to unload exist it seems entirely possible for >>>>> sites that are actively maintained to move off unload. >>>>> >>>>> Gecko: ( >>>>> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320) >>>>> It's possible that pages are depending on `unload` handlers in subframes >>>>> for functionality even without any main frame navigation. We should try to >>>>> understand how common this is before breaking it. It should be possible to >>>>> measure how often subframe unloads fire when the mainframe is not >>>>> navigating. This will give us an upper bound on the size of the problem, - >>>>> Chrome: we have landed code to measure the occurrence of unload in >>>>> different scenarios. We will report back the findings. >>>>> >>>>> WebKit: https://github.com/WebKit/standards-positions/issues/127 >>>>> >>>> >>>> From a quick skim, it sounds like WebKit is already happy with their >>>> tradeoff of not firing unload and doesn't see a need for an API that >>>> reduces unload further, is that about right? WebKit has mostly shipped >>>> heuristics here without trying to spec them first, right? In general I'm >>>> not too concerned >>>> >>> >>> Yes, there's no great upside for them. I believe the situation as >>> specced where unload is unpredictable and likely biased is bad for devs and >>> is probably skewing data collected via WebKit (and Chrome/Mozilla mobile) >>> but nobody is complaining. >>> >>> I believe there was support expressed offline for the prospect of >>> killing off unload. >>> >>> >>>> >>>> Web developers: Positive ( >>>>> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ) >>>>> The web communities we reached out had positive reactions to our proposal >>>>> and we have not heard about any concrete blockers. >>>>> >>>>> Other signals: >>>>> >>>>> 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? >>>>> >>>>> On WebView, we will introduce the Permissions-Policy but not move the >>>>> default to "deny". BFCache does not work on WebView, so the benefit is >>>>> lower. Meanwhile the risk seems higher as we have far less visibility into >>>>> the HTML being run in WebViews. A roll-out to WebView should be done >>>>> independently and in consultation with the WebView team. >>>>> >>>> >>>> Sounds like the right strategy to me, thanks! >>>> >>>> >>>>> Debuggability >>>>> >>>>> None >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Yes >>>>> >>>>> Flag name >>>>> >>>>> None >>>>> >>>> >>>> Please put the new policy behind a RuntimeEnabledFeature >>>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>. >>>> It's effectively a new API so is required >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >>>> to have a finch killswitch. It sounds to me like it should be unlikely that >>>> simply adding the new policy could break things, but maybe some scenario is >>>> possible where we decide breakage in 3p iframes is bad enough to warrant an >>>> emergency fix? >>>> >>> >>> Yes, there will be a flag, maybe more than one. The implementation >>> details of rolling this out gradually have not been worked out. See below. >>> >>> >>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> Estimated milestones >>>>> >>>>> M115 for availability of Permissions-Policy >>>>> >>>>> M115 is the earliest we would start to disable unload, however >>>>> >>>> >>>> Is this a typo? Or are you considering disabling the event in the same >>>> release we first make the permissions policy available? >>>> >>> >>> The plan is to make the PP available with a default of enabled and then >>> gradually flip the default to disabled. The details are here >>> <https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md#logistics-of-deprecation>. >>> It's not particularly nice. We have the option to just stop 100% but that >>> seems fairly disruptive, >>> >>> F >>> >>> >>>> >>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5579556305502208 >>>>> >>>>> -- >>>>> 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+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLm7CR6EeL2KmBFyFpYT%3DNPXmTg4roLKV%3D7dRcCE%2BOoGwg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEyEi1gmZ8THfuKa_XBotNt-8LGZc_LpXvaOvucmrCyhvwKKVA%40mail.gmail.com.
