access to orientation without access to linear acceleration?

[fergald]

According to https://w3c.github.io/sensors/#permission-api a page that wants to access orientation, must be allowed gyroscope and accelerometer. Relative orientation is not sensitive data, linear acceleration is but I cannot specify a policy that only allows relative orientation (I could access the gyroscope directly but not the higher level deviceorientation events API (at least not in chrome: https://cs.chromium.org/chromium/src/content/browser/generic_sensor/sensor_provider_proxy_impl.cc?q=SensorTypeToFeaturePolicyFeatures).

This seems like an undesirable outcome arising from the rule that fusion sensor permissions are transitive

https://www.w3.org/TR/generic-sensor/#permission-api

I don't think this is easy to fix this. Presumably someone with access to a fused sensor and 1 or 2 of the less sensitive inputs could derive the more sensitive input. Accounting for that seems more complex but could then lead to a more useful permissions system whereby the feature policies specify what information a page could access and the browser could then allow/deny sensors as a result. E.g. if you are only allowed have relative orientation information then you can have gyroscope or fused relative orientation but not both.

I'm suggesting that's easy but having everyone request acceleration just to get orientation seems counter-productive.

[anssiko]

Thanks @fergald. The current model is a balancing act between developer ergonomics, privacy, and implementability (how the permissions map to corresponding platform APIs).

Adding @snyderp to comment on sensitivity of relative orientation from privacy perspective drawing from the latest research and also to get PING's recommendation.

For more context on relative orientation in general, you may find our explainer helpful.

[pes10k]

Hi, not sure how I can help here other than:

1. Relative orientation is sensitive data, since it seems very likely that you can fingerprint a device w/ very high fidelity using these values (if im following correctly)
2. In general finer grained permissions are preferable, though not so much so that it has to boil down to a "accept all"
3. The W3C policy is that user needs are strictly more important than implementor and developer needs, so standards must reflect that
4. It would be good if standards were stricter about when folks could ask for permission (e.g. only top frame, after user gesture, etc) so permissions wouldn't need to be the primary access gating mechanism

[fergald]

Hi, not sure how I can help here other than:

I've reordered your points in what I think are priority order but left the numbers alone.

3. The W3C policy is that user needs are strictly more important than implementor and developer needs, so standards must reflect that

Right. I feel like a user needs control over what information they are sharing, not over which specific bits of hardware involved in producing that information (they may want that too for e.g. battery saving purposes). The current permissions are easy for the browser implementor because they are in terms of common hardware. They are not easy for the user (how many users understand that access to the magnetometer leaks location information?).

A solution to this would actually put a lot more burden on the implementor, forcing them to figure out what combinations of sensors leak what information.

2. In general finer grained permissions are preferable, though not so much so that it has to boil down to a "accept all"

The current permissions are not fine grained. To access relative orientation, I must request gyroscope and accelerometer. So as a user, to grant access to how much I have rotated my device I must also grant access to how much I have moved it in space. Granular permissions would allow me to give access to the orientation result without sharing any information about my spatial movements. "accept all" is what we have now - an app that wants to know which way is North needs access to 3 sensors.

1. Relative orientation is sensitive data, since it seems very likely that you can fingerprint a device w/ very high fidelity using these values (if im following correctly)

How do you fingerprint a device with relative orientation? "describes the device's physical orientation without regard to the Earth's reference coordinate system". No fixed base implies that a browser can select a random base orientation and give 2 pages completely different values for the same orientation.

4. It would be good if standards were stricter about when folks could ask for permission (e.g. only top frame, after user gesture, etc) so permissions wouldn't need to be the primary access gating mechanism

[pes10k]

In general, I don't think there is disagreement here other than possibly 1. I wasn't sure what the specific ask in your issue was, so tried to provide some points that I though might be valuable background.

3. we're not disagreeing on this. I was replying to @anssik 's comment about the priorities that guided the current API

4. yep again I don't think we're disagreeing

5. the values that can be fingerprinted are the internal calibration values, if I'm understanding your question correctly (apologies if im not). This issue Move fingerprintable APIs behind permissions deviceorientation#85 and the linked to paper may be of interest in this regard

[reillyeon]

I think I agree with @fergald's original point. If we make the assumption that it is difficult to reverse engineer the low-level sensor values from a high-level sensor values then the current permission and feature policy design doesn't make sense. A model which gives both users and developers the ability to make meaningful choices about the data being exposed should provide a strict ordering based on the sensitivity of the data. For example, the set of raw-accelerometer and raw-gyroscope permissions may imply the relative-orientation permission but not the other way around.

On the other hand I believe the point that @snyderp is making is that even the high-level sensor data is sufficient for fingerprinting, which renders the idea of this graduated permission model moot. In that case I believe, as discussed on w3c/deviceorientation#85, that the best solution is to find a mitigation through precision reduction or noise injection which removes fingerprintable behavior while not significantly changing the behavior of the sensor.