w3c / accelerometer Goto Github PK

In my opinion, yes, from https://w3c.github.io/accelerometer/#construct-spatial-sensor-object operation

While crawling Accelerometer, the following links to other specifications were detected as pointing to non-existing anchors:

• https://www.w3.org/TR/screen-orientation/#dom-screen

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

The spec (as the 2 other specs) defines a new permission name ("accelerometer"), which I understand needs to be added to the Permission API.

Also, the link to "permission name" is broken (no matching anchor).

This paper focuses on orientation sensors, but also notes a similar risk in accelerometer sensors for at least some devices:
Zhang, Jiexin, Alastair R. Beresford, and Ian Sheret. “SensorID: Sensor Calibration Fingerprinting for Smartphones.” In 2019 IEEE Symposium on Security and Privacy (SP), 638–55. San Francisco, CA, USA: IEEE, 2019. https://doi.org/10.1109/SP.2019.00072.

High-resolution reporting of accelerometer values may provide an attacker access to the factory-set calibration of the sensor, which is a persistent, cross-origin identifier allowing for device fingerprinting. This is a serious privacy concern.

Based on related concerns noted in device orientation, specifying a particular rounding threshold for this API may mitigate the threat for all (or almost all) devices. Paul Jensen recommends rounding to 0.1 m/s^2. Currently the spec doesn't speak to precision, except through use of the double datatype.

This is a separate attack from the AccelPrint work that's already been cited in the Generic Sensor API, but it's possible the attack and potential mitigations are related. (The AccelPrint paper doesn't seem to quite get into what all the sources of the fingerprint are or what methods are sufficient mitigation.)

w3c/deviceorientation#4

F2F consensus to rename AccelerometerReading properties to x, y, and z.

See also w3c/magnetometer#3

All main use cases require "periodic" reporting mode. Fix this prose:

The Accelerometer Sensor has a single supported reporting mode which is "auto".

https://w3c.github.io/accelerometer/#model

On many of your SVG images, you have code like:

<img src="foo.svg" onerror="this.src='foo.png'">

The obvious intention here is that, for ancient browsers that don't understand SVG images, you fall back to the PNG version.

However, if the PNG version also fails (such as, for example, if I've pulled the .bs file locally and am rendering it by itself, without the rest of the repository...), then the image just forever cycles and the page is never allowed to finish loading. What's worse, at least on Chrome, the image itself constantly resets between "broken" and "loading", which changes its height (from the height of the broken-image icon to 0x0, then back again), so the entire spec following the first such image is rapidly shifting up and down forever.

This functionality probably isn't important to keep (I haven't seen it anywhere else, and browsers that don't understand SVG are ancient at this point, and not worth targetting for the audience of "people that read specs"), but if it is, could you instead abstract it out to a <script> block and make it more robust, perhaps with something like:

<script>
function pngOnError(img) {
  this.src = this.src.slice(0,-3) + "png";
  this.onerror = null;
}
</script>
<img src="foo.svg" onerror=pngOnError>

The enum LocalCoordinateSystem is defined in each of the motion sensor spec - it should be defined just once, and referenced from other specs.

At the review of the Sensors API at TPAC 2017, PING and the Sensors WG discussed including known privacy exposures for a given sensor, e.g. the use of the gyroscope as a microphone, in the W3C specification for that specific sensor as opposed to incorporating the exposure by reference. The goal of doing so is that an implementer of the specific sensor API would see the specific privacy exposure — and mitigations — for a sensor in the spec for that sensor API.

In the case of accelerometer, that would entail incorporating a reference to the fingerprinting risk that accelerometers pose, e.g. http://synrg.csl.illinois.edu/papers/AccelPrint_NDSS14.pdf. For mitigations, the proposed mitigations in the Generic Sensor API specification could be brought over or referenced.

In the interest of helping someone in the future produce a greenfield implementation, it would be good if this specification explained or linked to an explanation of how raw sensor values are combined or split into separate linear acceleration vs gravity values. General relativity would seem to imply that such a separation is impossible, but clearly it's been done. 🙃

Rather than duck by pointing at others' suggestions ("The [TOUCHSIGNATURES] and [ACCESSORY] research papers propose that implementations can ..."), define normative privacy mitigations in this spec.

Here are some of the TAG's and PING's guidance arguing for this:
https://www.w3.org/blog/2019/06/privacy-anti-patterns-in-standards/
https://www.w3.org/blog/TAG/2019/09/11/security-and-privacy-for-our-times/

Would suggest having two separate interfaces here. One for the low-level accelerator sensor, and the other one for a fused, higher-level gravity-less acceleration (which might also rely on the gyroscope, etc.).

These two have different use cases and should have different APIs to reflect that.

See: w3c/sensors#127

This is similar to e.g. w3c/gyroscope#51, I don't know why the bot didn't file an issue for this spec.

It'd be great to add the use cases to the spec!

The accelerometer could be used to fingerprint people if it is used at the same time as the vibration API. This could be prevented by having the accelerometer disabled or collecting data at a lower accuracy when the vibration API is in use.

:(

readonly attribute boolean includesGravity;

boolean includeGravity = true;

The includeGravity parameter is not consistent. Is it intentional design?

If you want to do a real magnetic compass then you need the magnetic field and the gravity vector (or even better, isolated gravity data). The only way to get this is to includeGravity and then do a low pass filter (say with alpha value 0.8). (see intel/websensor-compass@3d92ff1)

That is doable but not efficient, plus Android already exposes a way to get isolated gravity, so it kind of feels foolish.

When the spec was switched from separate reading interface to include it in the main one, the types of the x, y, z attributes were switched to **unrestricted** double - what is the reasoning behind the change? I didn't find anything related to Infinity in the spec, nor did I easily find any supporting model consideration in the generic sensor spec, nor in the motion sensors spec.

if there is a good reason, I think it should be documented, possibly in the 3 docs; if there isn't,