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

556 views
Skip to first unread message

Shuran Huang

unread,
Mar 31, 2021, 4:36:11 PMMar 31
to blin...@chromium.org

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:



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

unread,
Apr 1, 2021, 4:44:45 AMApr 1
to blink-dev, Shuran Huang
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:



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

unread,
Apr 7, 2021, 3:49:45 PMApr 7
to Yoav Weiss, blink-dev
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:



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

unread,
Apr 22, 2021, 3:10:16 PMApr 22
to Shuran Huang, Yoav Weiss, blink-dev
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

unread,
Apr 23, 2021, 2:39:54 PMApr 23
to Mike West, Yoav Weiss, blink-dev
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

unread,
May 6, 2021, 2:21:07 PMMay 6
to Shuran Huang, Yoav Weiss, blink-dev
Ping. Were you able to make progress with regard to tracking down usage anecdotes to better understand possible compat issues?

-mike

Rick Byers

unread,
May 6, 2021, 4:30:56 PMMay 6
to Mike West, Shuran Huang, Yoav Weiss, blink-dev
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

Shuran Huang

unread,
May 7, 2021, 2:05:56 PMMay 7
to Mike West, Yoav Weiss, blink-dev
Hi Mike, 

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

Thanks,
Shuran

Shuran Huang

unread,
May 18, 2021, 12:58:06 PMMay 18
to Mike West, Yoav Weiss, blink-dev, Rick Byers
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

unread,
May 19, 2021, 5:20:54 AMMay 19
to Shuran Huang, Mike West, blink-dev, Rick Byers
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

unread,
Jun 3, 2021, 6:24:54 PMJun 3
to Yoav Weiss, Mike West, blink-dev, Rick Byers
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

unread,
Jun 10, 2021, 3:15:35 PMJun 10
to blink-dev, Shuran Huang, Mike West, blink-dev, Rick Byers, Yoav Weiss
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

unread,
Jun 10, 2021, 3:16:27 PMJun 10
to Mike West, blink-dev, Shuran Huang, Rick Byers, Yoav Weiss
LGTM2

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

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

unread,
Jun 10, 2021, 3:49:53 PMJun 10
to Chris Harrelson, Mike West, blink-dev, Shuran Huang, Rick Byers
LGTM3

Shuran Huang

unread,
Jun 14, 2021, 10:53:42 AMJun 14
to Yoav Weiss, Chris Harrelson, Mike West, blink-dev, Rick Byers
Thanks for the review. I will proceed with Mike's suggestion.
Reply all
Reply to author
Forward
0 new messages