Intent to Ship: Clear window name for cross-site navigations that switches browsing context group

[Shuran Huang]

Contact emails

shu...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/browsing-the-web.html#resetBCName

Summary

The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, such as when a user initiates a navigation from the URL bar or some cross-site navigation by clicking on a hyperlink on the current page. This can leak information and potentially be used as a tracking vector. 

To address this, we want to clear the window.name when the navigation is cross-site and switches browsing context groups, which aligns with the requirement by the spec. The implementation is behind a flag. This should be a low risk change since looking up a browsing context by name (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name) does not work where the documents’ origins are different and in different browsing context groups, so the name isn't actually useful. User counter is at around 0.006%: https://www.chromestatus.com/metrics/feature/timeline/popularity/3353

There are two other related changes that are required by spec but not covered in this intent, and are addressed by separate bugs:

• Restoring browsing context names on navigation (as defined in https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal): https://crbug.com/1141017

• Clearing window.name for cross-site navigations when the browsing context group is not replaced:  https://crbug.com/706350.

Blink component

UI>Browser>Navigation

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change will affect where window.name is used for cross-domain communication,  but we already have window.postMessage() as the recommended mechanism for the purpose. Other browsers are mitigating this usage as well.

Firefox: Shipped

Safari: Shipped

Web developers: No signals

Is this feature fully tested by web-platform-tests?

Yes. https://wpt.fyi/results/html/browsers/windows/clear-window-name.https.html?label=master&label=experimental&aligned

Tracking bug

https://crbug.com/1090128

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5962406356320256

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

This seems like a privacy-positive change, so thanks for working on this!

On Wednesday, March 31, 2021 at 10:36:11 PM UTC+2 Shuran Huang wrote:

Contact emails

shu...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/browsing-the-web.html#resetBCName

Summary

The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, such as when a user initiates a navigation from the URL bar or some cross-site navigation by clicking on a hyperlink on the current page. This can leak information and potentially be used as a tracking vector. 

To address this, we want to clear the window.name when the navigation is cross-site and switches browsing context groups, which aligns with the requirement by the spec. The implementation is behind a flag. This should be a low risk change since looking up a browsing context by name (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name) does not work where the documents’ origins are different and in different browsing context groups, so the name isn't actually useful. User counter is at around 0.006%: https://www.chromestatus.com/metrics/feature/timeline/popularity/3353

Hmm, did you mean 0.6%?

Usage seems rather high for such an esoteric bit of functionality. Did you do some more digging as to how this is being used and by whom?

 

There are two other related changes that are required by spec but not covered in this intent, and are addressed by separate bugs:

• Restoring browsing context names on navigation (as defined in https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal): https://crbug.com/1141017

• Clearing window.name for cross-site navigations when the browsing context group is not replaced:  https://crbug.com/706350.

Blink component

UI>Browser>Navigation

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change will affect where window.name is used for cross-domain communication,  but we already have window.postMessage() as the recommended mechanism for the purpose. Other browsers are mitigating this usage as well.

Firefox: Shipped

Seems like they've hit some compatibility issues related to WebDriver: https://bugzilla.mozilla.org/show_bug.cgi?id=1685089#c8

Have we looked into that? Would we suffer from similar issues?

[Shuran Huang]

Hi Yoav,

Thanks for the feedback! I spent some time on your questions and answered them inline. 

On Thu, Apr 1, 2021 at 4:44 AM Yoav Weiss <yoav...@chromium.org> wrote:

This seems like a privacy-positive change, so thanks for working on this!

On Wednesday, March 31, 2021 at 10:36:11 PM UTC+2 Shuran Huang wrote:

Contact emails

shu...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/browsing-the-web.html#resetBCName

Summary

The value of the window.name property is currently preserved throughout the lifetime of a tab, even with navigation that switches browsing context groups, such as when a user initiates a navigation from the URL bar or some cross-site navigation by clicking on a hyperlink on the current page. This can leak information and potentially be used as a tracking vector. 

To address this, we want to clear the window.name when the navigation is cross-site and switches browsing context groups, which aligns with the requirement by the spec. The implementation is behind a flag. This should be a low risk change since looking up a browsing context by name (https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name) does not work where the documents’ origins are different and in different browsing context groups, so the name isn't actually useful. User counter is at around 0.006%: https://www.chromestatus.com/metrics/feature/timeline/popularity/3353

Hmm, did you mean 0.6%?

Usage seems rather high for such an esoteric bit of functionality. Did you do some more digging as to how this is being used and by whom?

 

You are right that it should be 0.6%, sorry for the confusion. I am looking into HTTP Archive and see what sites are using this feature. Will provide more detail.

There are two other related changes that are required by spec but not covered in this intent, and are addressed by separate bugs:

• Restoring browsing context names on navigation (as defined in https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal): https://crbug.com/1141017

• Clearing window.name for cross-site navigations when the browsing context group is not replaced:  https://crbug.com/706350.

Blink component

UI>Browser>Navigation

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change will affect where window.name is used for cross-domain communication,  but we already have window.postMessage() as the recommended mechanism for the purpose. Other browsers are mitigating this usage as well.

Firefox: Shipped

Seems like they've hit some compatibility issues related to WebDriver: https://bugzilla.mozilla.org/show_bug.cgi?id=1685089#c8

Have we looked into that? Would we suffer from similar issues?

 

