[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.
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/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/CALEeEUCgDTY_w%3Dz5eiYzqvLC3g%2B9Nh3-vNGabc50%3D5r6AQPMPA%40mail.gmail.com.
