Opened 15 months ago

Last modified 8 months ago

#30542 new defect

Investigate fingerprinting capability of viewport API

Reported by: Thorin Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution, tbb-mobile, tbb-parity, ff68-esr
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor44-can

Description (last modified by gk)

I am not sure if this is an issue for TB. I do not have a touch device on which to install TB8. But since Tor Uplift's RFP underlines this protection, it might be prudent for someone to check it out.

My Android has a low screen res, the web content loads at a higher res - when I pinch to zoom and re-run/refresh: the viewport shows entropy. Ignore the css media measurements. Just focus on the five JS results: screen, available screen, outer, inner and viewport

Control

  • device should not be hidpi/retina/whatever-you-call-it
  • load test page [1]
  • all the widths/heights (except viewport: e.g 17px less width) should be the same (i.e 1000 x 1000)
  • zoom in to 133%
  • refresh or rerun button
  • all the widths/heights (except viewport e.g 13px less width) should be the same (e.g 750 x 750)

STR

  • device should be hidpi
  • load the test page
  • all the widths/heights (except viewport) should be the same (e.g 980 x 1522)
  • zoom in (fingers on a touch device)
  • scroll to the left and hit re-run tests
  • scroll back to the right and viewport is still based on the old value
  • also, in the pic in [2] css media still shows it's using the old values (980) (ignore that it's missing the height values: not sure why it does that: I think it's because it hits a fraction, I see the same thing on desktop)

Is this just a quirk? Or is the viewport not properly spoofed in all situations?

[1] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen
[2] https://github.com/ghacksuserjs/TorZillaPrint/issues/34

Child Tickets

Attachments (1)

examples.png (296.7 KB) - added by Thorin 15 months ago.
top=TB desktop, bottom=FFondroid+RFP

Download all attachments as: .zip

Change History (14)

comment:1 Changed 15 months ago by Thorin

why can't I edit the initial bug ..

Control - should be not hidpi or whatever

Changed 15 months ago by Thorin

Attachment: examples.png added

top=TB desktop, bottom=FFondroid+RFP

comment:2 Changed 15 months ago by Thorin

ignore the css: I was using width/height instead of min-width/min-height and likewise using device-width/device-height instead of min-device-width/min-device-height

So that just leaves why is the viewport spoofed on my desktop (FF/TB), but not my Android phone (FF+RFP)?

comment:3 Changed 15 months ago by Thorin

Actually, that only fixed zoom messing with the css output.

So css @media (width/height, device-width/device-height, min-width/min-height, min-device-width/min-device-height) and my viewport code don't get spoofed

comment:4 Changed 15 months ago by gk

Keywords: tbb-mobile added

comment:5 Changed 14 months ago by sysrqb

Keywords: tbb-parity added

Thanks Thorin. I see two problems here. The first is related to exact screen dimensions (#27083) and the other is inconsistency of reported values. On the webpage on Android, I see these are (approximately) the same (based on pinch-to-zoom level): screen resolution, available resolution, outer window, inner window, and view port. And these remain as the original values after pinch-to-zoom: [css] screen resolution and [css] inner window.

It seems like there isn't a feedback channel from the pinch-to-zoom function into the CSS engine (whatever that is). I also wonder if rounding the zoom level into buckets will help with this (in addition to any screen rounding and/or letterboxing we add). By this I mean on desktop, you can only zoom-in and zoom-out by fixed values, but pinch-to-zoom is relatively arbitrary. We can think about only allowing specific zoom levels.

And, as a side note, this seems partly broken with Firefox Nightly on Android, so we should test this after the 68esr rebase.

comment:6 Changed 14 months ago by Thorin

Thanks sysrqb. I'm not worried about #27083 here (and I used FF+RFP as TB for Android wasn't out at the time), just focused on second issue

On the webpage on Android, I see these are (approximately) the same (based on pinch-to-zoom level): screen resolution, available resolution, outer window, inner window, and view port

Not for me. They are radically different. If you look at https://github.com/ghacksuserjs/TorZillaPrint/issues/34 : css media is static, but the JS results change => indication of hidpi or something: maybe letterboxing kicking in solves this (I haven't tried yet)?

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

comment:7 Changed 13 months ago by tom

Ah so this is basically the Visual Viewport I just emailed about, suggesting we don't care about this.

The user behavior of zooming and panning can, in theory, give fairly good confidence that User A is *not* User B - because User A zoomed to 150% and User B zoomed to 200%. But to suggest that User B and USer C are the same because they both zoomed to approximately 200% - even if they panned in similar ways - seems waaaaaay too guessy to be a concern.

I'll also note that on Desktop, I don't beleive we stop the user from zooming in on a webpage which is essentially the same thing.

comment:8 Changed 13 months ago by gk

Description: modified (diff)

comment:9 Changed 13 months ago by gk

Keywords: tbb-fingerprinting-resolution ff68-esr added; tbb-fingerprinting removed

comment:10 in reply to:  7 Changed 13 months ago by Thorin

Replying to tom:

Ah so this is basically the Visual Viewport I just emailed about, suggesting we don't care about this.

My tests from OP were from <FF68 before the API landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1512813. I'm not sure if I got the issue right, TBH, and there isn't one

On desktop (admittedly my desktop is not touch capable) all metrics (js and css) stay in sync, on android they do not (where I can only use pinch to zoom).

comment:11 Changed 12 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:12 Changed 8 months ago by gk

Summary: pinch-to-zoom viewport vs other screen/windowInvestigate fingerprinting capability of viewport API

https://bugzilla.mozilla.org/show_bug.cgi?id=1575690 might be relevant here. Right now, this is a mobile-only feature https://bugzilla.mozilla.org/show_bug.cgi?id=1551302 being the desktop bug.

comment:13 Changed 8 months ago by Thorin

FWIW, I added a keyboard and toolbar height PoC on TZP (it only shows if you're using android) .. and it is a bit wonky: it depends if I can catch the window size with the toolbar showing (which should happen with new content), but sometimes it doesn't (latency?). Once you scroll and the dynamic toolbar hides, I can calculate a relative height. Same if you click in the text box to start typing

sysrqb had a plan for all this, but I haven't seen it yet. I'm concerned about keyboard height - I believe there's a lot of entropy there, and while it does require user gestures, it's not exactly easy for users to avoid using input fields. Maybe this needs it's own ticket?

There's also differences for when you move to Fenix/GeckoView; e.g.

Note: See TracTickets for help on using tickets.