Javascript can create/resize windows to consume the entire desktop

added MikePerry201408R component::applications/tor browser owner::mikeperry priority::high resolution::fixed status::closed tbb-fingerprinting tbb-firefox-patch tbb-pref tbb-testcase type::defect labels

Trac:
Cc: N/A to g.koppen@jondos.de

window.sizeToContent is potentially another vector for this, and mozilla already introduced clamping for it in https://bugzilla.mozilla.org/show_bug.cgi?id=764240. We may be able to adapt that clamping to apply to other types of resizes, too.

Trac:
Cc: g.koppen@jondos.de to gk
Keywords: N/A deleted, tbb-testcase added

What platforms limiting maximum window size? I know Windows since XP limiting window size, but allowing to bypass restrictions with some tricks. If no window size limits then no fingerprinting can be done, attacker will request over9000 window and will get it.

Mozilla broken limits for windows even, it happened by fix for https://bugzilla.mozilla.org/show_bug.cgi?id=783333 It's already in current releases and will be in next ESR. Not sure if they wanted that, but it is.

What do you think?

Why to allow window resizing at all? If valid popup then why it should be with different size, why need to create yet one properties to identify users?

To disable resizing need to change dom.disable_window_move_resize to true by default. That's all.

If valid popup then why it should be with different size, why need to create yet one properties to identify users? Btw, it's hard to do anyway. Any valid popups will be rounded by Torbutton anyway. Resizing possible with tricks and fraud only. Yet one reason to disable resizing in general.

Trac:
stopresizing.diff

dom.disable_window_move_resize is true by default

Trac:
Status: new to needs_review

Trac:
Keywords: N/A deleted, GeorgKoppen201404R added

Replying to cypherpunks:

If valid popup then why it should be with different size, why need to create yet one properties to identify users? Btw, it's hard to do anyway. Any valid popups will be rounded by Torbutton anyway. Resizing possible with tricks and fraud only. Yet one reason to disable resizing in general.

Looking at a bunch of Mozilla bugs (299424, 309251, 328492, 454779...) it seems Mozilla got bitten by that change in the past. While I personally agree with you that resizing the window after Torbutton rounded it properly might be a sign of malicious behavior I may just surf the wrong websites :) That said: What worries me more is disallowing the moving of popup windows. That seems something to me that is not problematic from a fingerprintability perspective, yet it would be forbidden with your patch as kind of collateral damage. And here I can think of useful scenarios, even if i am currently not aware of a site that moves its popups. I need to think about it more and would like to get other opinions.

And here I can think of useful scenarios, even if i am currently not aware of a site that moves its popups. To move it need to know where to move, but patches to Firefox code makes it impossible to know about real screen and offset coordinates from point of view of website. It's like to move window about size of all avail space of screen, any moves leaves part of window out of useable screen. What useful scenarios to move window out of screen?

Actually I'm worrying about race conditions in between window.open(with height width defined) and resizing of window by Torbutton. Can site to have some information using this races?

Can site to have some information Just tested, outerHeight (or any else size) properties just after window.open() returns requested or size to which was limited by platform. Fingerprinting works if size limited. If not limited than that fact leaked too. Fingerprints around. dom.disable_window_move_resize can't to fix it of course.

Torbutton rounds window size wrongly, too late and useless.

Worst thing that it is not even noticeable to user. Fingerprinting can work right now, but rounding by Torbutton hides it.

Wrong comment. Deleted

Replying to cypherpunks:

Actually I'm worrying about race conditions in between window.open(with height width defined) and resizing of window by Torbutton. Can site to have some information using this races?

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

Trac:
Keywords: N/A deleted, MikePerry201404R added

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

This bug is about window.open actually too. "Javascript can create"

Replying to cypherpunks:

That is a fine question. If there is indeed an issue could you file a new bug for it? Let's keep this bug for the "Javascript can create/resize windows to consume the entire desktop"-problem. Thanks.

This bug is about window.open actually too. "Javascript can create"

Ah, I see your point and it would defeat the currently proposed patch. Good idea. So, are you claiming in comment 12 that this is actually an issue? Do you have some example code to test this hypothesis?

<html>
<body>

<p>Click the button to open</p>

<button onclick="openWin()">Open Window</button>

<script>
function openWin()
{
myWindow = window.open("","","width=9000,height=9000");
var winW = myWindow.outerWidth;
var winH = myWindow.outerHeight;
alert(winW+"x"+winH);
}
</script>

</body>
</html>

This test lives on https://people.torproject.org/~gk/misc/entire_desktop.html now. Thanks. We need a new patch then it seems.

Trac:
Keywords: MikePerry201404R, GeorgKoppen201404R deleted, N/A added
Status: needs_review to needs_revision

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609 (moved):) full-screen-api.enabled = false, that should squash 'em all.

Changing status to needs_review because the first pref from comment:22 fixes the window.open() leak

Trac:
Status: needs_revision to needs_review

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609 (moved):) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted. Hrm, it seems we can't solve this properly with just setting some preferences...

And I still think we should not prohibit moving popup windows. There might be useful applications out there and moving popup windows does not seem to be a fingerprinting vector.

Replying to gk:

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609 (moved):) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted.

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

