200 origins sounds like a lot. Do you know what %age of page views those origins would represent?
On Wed, Feb 14, 2024 at 11:32 PM Brad Triebwasser <btri...@chromium.org> wrote: > *tl;dr:* We expect at most 200 origins could break, and only ~30 of those > may be legitimately using the API. > > We do track UMA/UKM for the primary API entrypoint function ( > GetScreenDetails > <https://developer.mozilla.org/en-US/docs/Web/API/Window/getScreenDetails>) > which we expect nearly all legitimate usage of the API to use. We see 60 > unique origins invoking GetScreenDetails, dominated by a handful of > origins (which align with the partners we know are using the API). > > For reference, 2500 unique origins are checking the window-management > permission, and 200 unique origins checking the old window-placement > permission (82% of those origins are *not *logging any GetScreenDetails > calls). > > As Mike mentioned, the only breakage here would be a site using > navigator.permissions.query({name: > 'window-placement'}) without error handling which according to UKM data > would be roughly 200 origins (at most 18% of those may be > legitimately using the API). > > I believe 200 unique origins is a relatively low number of potential > breakages, especially considering our data strongly suggests a majority of > that is fingerprinting. > > Regards, > Brad > > > On Mon, Feb 12, 2024 at 6:27 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> Agree that the risk feels low... one thing to perhaps check for (if you >> have UKM or use counters) is to see if there is any legit usage on sites of >> `navigator.permissions.query()` that isn't catching errors, since that will >> throw a TypeError and can break a page. >> On 2/12/24 9:16 AM, Rick Byers wrote: >> >> 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/CALEeEUDd9YoriLSXG3h7usjpyJThZ4W3%2BixTCdVK2PhS0p9_Rw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALEeEUDd9YoriLSXG3h7usjpyJThZ4W3%2BixTCdVK2PhS0p9_Rw%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/CAOmohSKNJHwoZ9MrB_Oujv9XZ8Eq2qJbmCk%2ByOqUtq6SV0QGqA%40mail.gmail.com.
