Open Bug 1579584 Opened 2 years ago Updated 1 year ago

Have window.outerHeight/outerWidth lie and report the innerHeight/innerWidth

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: tjr, Assigned: tjr)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-needed, site-compat, Whiteboard: [fingerprinting])

window.outerHeight/outerWidth are legacy properties that report the size of the outer window of the browser. By subtracting against innerHeight/innerWidth it exposes the size of the user's browser chrome which can be unique depending on customization, but at the least reveals non-standardized information that can be used for fingerprinting purposes.

Tor Browser (and RFP mode) has reported the values of innerHeight/innerWidth for outerHeight/outerWidth for a long time and I haven't seen or heard of any breakage caused as a result of that.

So I'd like to experiment with doing this on Nightly and seeing if we can identify any breakage. I considered adding telemetry for the properties; but reading them doesn't imply websites are relying on them for anything.

And I assume spoof window.screenX and window.screenY as window.mozInnerScreenX and window.mozInnerScreenY respectively?

Keywords: site-compat

Are there any valid uses for websites grabbing inner or outer X,Y coordinates at all? Why not spoof all four as 0?

Component: DOM: Bindings (WebIDL) → DOM: Core & HTML

Returning 0 for screen[X|Left|Y|Top] makes sense to me. Tor's approach of returning inner when accessing outer for the other attributes seems safer than returning 0, compatibility-wise.

Masatoshi raised the issue that window.resizeTo() could be abused as well. Presumably that also applies to resizeBy() and maybe move[To|By].

Once we've prototyped these changes and they seem sticky we should also open a discussion at https://github.com/w3c/csswg-drafts/labels/cssom-view-1 to tighten the definitions of these attributes standards-wise and get other browsers to align with us.

(Simon, as far as I know all use cases here are historical, related to an initial ambition of browsers to emulate/compete with X11.)

FWIW, this is in-progress but there are a ton of test failures I'm working through.

Priority: -- → P3

FWIW, on mobile environments window.innerHeight doesn't basically include the dynamic toolbar height, whereas CSS vh units includes the toolbar height, thus the toolbar height can be obtained by subtracting window.innerHeight from 100vh value.

AFAIK the toolbar height is stable in GV and doesn't reveal any entropy

yeah, but Fenix now has a preference to disable the dynamic toolbar (https://github.com/mozilla-mobile/fenix/issues/10240), then there is no difference between window.innerHeight and 100vh value, which, I guess, can be used to tell whether it's different from Chrome or Safari.

:hiro You can't hide the browser engine: there are literally hundreds thousands of detection points to do this: e.g error messages, math computations, even a simple if ("undefined" != typeof InstallTrigger) {console.debug("Hi Firefox user")}

Oh okay, TBH I am not familiar with regist-finger-printing area, so I maybe don't understand it though. Doesn't RFP try to obscure user's preferences then? Anyway, if the disabling the dynamic toolbar feature doesn't spoil RFP, that's good.

You need to log in before you can comment on or make changes to this bug.