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

366 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 PM (4 days ago) May 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 PM (4 days ago) May 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 PM (3 days ago) May 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
Reply all
Reply to author
Forward
0 new messages