Opened 4 years ago

Closed 4 years ago

#13025 closed defect (fixed)

Lie about the screen orientation

Reported by: mikeperry Owned by: gk
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: ff31-esr, tbb-easy, tbb-fingerprinting, TorBrowserTeam201410Easy, tbb-testcase, MikePerry201410R
Cc: gacar@…, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Screen orientation is now exposed as a JS property: https://developer.mozilla.org/en-US/docs/Web/API/Screen.orientation

We should probably make this property lie.

Child Tickets

Change History (21)

comment:1 Changed 4 years ago by mikeperry

Keywords: tbb-easy added

comment:2 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201409Easy added; TorBrowserTeam201409 removed

comment:3 in reply to:  description Changed 4 years ago by gk

Replying to mikeperry:

We should probably make this property lie.

What do you mean here? Giving always the same value back or just not the one the user is actually having?

comment:4 Changed 4 years ago by gk

Keep in mind

Right now screen.mozOrientation, screen.orientation, DeviceOrientationEvent, and related web API things are not spoofed in Tor Browser.

(via Arthur's #12924).

comment:5 Changed 4 years ago by gacar

I guess TBB should return the same (and the most common) value for everyone, which would be landscape-primary.

It seems Screen.orientation is still behind a moz- prefix in ESR31 and could be easily patched: `nsScreen::mozOrientation`.

comment:6 in reply to:  5 Changed 4 years ago by gk

Replying to gacar:

I guess TBB should return the same (and the most common) value for everyone, which would be landscape-primary.

That's the idea I had as well.

comment:7 Changed 4 years ago by gacar

Cc: gacar@… added

comment:8 Changed 4 years ago by gacar

What about DeviceOrientationEvent?
Should we just prevent firing of these events?
For instance in nsEventDispatcher or in nsDeviceSensors?

comment:9 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201410 added

comment:10 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201410Easy added; TorBrowserTeam201409Easy removed

comment:11 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201410 removed

comment:12 Changed 4 years ago by gk

Owner: changed from tbb-team to gk
Status: newaccepted

comment:13 Changed 4 years ago by gk

Keywords: tbb-testcase MikePerry201410R added
Status: acceptedneeds_review

bug_13025 in my tor-browser repo has the fix. I've tested it with

xrandr --output <your-output> --rotate left

In the webconsole 'landscape-primary' showed up then and on the scratchpad in a chrome context 'potrait-primary'.
The remaining parts of the API, like screen.orientation and orientationchange events are not exposed in desktop environments and thus no problem for us AFAICT.

I still need to think about a good way for testing this within our testing framework. This might therefore make it into a separate ticket...

comment:14 Changed 4 years ago by mikeperry

Ok, well I merged this into tor-browser-31.1.1esr-4.x-1, so it should appear in the next nightly.

comment:15 Changed 4 years ago by mcs

I should have mentioned this a while ago; sorry. Or maybe I'm wrong.
In my opinion, we shouldn't always answer the same thing. Instead the answer should be determined from the "screen size" (which is faked from the window size). If a site asks for screen size and is given portrait dimensions, wouldn't it make sense to also return portrait for orientation?

comment:16 in reply to:  15 Changed 4 years ago by gk

Replying to mcs:

I should have mentioned this a while ago; sorry. Or maybe I'm wrong.
In my opinion, we shouldn't always answer the same thing. Instead the answer should be determined from the "screen size" (which is faked from the window size). If a site asks for screen size and is given portrait dimensions

What is triggering the potrait dimensions here? The actual (i.e. vertical) screen? If so, this is #11439 I'd say and we need to decide how to fix that one. If we say "vertical screens should get dimensions similarly to horizontal screens to blend more into this group" then "landscape-primary" is the best choice. If we want to make own buckets for people with vertical screen layout then I'd agree with you.

comment:17 Changed 4 years ago by gacar

I think the number of users with the vertical monitor setting may not be big enough to create a meaningful anonymity set.

My primitive calculations with the Panopticlick data showed that enforcing a cutoff for the screen height (as TBB currently does for the width > 1000px) reduces the overall entropy of TBB-resized screens from 2.63 to 1.28 bits, and # of buckets from 43 to 13.

https://github.com/gunesacar/tbb-fp

Per pde's suggestion, I'll rerun these simulations after removing the possible TBB users from the raw data (to prevent double-resizing). Also, I plan to add some % of users with maximized screen size to the distribution. A related idea came up during the meeting with Mike was to resize the TBB window in a way to cover the users with maximized TBB windows.

Here's the list of 10 most common screen dimensions after being resized by the current algorithm.
Basically this the result of the following: take the screen dimension distribution from Panopticlick database, resize them as TBB would do, measure the entropy, number of buckets etc.

WxHxColor_depth, Frequency (Top ten)
==============
('1000x600x24', 426073),
('1000x900x24', 293909),
('1000x800x24', 233138),
('1000x700x24', 198246),
('1000x1000x24', 142745),
('1000x400x24', 33037),
('1000x500x24', 16585),
('800x400x24', 7835),
('1000x1400x24', 7350), V
('1000x1300x24', 6246), V

WxHxColor_depth, Frequency (Verticals, i.e. Height > Width)
==============
('1000x1400x24', 7350), V
('1000x1300x24', 6246), V
('1000x1100x24', 2216), V
('1000x1700x24', 1126), V
('1000x1500x24', 874), V
('1000x1200x24', 171), V
('1000x1900x24', 60), V
('1000x1600x24', 48), V
('600x1100x24', 22), V
('1000x1800x24', 21), V
('1000x2400x24', 15), V
('1000x2200x24', 14), V
('1000x2100x24', 6), V
('1000x5100x24', 4), V
('1000x9800x24', 3), V
('1000x3200x24', 3)] V

comment:18 Changed 4 years ago by brade

(Ooops! I didn't realize mcs had last used trac on this computer; I posted comment 15)

gk: I'm just arguing for consistency between this orientation property and the rest of the Screen object. It is reasonable for 1000w X 1400h to be recognized as a portrait screen. I can imagine that two web sites might have different approaches for layout -- one site depends on screen orientation and the other looks at the screen dimensions. In this case, it would be make sense to be consistent.

For bug #11439, I think we should look into capping window height similar to what gacar says that we do for window width.

comment:19 Changed 4 years ago by brade

Cc: mcs brade added

comment:20 Changed 4 years ago by KarelBilek

As I wrote here #13636 I have to confirm that it's happening to me and fingerprinting me.

The "screen size" is indeed faked from the window size.

On my PC I have turned off the JS until this is resolved

edit: oh, I misread, this is about orientation. Well, screen size is fingerprinting me anyway.

Last edited 4 years ago by KarelBilek (previous) (diff)

comment:21 Changed 4 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Well, we merged gk's fix to lie about the orientation, but clearly there still are deeper issues here. I filed #13650 for the vertical height vs orientation problem.

Note: See TracTickets for help on using tickets.