On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly <fer...@google.com> wrote:
> On Thu, 29 Jun 2023 at 01:16, 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 addition to Daisuke's response... are you concerned about enterprises > that are not using fleet management and so cannot use the opt-out? If you > think an enterprise policy will not be sufficient, a mitigation for those > enterprises would be for us to publish an extension that allows anyone to > re-enable unload (for all sites or for specific sites) by injecting the > PP:unload header. Are the escalations that can't be resolved by either a > policy or extension? > One extra comment on the extension option (great for desktop). If you wonder about the mobile BYOD scenarios, where extensions don't exist, then we are a bit lucky here because unload is already unreliable on mobile. So, it seems extremely unlikely that we'd see mobile enterprise/edu products that rely on unload on mobile. *Rick:* are there specific scenarios / environments that we haven't covered? > > >> >> 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? >> > > I would love to get moving on PP:unload ASAP no matter what. It's been > through OT and is sitting behind a flag with some sites eager to use it. > I'm happy to send an I2S for that while we discuss the harder problem. We > hope that getting that out there can clear out a large chunk of the 1st- > and 3rd-party unload usage, > +1, I'd suggest doing that regardless. There are a few large sites that have done some legwork on unload handlers (theirs and third party partners), and are interested in pushing the remaining unload handlers out with PP:unload. Having allies in the ecosystem (i.e. extra incentives to migrate), will be helpful going forward :) > > F > > >> >> 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> >>>>>> . >>>>>> >>>>> -- Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) Product Manager - Chrome Google Japan -- 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/CADWWn7UZnyVpLJa0hh3cKaa0mHWTxm4Rr2sb7YOcfkSfOBrfjQ%40mail.gmail.com.
