LGTM2 On Thu, Feb 22, 2024 at 5:20 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> LGTM1 > > Thanks for diving into the samples. Sounds like the breakage risk here is > indeed low. > > On Wed, Feb 21, 2024 at 8:15 PM Brad Triebwasser <btri...@chromium.org> > wrote: > >> Sure, I checked 10 unique origins (skipping duplicate pu707ev.com >> subdomains which make up half of the sampled domains) listed in >> https://chromestatus.com/metrics/feature/timeline/popularity/4448. >> >> 4 of them reference: >> https://cdn.jsdelivr.net/gh/cffgnu/qhdd/asset/responsive.min.js. I won't >> post all the code here, but you can see it querying a list of permissions, >> with a .catch() shortly after. Evidence of fingerprinting, but does handle >> exceptions. >> 1 on the root page <https://app.webscrapingapi.com/login> listed all >> permissions (and specifically >> referenced >> third_party/blink/renderer/modules/permissions/permission_descriptor.idl); >> Looks like fingerprinting. It has a catch following the >> navigator.permissions.query call. >> 1 had a library >> <https://klempner-verband.de/assets/js/app.js?id=a58e3fa4bf16bb1db6a6.js>checking >> every permission with navigator.permissions.query with a corresponding >> catch handler. >> 2 referenced https://fs.pudaf.com/fp.js. This was a little more >> obfuscated and I can't tell if exceptions are handled, but looking at the >> code, there is a ton of evidence suggesting fingerprinting (iterating over >> every permission, navigator properties, etc.). I tried in Firefox, and >> didn't observe any unhandled exceptions even though the debugger did pass >> that point in the code. >> 2 used a similar highly obfuscated library >> <https://ebarter.pro/app/js/dd.js> which contains the "window-placement >> string" but I did not see any corresponding permissions.query call, so >> results are inconclusive, but the sites did load in firefox with no >> unhandled exceptions on the missing window-placement permission. >> >> Out of 10 sampled origins, 8 were obvious fingerprinting, 8 had exception >> handling, 2 were too obfuscated to be conclusive. >> >> Regards, >> Brad >> >> On Tue, Feb 20, 2024 at 11:01 PM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> >>> >>> On Tuesday, February 20, 2024 at 8:32:33 PM UTC+1 Brad Triebwasser wrote: >>> >>> [Premature Send. Full message below] >>> >>> We are tracking UMA for when the permission name "window-placement" is >>> parsed (e.g all calls to navigator.permissions.query({name: >>> 'window-placement'}) increment the counter. That function will throw an >>> exception *"The provided value 'window-placement' is not a valid enum >>> value of type PermissionName." *once we remove the permission. So based >>> on the metrics, 0.006% of page loads that aren't handling the exception >>> could break. I strongly suspect most sites would have exception handling >>> since no other browser has implemented this permission string. >>> >>> >>> Would it be possible to manually inspect a few samples to see how many >>> of these sites properly handle the exception? >>> https://chromestatus.com/metrics/feature/timeline/popularity/4448 seems >>> to have a list of 100+ origins >>> >>> >>> We are also tracking UMA for window-placement permission policy. So >>> everytime the browser parcels "window-placement" in a header (e.g. >>> Permissions-Policy: >>> window-placement=(self)) or in an iframe (e.g. <iframe src=" >>> https://example.com"; allow="window-placement"></iframe>), the counter >>> is incremented. So ~0.015% of page loads are parsing the window-placement >>> policy. This scenario would not explicitly break a page, but the policy >>> would silently be ignored and the corresponding permission denied if the >>> site did not also have window-management specified. Again, no other browser >>> has implemented this string, so I suspect sites legitimately using this >>> would have some kind of fallback for non-chromium browsers anyway. >>> >>> Regards, >>> Brad >>> >>> >>> On Tue, Feb 20, 2024 at 11:24 AM Brad Triebwasser <btri...@chromium.org> >>> wrote: >>> >>> Certainly. >>> >>> We are tracking UMA both for when the permission name "window-placement" >>> is parsed (e.g all calls to navigator.permissions.query({name: >>> 'window-placement'}) increment the counter. That function will throw an >>> exception *"The provided value 'window-placement' is not a valid enum >>> value of type PermissionName."* >>> >>> 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. >>> >>> 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/CALEeEUCdqsmmEhBROkinxbzTULFPX >>> nC8goANs6-_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/CALEeEUDd9YoriLSXG3h7usjpyJThZ >>> 4W3%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/CAOmohS%2BkYoJShdaKKonG1pZasT4vg7enXWdh%2BU8FNeVTmyPKWw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BkYoJShdaKKonG1pZasT4vg7enXWdh%2BU8FNeVTmyPKWw%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/CAM0wra8E3Fct43ED1Se82h3CE3x2oNahe9xOkztC%3DFEAV7XTpg%40mail.gmail.com.
