On Fri, Feb 16, 2024 at 8:19 PM Brad Triebwasser <btri...@chromium.org> wrote:
> 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> > Can you detail what these two different counters represent? Our typical threshold is about half of the lower one (~0.0003%), but that varies based on the potential breakage. What would breakage here look like? > (% 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, so the main metric for potential breakage here is > 0.006% of page loads. 0.006% seems low in my opinion, but I'm curious if > there is any guidance on a lower target % we should be aiming for prior to > removing this feature. > > I separately calculated that the 200 origins make up about 0.0058% of > total origins tracked by UKM (if that's what you're asking), which aligns > with the UMA figures. I also want to note that 50 of those origins are > likely the same (spam?) website (e.g. https://aaaa123.com, > https://aaaa124.com, https://aaaa125.com). You can see examples of this > in the UMA sample data > <https://chromestatus.com/metrics/feature/timeline/popularity/4448>. > > Regards, > Brad > > On Thu, Feb 15, 2024 at 12:42 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> 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/CAOmohSL%3DB4B7EEdp%2B5xV8QfT5MFre%2BDbrfv%2B65HEp2z8xdH-bg%40mail.gmail.com.
