Investigate fingerprinting capability of viewport API

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

added component::applications/tor browser in Legacy / Trac ff68-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac sponsor::44-can in Legacy / Trac status::new in Legacy / Trac tbb-fingerprinting-resolution in Legacy / Trac tbb-mobile in Legacy / Trac tbb-parity in Legacy / Trac type::defect in Legacy / Trac labels

why can't I edit the initial bug ..

Control - should be not hidpi or whatever

Trac:

top=TB desktop, bottom=FFondroid+RFP

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)?

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

Trac:
Keywords: N/A deleted, tbb-mobile added

Thanks Thorin. I see two problems here. The first is related to exact screen dimensions (legacy/trac#27083 (moved)) 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.

Trac:
Keywords: N/A deleted, tbb-parity added

Thanks sysrqb. I'm not worried about legacy/trac#27083 (moved) 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)?

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.

Trac:
Description: 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 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

to

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

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-resolution, ff68-esr added

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).

Adding Sponsor 44 to ESR68 tickets

Trac:
Sponsor: N/A to Sponsor44-can

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.

Trac:
Summary: pinch-to-zoom viewport vs other screen/window to Investigate fingerprinting capability of viewport API

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.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1514429
• https://bugzilla.mozilla.org/show_bug.cgi?id=1523541

mentioned in issue legacy/trac#31591 (moved)

moved from legacy/trac#30542 (moved)

added Bug label and removed 1 deleted label

added Android Fingerprinting Platform Parity labels and removed 1 deleted label