Intent to Ship: Remove "window-placement" alias for permission and permission policy "window-management"

[Brad Triebwasser]

Contact emails

btr...@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. The "window-placement" alias has been showing console deprecation warnings since M113. We will disable WindowPlacementPermissionAlias by default, and remove the flag and legacy code shortly thereafter.

Blink component

Blink>Screen>MultiScreen

TAG review

No feedback was specifically requested for the permission rename, however related TAG reviews have been requested with both the old (1, 2) and new terminology (3).

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 and ~0.015 (% page loads) while the new variants are ~1.166 and ~3.066 (% page loads) respectively, indicating most usage has already migrated.

Gecko: No signal

Firefox has not implemented the API and corresponding permission yet.

WebKit: No signal

Safari has not implemented the API and corresponding permission yet.

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 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.

Debuggability

Disabling WindowPlacementPermissionAlias 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?

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.

[Mike Taylor]

Hi Brad,

On 2/6/24 3:49 PM, Brad Triebwasser wrote:

Contact emails

btr...@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. The "window-placement" alias has been showing console deprecation warnings since M113. We will disable WindowPlacementPermissionAlias 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.

Blink component

Blink>Screen>MultiScreen

TAG review

No feedback was specifically requested for the permission rename, however related TAG reviews have been requested with both the old (1, 2) and new terminology (3).

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 and ~0.015 (% page loads) while the new variants are ~1.166 and ~3.066 (% 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?

Gecko: No signal

Firefox has not implemented the API and corresponding permission yet.

WebKit: No signal

Safari has not implemented the API and corresponding permission yet.

Mind linking to the original API position requests here in this thread?

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 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.

Debuggability

Disabling WindowPlacementPermissionAlias 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?

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.

--
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+...@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.

[Brad Triebwasser]

+blin...@chromium.org / Reply All

Thanks for your feedback, Mike! Recipes inline:

On Tue, Feb 6, 2024 at 9:36 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Brad,

On 2/6/24 3:49 PM, Brad Triebwasser wrote:

Contact emails

btr...@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. The "window-placement" alias has been showing console deprecation warnings since M113. We will disable WindowPlacementPermissionAlias 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 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

TAG review

No feedback was specifically requested for the permission rename, however related TAG reviews have been requested with both the old (1, 2) and new terminology (3).

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 and ~0.015 (% page loads) while the new variants are ~1.166 and ~3.066 (% 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.

WebKit: No signal

Safari has not implemented the API and corresponding permission yet. The original API signal request is here.

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 2

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 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.

[Rick Byers]

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

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.

[Mike Taylor]

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.

[Brad Triebwasser]

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) 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

[Yoav Weiss (@Shopify)]

200 origins sounds like a lot. Do you know what %age of page views those origins would represent?

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.

[Brad Triebwasser]

Usage for the legacy permission and permission policy are ~0.006 and ~0.015 (% page loads) while the new variants are ~1.166 and ~3.066 (% 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. 

Regards,
Brad

[Yoav Weiss (@Shopify)]

On Fri, Feb 16, 2024 at 8:19 PM Brad Triebwasser <btr...@chromium.org> wrote:

Usage for the legacy permission and permission policy are ~0.006 and ~0.015

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?

[Vladimir Levin]

On Mon, Feb 19, 2024 at 12:10 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Fri, Feb 16, 2024 at 8:19 PM Brad Triebwasser <btr...@chromium.org> wrote:

Usage for the legacy permission and permission policy are ~0.006 and ~0.015

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% 

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.

[Brad Triebwasser]

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."

[Brad Triebwasser]

[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

[Yoav Weiss (@Shopify)]

On Tue, Feb 20, 2024 at 4:56 PM Vladimir Levin <vmp...@chromium.org> wrote:

On Mon, Feb 19, 2024 at 12:10 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Fri, Feb 16, 2024 at 8:19 PM Brad Triebwasser <btr...@chromium.org> wrote:

Usage for the legacy permission and permission policy are ~0.006 and ~0.015

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% 

Oops! indeed.

[Yoav Weiss (@Shopify)]

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

+blin...@chromium.org / Reply All

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Brad Triebwasser]

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 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 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 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

[Yoav Weiss (@Shopify)]

LGTM1

Thanks for diving into the samples. Sounds like the breakage risk here is indeed low.

[Domenic Denicola]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8E3Fct43ED1Se82h3CE3x2oNahe9xOkztC%3DFEAV7XTpg%40mail.gmail.com.