Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57)

Replying to [this comment](https://github.com/w3c/deviceorientation/issues/57#issuecomment-459979734) from @geoffreygaren:

>> Everything being discussed is a shade of that argument that there is, with certainty, a level of default access available that provides enough privacy and security protections while not completely disabling current uses.
> 
> Can you cite some evidence to support your assertion that obfuscation, quantization, and frequency reduction solve the privacy and consent problem?

Empirical evidence for the case for obfuscation, quantization, and frequency is, I agree, important to proceed. If those approaches are capable of eliminating all privacy and security concerns then the consent problem is also taken care of implicitly. We are in the current predicament due to the lack of clarity within existing studies on the exact protections that would eliminate personally identifiable data concerns. Existing studies do not go far enough in evaluating the full effects that obfuscation, quantization, and frequency can have on eliminating personally-identifiable information from sensor data and, thus, eliminating fingerprinting. However, it remains equally disappointing to see a progressive, pro-active approach based on further investigation being dismissed in favor of a quick short-term solution.

In [Bojinov-Boneh-Michalevsky-Nakibly](https://crypto.stanford.edu/gyrophone/sensor_id.pdf), Section 6.1 states the following:

> " In contrast to audio-based fingerprinting, there is no
good way to feed a signal into the accelerometer, namely
exert a known acceleration force; instead we take an
approach of performing background measurements and
waiting until there is enough data to estimate the accelerometer
calibration parameters. We perform a measurement
every time the phone is at a resting position, or
more precisely, the phone is at a constant velocity (no acceleration).
Note that in most reasonable cases it is very
unlikely that a phone will not be at rest for an extended
period of time. Detecting the phone is at rest is relatively
straightforward: the measured acceleration vector should
be static and its magnitude should roughly be equal to `g` 
(gravity). "

Figure 6 in that same paper provides a scatter plot of all z-axis accelerometer data that is collected from 17 iOS devices when they are placed at rest on a table (i.e. the device has no velocity in any axis thus fulfilling the required calibration environment requirements as explained in the quote above). 

All the iOS devices in that study present unique `g` values that fall within in the range `[0.993, 1.004]`. That study showed that `devicemotion` data is potentially fingerprintable based on those discrepancies between different devices (although many devices reported values do overlap with each other within that same range).

In a [previous comment above](https://github.com/w3c/deviceorientation/issues/57#issuecomment-459302243) I suggested _obfuscation_ as follows should be added to emitted `devicemotion` data:

> * Add a random constant in the range ... [-0.005, 0.005] to all `devicemotion` data on each new invocation of the API.

By applying these obfuscation values to the data collected in that study, that data from 17 devices becomes indistinguishable from any subsequent invocation of the `devicemotion` API on the same device OR any invocation of the `devicemotion` API on any other device. Where the term "fingerprint" is defined as a means to identify and then re-identify a user on a subsequent visit due to consistencies in readings, this API would become useless for the purposes of ongoing identification of devices or users between visits.

Finally, in the same [previous comment above](https://github.com/w3c/deviceorientation/issues/57#issuecomment-459302243), I continued that discussion around obfuscation with the following:

> Optionally adjust that value during idle periods of inactivity for dynamic obfuscation (when e.g. the device is placed on a table).

Implementing this additional protection goes even further to prevent any fingerprinting from occurring within the same continuous, long-running stream of `devicemotion` data collected on a device. It does this by adjusting the obfuscation constant marginally (by a much smaller value) whenever the device is detected to be at rest (e.g. placed on a table or held still with no exerted velocity in any axis).

Finally, the presence or absence of any obfuscation constant in this data does not affect general calibration of `devicemotion` sensor data. Calibration of device sensors is performed under the same conditions as described above (when no velocity is present in any axis) - at which point we can estimate the calibration offset from earth's precise gravitational constant of 0.980665 (9.81 m/s^2) on each invocation.

In [this comment](https://github.com/w3c/deviceorientation/issues/57#issuecomment-459818413), @geoffreygaren wrote:

> Or, if the solution is as simple as you say it is, you might as well just code it up and we can test it empirically.

In WebKit, the most trivial code change would be to add a per-instance-bound obfuscation constant (`CURRENT_OBFUSCATION_CONSTANT`) in the range `[-0.005, 0.005]` to the collected gravitational values on [these lines](https://github.com/WebKit/webkit/blob/c3ad6ddc321cc9a1cc99016cd1ae1dff25049a10/Source/WebCore/platform/ios/WebCoreMotionManager.mm#L238-L240):

```diff
- totalAccel.x = userAccel.x + gravity.x;
+ totalAccel.x = userAccel.x + (gravity.x * (1 + CURRENT_OBFUSCATION_CONSTANT));
- totalAccel.y = userAccel.y + gravity.y;
+ totalAccel.y = userAccel.y + (gravity.y * (1 + CURRENT_OBFUSCATION_CONSTANT));
- totalAccel.z = userAccel.z + gravity.z;
+ totalAccel.z = userAccel.z + (gravity.z * (1 + CURRENT_OBFUSCATION_CONSTANT));
```

A basic patch of this type would provide enough initial protection to eliminate the majority of fingerprinting capabilities of this API being discussed.

---

By applying just 'obfuscation' initially would indicate effective removal of the ability to fingerprint devices/users via `devicemotion` if those fingerprinting attack vectors rely on any form of "at rest" calibration process. Other attack vectors (such as measuring the sensitivity of sensor data readings) could be mitigated easily with quantization protections.

The entire concept of [spatial computing](https://medium.com/@victoragulhon/what-is-spatial-computing-777fae84a499) on the web is at stake (i.e. motion as a basic input driver to rival mouse, keyboard and touch input drivers). Basic input drivers should not be subject to permission-based access controls (by all means, all other sensor APIs belong behind permissions but absolutely not motion motion and orientation sensor access).

Regarding battery life, a reduction in the frequency of event firing would materially reduce the amount of event collection and propagation required within a web browser's code. Execution of those code paths would be reduced by a factor of 50%+ (e.g. when moving from firing of events from 60 FPS to 30 FPS). Anything >= 15 FPS is still entirely acceptable for the use cases documented within this specification (i.e. non-VR/AR use cases). For use cases that require high-resolution data (at greater accuracy and delivered at higher frequencies) such as the use of motion and orientation sensor data within VR/AR scenes there are other, more suitable, APIs that should be implemented, gated with permissions and used by web developers (Generic Sensors API, WebVR API, WebXR API). Those APIs, obtained via permissions, should remain unencumbered with any forms of obfuscation, quantization, and frequency capping or limiting.

All of this is to say: we do still need more _independent_ feedback on the effectiveness of these mitigations before pushing existing and future spatial computing use cases off a cliff. The most reasonable approach at the current time would be for Apple to implement a simple form of obfuscation as explained above in WebKit code and to also enable the "Motion and Orientation Sensors" setting by default with those protections implemented in an upcoming release. This would provide initial protections and mechanisms to eliminate the most egregious fingerprinting attack vectors, as identified in existing sensor privacy studies, while still allowing on-going research to continue in to additional protections that could be added on an ongoing basis in the future. This approach allows Apple and other browser vendors to continue to research, tweak and adapt sensor privacy protections in future releases while still actively preventing fingerprinting in the immediate short-term. In any other approach we are simply stating that spatial computing use cases on the web are immaterial to this discussion, spatial computing as a concept and basic input has no place or future on the web and spatial computing use cases will be eliminated as collateral damage when building more walls around access to this data instead of focussing on eliminating personally-identifiable features from that data instead. The stakes of this discussion and the course of action being taken here to add permissions or otherwise restrict access to data _warrants extreme caution_. Nobody will stop browser vendors from their current course of action but I simply wish that the impact and loss to open motion access to the web was clearly understood in the context of the elimination of spatial computing uses (to the benefit of native applications).


-- 
GitHub Notification of comment by richtr
Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/57#issuecomment-461474245 using your GitHub account

Received on Thursday, 7 February 2019 15:38:07 UTC