-- faether (sorry, can't open an account due to #12721 (moved))

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Set browser.link.open_newwindow.restriction = 0 to open all popups as tabs, ignoring any sizes. Together with dom.disable_window_move_resize = true, and (see #12609 (moved):) full-screen-api.enabled = false, that should squash 'em all.

Giving the preference modifications belonging to this bug a quick shot I have found one machine where the test in comment:21 got not properly rounded window dimensions extracted.

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked. This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

And this still works even though https://bugzilla.mozilla.org/show_bug.cgi?id=565541 got fixed long ago? Do you have a) example code showing this and b) how is this related to the bug at hand?

Replying to gk:

Replying to cypherpunks:

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked.

Huh. That sounds interesting. Just so I really understand it right,

You started a clean Tor Browser on the test machine,
its initial window had a correctly rounded size A,
you set browser.link.open_newwindow.restriction = 0,
went to the test page from comment:21 and clicked "Open window",
it did not open a new window, but a new tab in the initial window,
but the test still reported size B, with B != A?

If that's the case, can you tell me the test machine's OS etc.? I'd like to reproduce it.

Here (Linux, fresh TBB installation), browser.link.open_newwindow.restriction = 0 causes the comment:21 test to open in a new tab in the main window and to show that main window's size, as it should.

[However, even if browser.link.open_newwindow.restriction = 0 does not work absolutely everywhere, we could still set it to protect most users?]

This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

See, now I'm confused again. When browser.link.open_newwindow.restriction = 0 is set and works, then the window-rounding code shouldn't even fire here because popups will never go to a new window.

Replying to gk:

And I still think we should not prohibit moving popup windows.

With browser.link.open_newwindow.restriction = 0 diverting all popups to tabs, dom.disable_window_move_resize = true would just stop remote moving and remote resizing of the user-opened windows.

And this still works even though https://bugzilla.mozilla.org/show_bug.cgi?id=565541 got fixed long ago?

Oh you're right, with browser.link.open_newwindow.restriction = 0 it's unnecessary to add dom.disable_window_move_resize = true. I've been using that latter pref for many, many years and hadn't even realized that things have improved. :)

Trac:
Username: faether

Replying to faether:

Replying to gk:

Replying to cypherpunks:

After setting the three prefs, did the test not open in a new tab? But its size was still unexpected?

It opened in a new tab but running the test in comment:21 trying to get some information out of the user showed at least on one testing machine that it worked.

Huh. That sounds interesting. Just so I really understand it right,

You started a clean Tor Browser on the test machine,

its initial window had a correctly rounded size A,

you set browser.link.open_newwindow.restriction = 0,

went to the test page from comment:21 and clicked "Open window",

it did not open a new window, but a new tab in the initial window,

but the test still reported size B, with B != A?

Yes.

If that's the case, can you tell me the test machine's OS etc.? I'd like to reproduce it.

It is an old netbook with two slow cores and 1GiB RAM running Debian testing. I did not see the issue on faster hardware. It is probably a race condition in our rounding-window-on-startup-nightmare. See #9268 (moved) for the remaining issues and why we need a Tor Browser patch.

[However, even if browser.link.open_newwindow.restriction = 0 does not work absolutely everywhere, we could still set it to protect most users?]

Maybe. So what is your proposed patch for this bug then just doing a browser.link.open_newwindow.restriction = 0?

This means, that the current code responsible for rounding the window dimensions does not cope with the use-case you have in mind.

See, now I'm confused again. When browser.link.open_newwindow.restriction = 0 is set and works, then the window-rounding code shouldn't even fire here because popups will never go to a new window.

I'd need to dig up the code but I think the new-window-logic is running as usual (+ the window-rounding code) but is encountering the request to open the content in a new tab in its course. This happens before the user is seeing anything on its screen. The result is: no popup window but a new tab.

So what is your proposed patch for this bug then just doing a browser.link.open_newwindow.restriction = 0?

Yes.

Plus full-screen-api.enabled = false to fix #12609 (moved) in the same release, ideally - and then ever onwards towards the next rounds of fingerprintability whac-a-mole... :)

Trac:
Username: faether

So who do you have to bribe to land these prefs? ;)

Seriously though, now there's TBB 3.6.4 and they're still not in... I'm not saying this to blame anyone, G*d bless y'all, but it feels like even simple anti-fingerprinting fixes are moving very slowly, and I'd be interested in what can be done about that.

Trac:
Username: faether

This one seems like a decent workaround to me. I am inclined to agree that fixing some instances of this are better than letting it go.

I am a little concerned about the usability of popups going to new tabs, but I think it is not terrible. At least, not as comparatively terrible as #12609 (moved)'s pref suggestion.

Gk - how do you feel about the usability aspects of this?

Trac:
Keywords: N/A deleted, MikePerry201408R, tbb-pref added

Replying to mikeperry:

This one seems like a decent workaround to me. I am inclined to agree that fixing some instances of this are better than letting it go.

Agreed. Nevertheless, I'd like to have a proper fix for this issue. I'll open a ticket for this once this ticket got fixed by switching the proposed pref.

I am a little concerned about the usability of popups going to new tabs, but I think it is not terrible.

Agreed.

Pref is set. Will appear in 3.6.5 and 4.0-alpha-2.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

#12979 (moved) is the bug for the real fix.

closed

mentioned in issue #12609 (moved)

mentioned in issue #12715 (moved)

mentioned in issue #12979 (moved)

mentioned in issue #17397 (moved)

mentioned in issue #23282 (moved)

mentioned in issue #31821 (moved)

moved to tpo/applications/tor-browser#9881 (closed)

mentioned in issue tpo/applications/tor-browser#12979 (closed)

mentioned in issue tpo/applications/tor-browser#31821 (closed)

Javascript can create/resize windows to consume the entire desktop

Child items ...

Activity