Lie about the screen orientation

added MikePerry201410R TorBrowserTeam201410Easy component::applications/tor browser ff31-esr owner::gk priority::high resolution::fixed status::closed tbb-easy tbb-fingerprinting tbb-testcase type::defect labels

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

Trac:
Keywords: TorBrowserTeam201409 deleted, TorBrowserTeam201409Easy added

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?

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

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.

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.

Trac:
Cc: N/A to gacar@esat.kuleuven.be

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

Trac:
Keywords: N/A deleted, TorBrowserTeam201410 added

Trac:
Keywords: TorBrowserTeam201409Easy deleted, TorBrowserTeam201410Easy added

Trac:
Keywords: TorBrowserTeam201410 deleted, N/A added

Trac:
Status: new to accepted
Owner: tbb-team to gk

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

Trac:
Status: accepted to needs_review
Keywords: N/A deleted, MikePerry201410R, tbb-testcase added

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

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?

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

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

(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 (moved), I think we should look into capping window height similar to what gacar says that we do for window width.

Trac:
Cc: gacar@esat.kuleuven.be to gacar@esat.kuleuven.be, mcs, brade

As I wrote here #13636 (moved) 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.

Trac:
Username: KarelBilek

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

Trac:
Resolution: N/A to fixed
Status: needs_review to closed