Open Bug 1542676 Opened 5 years ago Updated 2 years ago

Round subpixel accuracy of window properties to integers when resistfingerprinting is enabled

Categories

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

enhancement

Tracking

()

Tracking Status
firefox68 --- affected

People

(Reporter: gk, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor 26607][fingerprinting])

Starting with bug 1151421 some window properties give back subpixel accuracy on particular displays. We should make sure to round that to integers when resistfingerprinting is enabled to not give away the information about subpixel-capable display yes/no?

Downstream: https://trac.torproject.org/projects/tor/ticket/26607 including link for PoC

Type: defect → enhancement
Priority: -- → P3

This allows to calculate the real window.devicePixelRatio when privacy.resistFingerprinting is enabled, which is spoofed to 1 under that setting.

What we observed is that the measured window.scrollY is always a multiple of 1 / window.devicePixelRatio, and therefore assume that the scroll is done in physical screen pixels units which result in these subpixel CSS properties for HiDPI screens.

Would it be feasible/a good idea to make sure scroll does not leak screen DPI (like doing scroll in CSS pixels instead of screen pixels)?

Flags: needinfo?(botond)

(In reply to Alex Catarineu from comment #2)

Would it be feasible/a good idea to make sure scroll does not leak screen DPI (like doing scroll in CSS pixels instead of screen pixels)?

Are you looking to round to CSS pixels the amount of scrolling that's actually performed visually, or just the values reported via window.scrollX/Y?

Flags: needinfo?(botond)

It would be the first one. This not only can be read via window.scrollXY, but also with getBoundingClientRect() and similar. Even if it was possible to round all these properties, as Tom suggested an attacker could nudge elements until the value changed to recover the original subpixel value.

(In reply to Alex Catarineu from comment #4)

It would be the first one.

In that case, you'd probably want to perform the rounding here, as part of the adjustment from aPt to pt.

However, it's hard to predict what sort of side effects that might have.

Markus, can you think of anything offhand that such rounding would break? Otherwise, try it and see, I guess.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.