Investigate device sensor code for possible information leaks

Device orientation relative events got changed. We should make sure this does not introduce new fingerprinting vectors:

https://bugzilla.mozilla.org/show_bug.cgi?id=1205649

added TorBrowserTeam201705R component::applications/tor browser ff52-esr owner::tbb-team priority::high resolution::fixed severity::normal sponsor::4 status::closed tbb-7.0-must tbb-fingerprinting type::defect labels

Trac:
Keywords: ff52-sr deleted, ff52-esr added

Trac:
Summary: Investigate updated device orientation codeI for possible information leaks to Investigate updated device orientation code for possible information leaks

Adding tickets to our 7.0 ticket list

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Getting more tickets on our alpha radar.

Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added

Moving the investigation tickets to higher priority.

Trac:
Priority: Medium to High

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

Moving more tickets on our May 2015 radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201705 added

We do have fingerprinting protection for "screen orientation" and related events, but in fact we never introduced specific protection for "device orientation" events. We did, however, disable device sensor readings in general in #15758 (moved) by setting "device.sensors.enabled" to false. These sensors may include:

    TYPE_ORIENTATION = 0U,
    TYPE_ACCELERATION = 1U,
    TYPE_PROXIMITY = 2U,
    TYPE_LINEAR_ACCELERATION = 3U,
    TYPE_GYROSCOPE = 4U,
    TYPE_LIGHT = 5U,
    TYPE_ROTATION_VECTOR = 6U,
    TYPE_GAME_ROTATION_VECTOR = 7U

In TBB 7.0a3's JS console, I see four relevant APIs:

• DeviceLightEvent
• DeviceMotionEvent
• DeviceOrientationEvent
• DeviceProximityEvent

Despite the presence of these interfaces, the Mozilla code appears to suggest that disabling "device.sensors.enabled" should result in no such events being generated from sensor hardware, because sensor observers are never registered. Unfortunately I don't currently have a laptop with such sensors (do these exist?) so I can't do a manual test. Maybe we can find a hook for simulating sensor data.

Also, this should be a particularly useful thing to examine on Orfox. Ideally these sensors would be behind a permission that is requested if a content script calls, for example, addEventListener("deviceorientation", ...).

I have changed the title to cover all device sensor code.

Trac:
Cc: mcs, brade to mcs, brade, arthuredelstein
Summary: Investigate updated device orientation code for possible information leaks to Investigate device sensor code for possible information leaks

#21786 (moved) is related.

I did some experimentation using the following JS snippets within the developer console:

window.addEventListener("deviceorientation", aEvent => console.log(aEvent));
window.addEventListener('devicelight', aEvent => console.log(aEvent)); 

On a MacBook Pro, devicelight events are generated but only after I changed device.sensors.enabled to true and restarted the browser. deviceorientation events are not generated; I think those require an accelerometer.

There is a Boolean pref device.sensors.test.events that you can set to true to cause a fake sensor event to be generated (that happens the first time a sensor-related event listener is registered). This also has no effect if device.sensors.enabled = false.

On a Lenovo convertible laptop running Windows 10 (which supports rotation to all four screen orientations) I could not generate either event, even when in tablet mode. In Chrome I see one deviceorientation event but it does not contain useful data.

I am confident that all of these events are disabled by device.sensors.enabled = false. Search for mEnabled within dom/system/nsDeviceSensors.cpp.

We are beyond the alpha testing. Moving tickets for tbb-7.0-must.

Trac:
Keywords: tbb-7.0-must-alpha deleted, tbb-7.0-must added

I looked at the code in dom/system/nsDeviceSensors.cpp agree with mcs that these events are disabled by device.sensors.enabled = false. So I think we can close this ticket without any additional patch.

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added

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

closed

mentioned in issue #31084 (moved)

moved to tpo/applications/tor-browser#21609 (closed)