Opened 3 months ago

Last modified 2 weeks ago

#30542 new defect

pinch-to-zoom viewport vs other screen/window

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 3 months ago.
top=TB desktop, bottom=FFondroid+RFP

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 months ago by Thorin

why can't I edit the initial bug ..

Control - should be not hidpi or whatever

Changed 3 months ago by Thorin

Attachment: examples.png added

top=TB desktop, bottom=FFondroid+RFP

comment:2 Changed 3 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 3 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 3 months ago by gk

Keywords: tbb-mobile added

comment:5 Changed 8 weeks 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 8 weeks 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 8 weeks ago by Thorin (previous) (diff)

comment:7 Changed 6 weeks 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 6 weeks ago by gk

Description: modified (diff)

comment:9 Changed 6 weeks ago by gk

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

comment:10 in reply to:  7 Changed 6 weeks 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 2 weeks ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

Note: See TracTickets for help on using tickets.