Opened 8 months ago

Last modified 8 months ago

#33541 new defect

fingerprinting: zoom.min/maxPercent should be fixed at 100

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Pressing Ctrl +/- results in detected window resolution different from 1000x1000 (test with which is a way to easier fingerprinting.

To avoid this zoom.minPercent and zoom.maxPercent must be set to 100.

Child Tickets

Change History (4)

comment:1 Changed 8 months ago by Thorin

Keywords: tbb-fingerprinting-resolution added
Priority: HighMedium

Site-specific zoom settings are disabled. And new windows/tabs always start with 100%. But any zoom set on a tab remains until reset/changed - even if the domain changes.

Zoom affects almost everything (as you can see from my test) - all the measurements, dpi, dppx, dpcm, devicePixelRatio etc, you can just use the size of an element.... and so on.

But, in general, everyone would be the same: i.e everyone starts at 1000x1000px, they zoom to 133% and everyone returns 750x750. There's no entropy here: edit: but.... sites don't measure zoom levels (see below), so in effect the entropy sites see is the change in measurements

I do not think disabling zoom is the answer: accessibility issues and different threat models and all that. But what could be tightened is that zoom is reset to 100% on a domain change per tab


Edit: BTW, it was a lot of work/testing to be able to correctly determine that zoom is used, and what that zoom is: and it's only usable on desktop, and I lack devices to fully test with different devicePixelRatios and dpi settings <-- tl;dr => no one is using it (see point above that zoom detection is not reliable/used)

If anything - it adds instability to the fingerprint to be able to link across domains/sessions (except for the same tab/same session issue). Anyone using inner window for FP'ing is doing it wrong anyway (unless measured in full-screen only: and even that's limited)

Last edited 8 months ago by Thorin (previous) (diff)

comment:2 Changed 8 months ago by cypherpunks

as you can see from my test

Where is that test to be seen?

As for the rest: I know what you explained. However it is still better to fix things to 1000x1000 because zooming in/out is user behavior and that *is* fingerprintable (and user behavior will become more and more a target for FP, with more powerful AI etc). So the idea here to reduce the possibility of the user to make inadvertent mistakes. One can still change the zoom.* settings in about:config but then it is supposed that one knows better what one is doing.

comment:3 in reply to:  2 Changed 8 months ago by Thorin

Replying to cypherpunks:

as you can see from my test

Where is that test to be seen?

I'm the author of TorZillaPrint

As for the rest...

I'd have to check, but those two prefs wouldn't be enough (but would help, I guess). I think layout.css.devPixelsPerPx overrides this. My main concern is that it removes functionality. I get the point that users who repeatedly zoom (and if i understand it correctly, they would have to consistently do it on new windows, new tabs, new sessions: and probably need to hit the same zoom level for precision tracking: and probably on the same sites: and the sites would have to bother fingerprinting this) could be a concern - but I think the threat is extremely low

In order to make that combination of events for end users even harder: tighten zoom resistance to include domain changes per tab: i.e zoom once, keep re-using that tab and your inner window dimensions are currently "broken" consistently across domains for as long as you use that tab

This is the better solution IMO, and in fact solves the problem you describe (I can't imagine anyone putting up with having to zoom everything all the time: they would be using system accessibility options or changing the OS's display sizes/dpi or whatever)


The ultimate solution, but I'm not entirely sure if it's feasible (or is but low priority and/or a lot of work), is that zoom could trigger letterboxing to re-calculate: but AFAIK zoom was explicitly left out in the RFP patch for technical/complexity issues (read ) <- I'll ping tom (tom is the letterbox author)

comment:4 Changed 8 months ago by tom

As I understand it, this ticket is saying "Hey, a user can manually choose to zoom the page, and when they do that, the resolution changes." (And a bunch of other stuff changes too, like device pixel ratio and dpi and you can detect the zoom percentage.)

The ultimate solution, but I'm not entirely sure if it's feasible (or is but low priority and/or a lot of work), is that zoom could trigger letterboxing to re-calculate

I don't understand what we would recalculate. When you zoom, the resolution of the browser stays the same, but from the website's perspective the resolution has decreased. The amount of information the website is (a) Original Resolution (b) Zoom Level. Everything else is - AFAICT - a calculation of those two components, so trying to hide (B) would require hiding it as it's exposed everywhere (e.g. device pixel ratio)

Note: See TracTickets for help on using tickets.