compat: make spoofed orientation reflect spoofed screen dimensions [1607032 + 1918202]

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-fingerprinting in Legacy / Trac tbb-mobile in Legacy / Trac type::defect in Legacy / Trac labels

Trac:

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

This one is tricky. I'm not sure if spoofing the device orientation is really important, but I think we should be consistent. We should either spoof all of these values or none of them.

Orientation wouldn't even be a stable metric, IMO: and most mobile device users would orientate the same per site: i.e it is driven by content? I've never seen it in any fp scripts, TBH.

I'm not hardware savvy: but do laptop and desktop support this, e.g with rotating screens. We could ignore android, and only apply orientation to win/mac/linux. i.e least apply landscape to css media orientation like we do for the two css media resolutions. matchMedia I'm not sure about. And their will be other methods, I'm sure.

Or we could not bother. Going full screen will leak orientation. A lot of desktop/laptop users (I assume, once letterboxing is implemented: even if that only enhances rather than replaces new win sizes) will go FS, maximize, or resize to match orientation to get real estate usage: i.e inner window = your orientation. So I think it may be a losing battle. I also wonder how much this may affect functionality on some sites. And lastly, the solution IMO is Tor uptake: e.g tripling the user base etc simplistically negates what we do here now.

+1 for not spoofing orientation

I'm not hardware savvy: but do laptop and desktop support this, e.g with rotating screens. We could ignore android, and only apply orientation to win/mac/linux. i.e least apply landscape to css media orientation like we do for the two css media resolutions. matchMedia I'm not sure about. And their will be other methods, I'm sure.

I tested with my Windows Surface tablet: yes desktop will reveal the orientation if you have it non-standard and yes there are open leaks where RFP doesn't work.

So this might be a WONTFIX for mobile (which I agree with) but it is an active open issue on desktop that makes a few people look quite unique. We should open a bugzilla bug for these if we don't have one...

open issue 1607032 css @media orientation/{device-}aspect-ratio and RFP
original uplift 1281949 screen.orientation should be spoofed when privacy.resistFingerprinting is enabled (Tor 18958)

https://developer.mozilla.org/en-US/docs/Web/API/Window/orientationchange_event

not supported in FF

https://developer.mozilla.org/en-US/docs/Web/API/Window/orientation

not supported in FF

https://arkenfox.github.io/TZP/tests/screenorientation.html

part 1: android

without RFP we get these values

note: my phone's natural orientation is portrait
portrait, portrait-primary, 0
landscape, landscape-secondary, 270
landscape, landscape-primary, 90
i can't get upside down

with RFP, we get these values

portrait, landscape-primary, 0
landscape, landscape-primary, 0
the landscape vs portrait diffs are the top four values
- -moz-device-orientation + device-aspect-ratio (using matchmedia)
- ^ and their corresponding css values (read by JS using pseudo values)
- the actual css values are also displayed
- the other 3 values are RFP protected

given android is made to fit the screen, the screen orientation (portrait vs landscape) is already given away by the inner window and screen dimensions and other various methods

given this I think we could/should make it more compat friendly to actually return

portrait, portrait-primary, 0
landscape, landscape-primary, 90

and nothing is lost

edit: the fact that the default (for phones with natural orientation of portrait) breaks web standards (portrait, landscape-primary, 0) is a red flag and we will be punished by it one day e.g. anti-fraud scripts

part 2: desktop

On page load, I run the code once and then add two eventListeners

The first is window.addEventListener('resize', function(){run('resize')})
The other one is screen.orientation.addEventListener('change', function(){run('change')})
I keep a running total of the last 4 events at the bottom

events

android triggers both events and resize is important for css to update it seems
desktop is a little whacky
- you can trigger the resize event
  - e.g. landscape width > allowed portrait width when changing to portrait - windows/or FF will resize the browser to fit
- otherwise, only the change event fires and this has a quirk:
  - all values update EXCEPT css (i.e the JS pseudo lookup values for them)
  - a re-run doesn't cut it, you need to do a page reload
  - we could probably insert new css rules each time, if we wanted, but this is not necessary
  - ^ we can infer it on desktop from the matchmedia results
  - ^ the css test is to confirm our patches work and to check for inconsistencies (in TZP) and this is now a known quirk
  - besides, on desktop we only use a resize event and this is would be enough to show entropy (tablets?)
- or based on testing, it doesn't matter about the change/resize - it's whatever the device is set up as

note: windows devices can also be swicthed into tablet mode if supported, with auto-rotate. My laptop doesn't have this

on windows the LL/LS/PP/PS are landscape, landscape flipped, portrait, portrait flipped

test 1

without RFP
- restarting FF in between (to see if the "natural orientation" requires a restart or means anything)
- starting the browser in LP each time, resize event firing / page reload
- starting the browser in PP each time, resize event firing / page reload

	LP: landscape,   0, landscape-primary
	LS: landscape, 180, landscape-secondary 
	PP: portrait , 270, portrait-primary
	PS: portrait ,  90, portrait-secondary

so regardless of the starting type or what the laptop has set for the "natural orientation"

the four types seem to be hardcoded to 0, 180, 270, 90 respectively, although the spec is a little hard for me to follow
https://w3c.github.io/screen-orientation/#the-current-screen-orientation-type-and-angle
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/screen-orientation/orientation-reading.html

so, AFAICT we can now just test and see what happens with RFP

and no matter what I do, in any orientation, RFP desktop is always a1de035c [RFP desktop] successful

summary

