http://ip-check.info detects browser window size with JS disabled
STR:
- Disable JavaScript by setting
javascript.enabledtofalseinabout:config - Restart Tor browser (or use new identity)
- http://ip-check.info and "Start test!"
- New identity
- Resize window
- Repeat step 3
Result:
(I don't know how exactly but) Browser window size is detectable.
*(tested also in ungoogled-chromium with JS disabled - same result: window size detectable)
Activity
Replying to cypherpunks:
Yes, CSS can do this, too.
But how can CSS send back an HTTP request to the website, containing the info? It has no XHR capabilities. Based on the requests sent to the server for each different background, https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html
Replying to cypherpunks:
Thanks for the example. Hm. What would be the way to avoid this please? Block images? Block iframes? Anything else? (use lynx? :P) The only way is to use the default settings of the Tor Browser, chances are many other people have the same default browser size as you.
Actually the chances (or rather the statistics) that many other people use Tor Browser at all compared to the number of non-TB users are very small. So relying on the fact that most of them never resize their browser window (which sounds unlikely) is also questionable.
This needs serious investigation, not just flippant closing as a "non-bug". It may not be a bug but indeed but it is an easy way to fingerprint users.
Actually the chances (or rather the statistics) that many other people use Tor Browser at all compared to the number of non-TB users are very small.
non-TB users are de-anonymized by default so you shouldn't even take them under consideration.
Please reconsider with an option to block @media queries or otherwise mitigate the effect of them.
Breaks a lot of sites, at best it's something to consider for the long term.
Replying to cypherpunks:
Breaks a lot of sites
So does disabling JS but when anonymity is top priority usability backs off. Having it as an option in "Safest" security level would fit. JS is enabled by default and the security slider is, well, a "security" slider, the stuff that is disabled depends (among other things) on the number of CVEs that impact a certain thing, no such procedure may exist for the
@mediaCSS component, but yes it does exist for the JS interpreter.There is no slider any more (UI-wise), just 3 options.
no such procedure may exist for the @media CSS component
Why? If it is possible to block browser window size detection, it should be possible to make it an option. Or are you saying that what was made possible (someone wrote code about it) cannot be unmade or put into conditional logic?
Blocking JS can thwart methods used to get entropy but the threat from CSS is not the same. JS is far more powerful.
When allowing JS (or CSS in this case), you always look at a worse case scenarios. Tor Browser should open at
1000pxx100sin height up to1000px. And you are not meant to resize. This limits the buckets Tor Browsers users are in. CSS @media is not the problem: the problem is users resizing their browser.Now we have letterboxing (in alpha), and the inner window will snap to
200sx100s(I'm simplifying: there's stepping sizes) and now users can resize their browser, go full-screen, toggle on/off the inspector, find bar, bookmarks toolbar, sidebar, etc. Go nuts with it! While their will be more "buckets" Tor Browser users fall into, it is still limited and increases usability.Letterboxing makes this issue about css
@mediaa moot point - no matter what you do, your css media inner window measurements will be protected (excluding as you transition from one size to another = not a leak). Please close the ticket.-
Replying to cypherpunks:
Then why is there no option that freezes the window size?
Because technically it was never feasible, and even if so, way too complex, because the browser size isn't the only thing to cause the inner window to change
It is the first time I read about this (letterboxing). Can you please share a link for more info?
It's easier if you just experience it.
Download Firefox 67+ (that's when it first landed, some fixes came later: e.g https://bugzilla.mozilla.org/show_bug.cgi?id=1546832 landed in FF69) and set
privacy.resistFingerprinting.letterboxing->trueload a web page and resize your browser: go fullscreen, maximize, manually resize it, flip the sidebar open, turn your toolbar on and off. Or alternatively, try Tor Browser alpha. Best illustrated with a website with a dark background, since the letterboxing is white. Replying to cypherpunks:
There is no slider any more (UI-wise), just 3 options.
no such procedure may exist for the @media CSS component
Why? If it is possible to block browser window size detection, it should be possible to make it an option. Or are you saying that what was made possible (someone wrote code about it) cannot be unmade or put into conditional logic? No, I meant that there are no CVEs related with some exploit that affects
@mediacontrary to the dozen ones that affect the JS interpreter.
Replying to cypherpunks:
Please reconsider with an option to block @media queries or otherwise mitigate the effect of them.
Rounding windows/letterboxing is the mitigation we have and there are no other ones planned/necessary.
Trac:
Resolution: N/A to not a bug
Status: reopened to closedUsing version 9.0.1 (based on Mozilla Firefox 68.2.0esr)
https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html still shows the variations in size when resizing browser window
Trac:
Resolution: not a bug to N/A
Status: closed to reopened-
Go to https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen - this has a bigger range and doesn't actually download any images (instead it inserts text), as it's just a PoC: thus it's way faster
Resize away with letterboxing on. Leaking sizes as you transition from one letterbox to the next is not entropy
Trac:
Status: reopened to closed
Resolution: N/A to not a bug -
Replying to cypherpunks:
... still detects resizing of the window.
once again.. returning sizes as you transition (resize) from one (letterbox) size to another is not entropy
Trac:
Status: reopened to closed
Resolution: N/A to not a bug
Severity: Critical to Normal -
Replying to cypherpunks:
But it detects a change of size (css inner window) also when you press CTRL+F or F12
That's how it works. If the inner window changes size (e.g. due to findbar, docked dev tools, full-screen, sidebar, etc), then of course the change can be detected. The change from one size to another is not entropy. These changes happen with and without letterboxing. Letterboxing controls the size you END up at.
Trac:
Resolution: N/A to not a bug
Status: reopened to closed https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen
now shows 1000x900 (with default Tor browser windows size)
Why is it not 1000x1000 as it was?
-
Replying to cypherpunks:
https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen
now shows 1000x900 (with default Tor browser windows size)
Why is it not 1000x1000 as it was?
It's only reporting exactly what you have. I would guess that it's because letterboxing is enabled (by default), and you have your toolbar showing and due to a bug, this causes the height to short by a few pixels - hence it falls back to 900 high
-
Replying to cypherpunks:
This got closed with "not a bug" now you say "due to a bug". Confusing.
This ticket (31206) is not a bug: css can be used to get measurements Ticket #27845 (moved) is a bug and has nothing to with how css is used
You asked why it was 1000x900 and not 1000x1000: and I pointed out #27845 (moved) as the likely cause (together with letterboxing = why it would snap the viewport to 900)