Presumably the risk of legitimate breakage here is bounded by the use of the Window Management API, right? Are there any UseCounters for the various Window Management operations? I couldn't find any at a quick glance. I imagine legitimate usage is dominated by a few sites with an obvious need (do we have UKM data?), and such sites should always degrade gracefully without window management capabilities, right?
My intuition is that the compat risk here should be extremely low, but I hope we have some data to validate that which isn't tainted by the fingerprinting usage. Rick On Wed, Feb 7, 2024 at 1:59 PM Brad Triebwasser <btri...@chromium.org> wrote: > +blink-dev@chromium.org <blink-dev@chromium.org> / Reply All > > Thanks for your feedback, Mike! Recipes inline: >> >> On Tue, Feb 6, 2024 at 9:36 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Hi Brad, >>> On 2/6/24 3:49 PM, Brad Triebwasser wrote: >>> >>> Contact emails >>> >>> btri...@chromium.org >>> >>> Explainer >>> >>> >>> https://github.com/w3c/window-management/blob/main/EXPLAINER_spec_and_permission_rename.md >>> >>> Specification >>> >>> https://w3c.github.io/window-management/#api-permission-api-integration >>> >>> Summary >>> >>> Removes the legacy "window-placement" alias for permission and >>> permission policy "window-management". This is a follow-up to >>> https://chromestatus.com/feature/5146352391028736 and corresponding >>> blink-dev PSA >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Hf2b1-S39Uw/m/YAEC_0DSBQAJ>. >>> The "window-placement" alias has been showing console deprecation warnings >>> since M113 >>> <https://chromium.googlesource.com/chromium/src.git/+/13204be718225ae09c8ba7e36b055a369c36c878>. >>> We will disable WindowPlacementPermissionAlias >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5?q=-f:gen%2F%20AND%20-f:out%2F%20WindowPlacementPermissionAlias> >>> by default, and remove the flag and legacy code shortly thereafter. >>> >>> I'm a little bit confused here - it seems like the PSA of the alias is >>> being treated as the beginning of a deprecation, is that correct? My >>> interpretation of "will lead to a deprecation and removal" from the >>> original message was that it would be followed with an Intent to Deprecate >>> and Remove (per >>> https://www.chromium.org/blink/launching-features/#deprecate), but it >>> seems like that step of the process was skipped. >>> >> Yes, I never sent out a separate "Intent to Deprecate" in this case. The >> original PSA >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Hf2b1-S39Uw/m/YAEC_0DSBQAJ> >> was >> intended to be a hybrid of the introduction of the new names and >> deprecation of the old ones so we also landed deprecation code (DevTools >> deprecation warnings etc.) during that time. Since these have already been >> "deprecated" since M113, I wasn't sure if a separate "intent to deprecate" >> was appropriate in this case since we already deprecated them and monitored >> usage to be sufficiently low, but I can back-up and send an I2D if >> recommended here. >> >>> >>> Blink component >>> >>> Blink>Screen>MultiScreen >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScreen%3EMultiScreen> >>> >>> TAG review >>> >>> No feedback was specifically requested for the permission rename, >>> however related TAG reviews have been requested with both the old (1 >>> <https://github.com/w3ctag/design-reviews/issues/413>, 2 >>> <https://github.com/w3ctag/design-reviews/issues/602>) and new >>> terminology (3 <https://github.com/w3ctag/design-reviews/issues/840>). >>> >>> TAG review status >>> >>> Not applicable >>> >>> Risks >>> Interoperability and Compatibility >>> >>> There are low compatibility risks. Usage for the legacy permission and >>> permission policy are ~0.006 >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4448> and >>> ~0.015 >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4450> (% >>> page loads) while the new variants are ~1.166 >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4447> and >>> ~3.066 >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4449> (% >>> page loads) respectively, indicating most usage has already migrated. >>> >>> These percentages are still relatively high, especially for the >>> permissions policy variant. Besides the obvious fingerprint.js usage (which >>> shouldn't break pages... I would hope), can you describe what the failure >>> mode is after the proposed removal is? Have you dug into the remaining >>> usage to verify? >>> Yes, I dug into the remaining usage quite extensively via Web Archive >>> queries and UKM and couldn't find any usages other than what looked like >>> fingerprinting. After removal, the permission API will produce an error due >>> to an unknown permission, and the permission policy will silently fail >>> (e.g. iframes with allow='window-placement' will not have access to the >>> features). I beleive that the numbers shifting several orders of magnitude >>> in favor of the new strings seems to indicate legitamite usage has >>> migrated, and the remainig usage likely fingerprinting. >>> >>> Gecko: No signal >>> >>> Firefox has not implemented the API and corresponding permission yet. >>> The original API signal request is here >>> <https://github.com/mozilla/standards-positions/issues/542>. >>> >>> WebKit: No signal >>> >>> Safari has not implemented the API and corresponding permission yet. The >>> original API signal request is here >>> <https://github.com/WebKit/standards-positions/issues/117>. >>> >>> Mind linking to the original API position requests here in this thread? >>> Added links above to the original API signal request. FWIW, we have >>> since filed additional requests for functionality related to window >>> management, not necessarily window *placement* related (hence >>> motivation for renaming the API): eg 1 >>> <https://github.com/WebKit/standards-positions/issues/96> 2 >>> <https://github.com/mozilla/standards-positions/issues/712> >>> >>> >>> Web developers: We have communicated internally with partners using the >>> API who have expressed commitment to updating the permission strings in >>> their code. >>> >>> Other signals: Positive comment >>> <https://github.com/w3c/window-placement/pull/115#pullrequestreview-1159676614> >>> from W3C WG Chair >>> >>> WebView application risks >>> >>> This is considered low risk. It removes an alias without any change in >>> behavior of the underlying API. >>> >>> Does this permission do anything on WebView? I would have guessed no. >>> Your correct, this window management API doesn't apply to WebView so >>> there is no impact there. >>> >>> >>> Debuggability >>> >>> Disabling WindowPlacementPermissionAlias >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5?q=-f:gen%2F%20AND%20-f:out%2F%20WindowPlacementPermissionAlias> >>> will stop DevTools deprecation warnings for usage of the legacy strings and >>> instead will act as if they did not exist at all (e.g. Permission API will >>> produce an error when using "window-placement"). >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? >>> >>> No. This feature is not supported on Android. >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> Yes. Web Platform tests have already been migrated to the new alias: >>> >>> https://github.com/web-platform-tests/wpt/tree/master/window-management >>> >>> Flag name on chrome://flags >>> >>> None >>> >>> Finch feature name >>> >>> WindowPlacementPermissionAlias >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1328581 >>> >>> Estimated milestones >>> >>> M123 (flag disable) M125 (flag/code removal) >>> >>> Anticipated spec changes >>> >>> None >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5137018030391296 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> 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/CALEeEUCdqsmmEhBROkinxbzTULFPXnC8goANs6-_O8n3%2B%3D47hQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALEeEUCdqsmmEhBROkinxbzTULFPXnC8goANs6-_O8n3%2B%3D47hQ%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/CALEeEUBYrF50-%3Dp8umAxQLaEttR-jW4WRfWyF5AATV2p29w17w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALEeEUBYrF50-%3Dp8umAxQLaEttR-jW4WRfWyF5AATV2p29w17w%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/CAFUtAY-oM3xmkW8FCUZ34Xi4AnFnbXiA5FdQGKqFA%2BHrVr18QQ%40mail.gmail.com.