android isn't leaking any entropy that isn't a dead giveaway that we can't hide, but we should fix RFP to allow portrait-primary + ~~270~~ 0 as well for compat/future-footguns
desktop is fine
tablets I think are fine
note: desktops/tablets in fullscreen (which we do not hide and can use inner measurements to infer the device orientation) on a portrait device will look silly but that's OK, it's always been like this, and we don't encourage FS. Even maximized can leak this inference. That's OK

I am a little confused as to why android and desktop are different - where is this in the code? cc @pierov @tjr

Now the nitty gritty

tablets, e.g. windows devices can have a tablet mode - I do not have a tablet capable device (buy me one please @richard so my test lab is complete)
I suspect it behaves the same as desktop which means .. how would scripts know it's in tablet mode, for all intents and purposes it's a low res laptop?

So that's it - easy peasy, fixup android to allow for portrait-primary

Class, discuss!

https://searchfox.org/mozilla-central/source/testing/web-platform/tests/screen-orientation/orientation-reading.html


const expectedAnglesLandscape = {
	"landscape-primary": 0,
	"portrait-primary": 90,
	"landscape-secondary": 180,
	"portrait-secondary": 270,
};
const expectedAnglesPortrait = {
	"portrait-primary": 0,
	"landscape-primary": 90,
	"portrait-secondary": 180,
	"landscape-secondary": 270,
};

I don't understand this, in all my testing I could only get expectedAnglesLandscape, so I guess I'm missing something or some hardware

I don't understand this, in all my testing I could only get expectedAnglesLandscape, so I guess I'm missing something or some hardware

Windows (10) in tablet mode might trigger this? I should test on my Surface... Which I haven't turned on since the last test we needed I think .

I'm not even sure or where it is, let me check

android isn't leaking any entropy that isn't a dead giveaway that we can't hide

What about split screen? I don't think it's supported by AOSP, but some devices might support it in some proprietary way.

I should test on my Surface...

I tried with https://www.w3schools.com/css/tryit.asp?filename=tryresponsive_mediaquery_orientation2.

It really doesn't care of how I moved my device.

We can probably confirm that in code.

Which I haven't turned on since the last test we needed I think .

It had Firefox 112 and Tor Browser 12.0.5 .

but we should fix RFP to allow portrait-primary + 270 as well for compat/future-footguns

edited it - i think I have that angle wrong .. primary is always 0 or 90 .. and android without RFP was 0

https://www.w3schools.com/css/tryit.asp?filename=tryresponsive_mediaquery_orientation2

that works on my android (expected) although I had to pull to refresh a few times in each orientation before it kicked in, and I could auto-rotate and the colors changed

not sure what this achieves, as my test already auto-changes on android, but sure - tablet not the same then

Anyway, I think we can ignore real time changes and just focus on what is returned when we load a test. And I'd like someone else to confirm desktop in all four orientations returns a1de035c [RFP desktop]

What about split screen?

RFP already returns

1. portrait (css/matchmedia) + landscape-primary + 0 (RFP hardcoded)
1. landscape (css/matchmedia) + landscape-primary, 0 (RFP hardcoded)

So if you were an device with split screen IDK exactly

a portrait inner with landscape device you would still end up as 2? = stands out
a landscape inner with portrait device you end up as 1? = stands out

What I'm suggesting is to change the no. 1 for compat to

1. portrait (css/matchmedia) + portrait-primary + 0 (RFP hardcoded)

So if you were an oddball device with split screen IDK exactly.

a portrait inner with landscape device you would end up as 2? = stands out, no change
a landscape inner with portrait device you end up as 1? = stands out, no change

struggling here. We've always stood out with split screens, unless I'm missing something

still struggling to see where/how we patched desktop with matchmedia and css, since you said matchmedia can't be patched

moved from legacy/trac#30543 (moved)

added Bug label and removed 1 deleted label

added Android Fingerprinting labels and removed 1 deleted label

added Icebox label

added Roadmap::Future label and removed Icebox label

mentioned in issue #41747

changed the description

marked this issue as related to #42439

changed title from device orientation leaks to compat: device orientation vs screen

removed Android label

added All Platforms label

OK, so I'm going to change the scope of this.

We lie about the screen dimensions. We lie about device orientation. Sometimes these are at odds, because css + matchmedia are based on our spoofed screen measurements, whilst 'mozOrientation', 'orientation.angle' and 'orientation.type' aren't

This is a red flag, and in particular, really bad on android where most users would be portrait (I assume).

I propose that we spoof 'mozOrientation', 'orientation.angle', 'orientation.type' based on our screen lies

if our screen lie is square or landscape, return landscape-primary + 0
if our screen lie is portrait, return portrait-primary, 0
^ this does not leak any entropy that we aren't already providing, albeit it a lie (screen dimensions)
^ no more paradoxes

This also means the metric becomes less stable for fingerprinting, esp tablets and phones. Users on portrait devices with newwin sizes already stood out

Works for me.

this has landed upstream ... awaiting next nightly to test. We should backport it to TB (I don't think it's a major issue/breakage for upstream to backport it to ESR, it's just tidying up a potential footgun - but maybe they will if you ask @fkilic nicely)

Okay. If it's only for compat we can let it bake in Firefox nightly for a while.

upstream

So actually, I would prefer this was backported for TB since the benefit is for android which is the majority of our users. It also makes it easier for TZP's health check

Doesn't seem too risky to me, we can take it soonish.

Maybe we can wait a few days to let it bake a little bit in nightly and then take it.

also https://bugzilla.mozilla.org/show_bug.cgi?id=1922204 - my bad

changed title from compat: device orientation vs screen to compat: device orientation vs screen [1607032]

changed the description

compat: make spoofed orientation reflect spoofed screen dimensions [1607032 + 1918202]

Designs

Child items ...

Activity

part 1: android

part 2: desktop

summary