Flipping the permission policy default is still a breaking change that requires some action from the developer to keep unload events, right? If so, we still want en entry in the /deprecated page so that unmanaged (vendors/BYOD/outbound) users accessing on-prem deployments have some mitigation. Kenji and I discussed this case with SAP last week, and that level of mitigation seemed necessary.
On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly <fer...@google.com> wrote: > > > On Sat, 8 Jul 2023 at 07:55, Brandon Heenan <bhee...@google.com> wrote: > >> Hello, I'm chiming in to provide some thoughts from the enterprise >> perspective. >> >> Our goal is to not block forward progress to the web, but to improve the >> web in an enterprise-friendly way. You shouldn't ever hear me say "you >> can't do X because it's scary to the enterprise team." You should instead >> hear "We expect X to be risky, but here are the things we know we can do to >> make it much less risky." >> >> In this case, yes, this is risky for enterprises. We can say this with >> confidence because we've seen escalations before when we've made changes to >> unload events (crbug.com/933153, crbug.com/953228). >> >> Kenji and Daisuke have been working with us, and my understanding of the >> plan is to: >> >> - >> >> Allow developers to opt-in early to the new behavior (unload event >> ignored) with a permission policy >> - >> >> Communicate the change on chromestatus and the enterprise release >> notes (already happening >> >> <https://support.google.com/chrome/a/answer/7679408?sjid=15316582819754370342-NA#skpUnload114>). >> We will provide a bug link for customers for feedback in a future release. >> - >> >> Reach out to enterprises and developers we expect to be affected >> - >> >> Introduce an enterprise policy to allow an IT admin to control unload >> event behavior >> - >> >> Introduce a flag in chrome://flags/deprecated to allow end users to >> control unload event behavior >> >> > I looked into this, I'm not sure this should be a deprecated flag. It > doesn't really fit the description. Some time in the future when we start > to fully disable unload, there should be a deprecated flag for unload but > right now we are just flipping the permission policy default. > > Are you OK with just adding a UI entry for the existing flag that controls > this Permission-Policy rollout (which is named DeprecateUnload but I'm > happy to rename it) > > F > > >> >> - >> >> As early as M117, change the default for the policy so that unload >> events will be ignored. This is the breaking change, and there's likely to >> be friction here. The two escalations mentioned above both resulted in >> respins the first time they reached this point. However, this time around, >> IT admins will be able to fix their environment immediately with the >> enterprise policy, end users will be able to fix themselves with the >> deprecation flag, and developers will be able to fix their app with the >> permission policy. With those mitigations in place, the risk of requiring >> a >> respin (or Finch rollback) due to enterprise impact is dramatically >> reduced, and this is how we eventually successfully shipped both of those >> above escalations. >> - >> >> We expect a long transition period after that. By default, the unload >> event is ignored, but different stakeholders are able to revert to legacy >> behavior. Within enterprise, we expect the enterprise policy to be the >> most >> useful mitigation, and the deprecation flag is the backup for BYOD or >> unmanaged devices. For the above escalations, this migration period was >> over a year, and I'm expecting something similar this time. >> - >> >> At some point in the future, we expect to remove those mitigations >> and remove support for the unload event completely. We don't have any >> specific dates for that yet; we will be responsive to the needs of web >> stakeholders, enterprise and otherwise. >> >> The two escalations I mentioned above were successfully resolved and the >> changes to not allow popups on page unload and to not allow synchronous >> XHRs on page unload were shipped. Both of those changes followed >> essentially the same plan I just laid out above, and so I think it's >> reasonable to do the same thing here. >> >> >> On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote: >> >>> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux <kenji...@google.com> >>> wrote: >>> >>>> >>>> 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? >>>> >>> >>> I'm glad to see the conversation with the enterprise team is further >>> along than I had realized. Having skip unload events in the release >>> notes >>> <https://support.google.com/chrome/a/answer/7679408?sjid=5091298988245423514-NA#skpUnloadEv113> >>> since M113 is a significant mitigation, sorry I wasn't caught up on the >>> latest. And yes some sort of user opt-out for BYOD (extension or >>> chrome::/flags, etc.) seems like an essential mitigation. I defer to the >>> enterprise team's judgement here, so if they're OK with proceeding then we >>> shouldn't let my enterprise fears block us. I expect we do need some easy >>> way for an application to signal that it really does need unload handlers. >>> Setting a permission policy is likely orders of magnitude easier than >>> converting essential unload handlers to pagehide and ensuring they're safe >>> to invoke multiple times. >>> >>> The other major constituency potentially impacted are ad networks. >>> Perhaps the next step should be a 1% finch trial where we can measure >>> various ad-related metrics? I'd defer to the judgment of the Chrome Ads >>> team (@Josh Karlin). >>> >>> Anyway, I'm personally OK with 1% stable experiments (and whatever else >>> on dev/beta). But I think we should discussing learnings from such 1% >>> experiments here publicly before approving a plan to go beyond that. >>> >>> 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 :) >>>> >>> >>> Yep I think this was Yoav and my primary concern. For chrome to have a >>> pragmatic and reasonable deprecation path given our user base, we really >>> need sites adopting such an API. If we're not going to actually ship such >>> an API then I think we'd have to give up on deprecating unload. I'd support >>> shipping this API despite the lack of support from WebKit and Gecko. >>> >>> >>>> 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, kenji...@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+...@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/CAFKd2qWW%3DNinavDcaJx7ejbgYF5rbZ6-YbC-SAVbWet%2Bj0UQPQ%40mail.gmail.com.
