On Tue, 8 Aug 2023 at 08:00, Brandon Heenan <bhee...@google.com> wrote:
> 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. > It's just about naming/presentation - I'm adding a switch no matter what, just whether it shows in the deprecated tab or the main tab, F > > 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/CAAozHL%3DC8R3fsd%3DA9wP3PG%3DfJGxkzDgNaCc1vDraduxigtNvLg%40mail.gmail.com.
