On Mon, Feb 19, 2024 at 12:10 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> > > 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. > To confirm: I believe your sentence is correct but the number in brackets is off by a factor of 10, right? The threshold is typically ~0.003% > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL%3DB4B7EEdp%2B5xV8QfT5MFre%2BDbrfv%2B65HEp2z8xdH-bg%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/CADsXd2My9EcE%3D05UnO8SWhV97ybu4y1Mbv2AQ9Sau_h_vyKwhQ%40mail.gmail.com.
