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 <[email protected]>
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) <
[email protected]> wrote:
On Fri, Feb 16, 2024 at 8:19 PM Brad Triebwasser <[email protected]>
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) <
[email protected]> 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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
wrote:
[email protected] <[email protected]> / Reply All
Thanks for your feedback, Mike! Recipes inline:
On Tue, Feb 6, 2024 at 9:36 PM Mike Taylor <[email protected]> wrote:
Hi Brad,
On 2/6/24 3:49 PM, Brad Triebwasser wrote:
Contact emails
[email protected]
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 [email protected].
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 [email protected].
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 [email protected].
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ff5248d-c40b-413d-88b9-e596e6a0f7bdn%40chromium.org.
