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/CALEeEUDXGvQV3v-pwCqHGDCtsd9GsuyZL-hUass%2BSeTs2SGOOA%40mail.gmail.com.