Thanks for catching it. It looks to me the issue lies in Protractor, a testing tool used by FirefoxDriver. Protractor uses the "Deferred Bootstrap" feature provided by AngularJS, which mangles with the window.name property, to perform tests. This has been broken on Safari for 4 years now: https://github.com/angular/protractor/issues/4004. Based on the issue comments, it's mostly a wontfix on the FireFox side. I also feel it makes sense for the Protractor team to fix this issue.

[Mike West]

Friendly ping on this. Were you able to clarify the compat impact of the 0.6% usage number?

-mike

--
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/CAJ3-5L2c9wXMJ841984sZRHQMOaafX9NbJo6JKSdaO4a2Yg2pw%40mail.gmail.com.

[Shuran Huang]

Hi Mike,

I am still trying to collect data to clarify the impact. Unfortunately HTTP Archive does not have the data, so UKM was recently added for it. Meanwhile, I am tracing down the window.name usage in Google's client library, which can contribute a lot to the ratio.

It's worth mentioning that 0.6% is an upper bound ratio, i.e. whenever a site reads the non-null-but-should-be-null window.name after a cross-site cross-BCG navigation, which may not really be indicative of the compatibility problem. 

Thanks,

Shuran

[Mike West]

Ping. Were you able to make progress with regard to tracking down usage anecdotes to better understand possible compat issues?

-mike

[Rick Byers]

I believe we've found before that some popular sites have code which enumerates the window object ("for (x in window)" etc.), and this makes UseCounters for rarely accessed properties on window almost meaningless. The UKM data should tell you, but it might be worth comparing to UMA/UKM data for any other property getter on the global object.  

The stronger signal may be what happened when Firefox and Safari shipped this change. If there's no evidence of any site being broken when the other browsers changed, and we're not aware of any reason someone might prefer to use window.name instead of postMessage() then perhaps that's enough to give this change a shot but be prepared to revert if breakage is uncovered during beta? My primary concern would be Chrome-only enterprise apps, so there's some risk of a firedrill requiring a quick disable once it hits stable. 

Rick

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

[Shuran Huang]

Hi Mike, 

The UKM UseCounter was released in beta yesterday. I am waiting to collect data from it. 

Thanks,

Shuran

[Shuran Huang]

Based on the UKM collected from beta M91, this feature is triggered the most on https://www.google.com, way higher than other origins.

To figure out its compatibility impact for google, I've reached out to GAPI team (GAPI is Google’s client library for browser-side JavaScript, which calls the window.name property, and is loaded when browsing www.google.com) , as well as Web Testing team to find whether enabling this feature would cause issues for GAPI or any google3 web test to fail (on chrome-linux). The test results showed that this feature shouldn't be a problem for GAPI, and does not have any impact for google3 web tests.

I also haven't heard back from Firefox for any compatibility issues after shipping this feature. So I wonder if we can enable the feature for the binary and be prepared to revert it back if it causes any breakage in beta. Also want to mention that this feature can be disabled in Chrome://flags with clear-cross-browsing-context-group-main-frame-name.

[Yoav Weiss]

On Tue, May 18, 2021 at 6:58 PM Shuran Huang <shu...@chromium.org> wrote:

Based on the UKM collected from beta M91, this feature is triggered the most on https://www.google.com, way higher than other origins.

Fun!

If we exclude google.com, what is the %age of visits that are hitting this?

[Shuran Huang]

Tried to calculate feature hit rate with origin matching "*.google.*", which contributes ~27% of all the feature hits (other sites are below 3%). Note that the GAPI script could be loaded on other sites that do not set the window.name field, which can contribute to the feature hit but does not have compatibility issues if we enable the feature.

I also checked the latest data from Chrome Status Platform, the feature popularity drops to 0.4%. Could it be a reaction to the Firefox change? According to the response received from Firefox, they haven't observed any breakage so far. If enabling this feature for the binary is considered risky, we can also go for a Finch rollout.

[Mike West]

LGTM1. This is the right direction for the platform, and following Firefox's and Safari's good example gives me confidence that the 0.6% number above is more benign than it looks.

That said, two things seem prudent:

1.  Given the usage, it's probably a good idea to roll this out via Finch, as you suggest. I'm comfortable leaving the rollout schedule to y'all, as long as we have the ability to turn it off if our hopes about compatibility turn out to be unfounded.

2.  Likewise, we often discover that our enterprise users are unexpectedly exercising portions of the platform we'd like to remove. It would be ideal to add a policy that allows them to carve themselves out from this change for a limited time while they adjust their applications.

Thanks!

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

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/CAJ3-5L2c9wXMJ841984sZRHQMOaafX9NbJo6JKSdaO4a2Yg2pw%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55bcc3c0-3fb3-4bc4-a728-9d4270797414n%40chromium.org.

[Yoav Weiss]

LGTM3

[Shuran Huang]

Thanks for the review. I will proceed with Mike's suggestion.

[Shane Hird]

I have run into this issue with Firefox, angular-js and protractor:

 

https://docs.angularjs.org/guide/bootstrap

"If window.name contains prefix NG_DEFER_BOOTSTRAP! when angular.bootstrap is called, the bootstrap process will be paused until angular.resumeBootstrap() is called."

It makes use of the ability to pass window.name and broke with Firefox's implementation of clearing this. I had to set 'privacy.window.name.update.enabled=false' to restore functionality.

Hopefully the feature can continue to be disabled for testing purposes.