- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Mar 2018 13:45:24 +0000
- To: public-device-apis-log@w3.org
**This is a summary of the proposed changes made to the specs in scope of this wide review based on TAG feedback at https://github.com/w3ctag/design-reviews/issues/207. Here's how to read this response:** * Quoted are all the comments made in https://github.com/w3ctag/design-reviews/issues/207, copied verbatim. Grouped into three categories: Official TAG review, Other comments in the TAG review issue, Security questionnaire comments. * Links to PRs that contain proposed changes that address TAG review feedback are provided, search for "Proposed changes:" to locate these. * References to existing specification text is provided if the specifications already addressed the review comments. * **Summary:** Based on the group's assessment, TAG review feedback did not yield normative changes to the specifications under wide review. The review comments helped improve various informative aspects of the specifications and readability was further improved. The review comments further reinforced group's view that the specifications are ready to advance to Candidate Recommendation stage in the near future. ## Official TAG review **[Responses to the [official TAG review feedback](https://github.com/w3ctag/design-reviews/issues/207#issuecomment-358006106) below.]** >the sensors (at least in the current spec) being a top level global, singular object could be improved The objects are not singular. Different `Sensor` instances can be tied to the same or different physical sensors of the same type on the device. Extensibility is planned to be explicitly addressed in [Level 2](https://github.com/w3c/sensors/projects/5) by Discovery API that allow web developer to have control over which physical sensor is used. The default sensor concept https://w3c.github.io/sensors/#default-sensor allows this future extensibility: ``` In cases where multiple device sensors corresponding to the same type may coexist on the same device, specification extension will have to define ways to uniquely identify each one.” ``` >An additional remark would be on making these sensors embed friendly components, which allow other hardware API interfaces to drag and drop them into their APIs as they wish, which the current spec doesn't seem to allow due to the limitation noted above. This mostly comes from usecases such as WebVR controllers and expanding gamepad API to accommodate sensors within a gamepad. See above. Already as of today, e.g. WebVR/XR [Device] API could use https://w3c.github.io/orientation-sensor/#orientationsensor-interface as a drop in placement and hook into the https://w3c.github.io/orientation-sensor/#construct-an-orientation-sensor-object The same applies to the Gamepad API. Research papers published on the topic indicate that by throttling the frequency, risks of successful attacks are not fully eliminated, while throttling may greatly affect usefulness of a web application with legitimate reasons to use the sensors. This is noted in https://w3c.github.io/accelerometer/#security-and-privacy >We would like to see if there is a way to avoid downsampling frequency in contexts where this would make the sensor unusable, as annevk noted above. Putting high frequency polling behind a flag would address some level of the privacy concerns. The spec already provides an extension point for implementations to do that by hooking into the Permissions API, see https://w3c.github.io/sensors/#request-sensor-access ## Other comments in the TAG review issue **[Responses to the other comments made in the [TAG review issue](https://github.com/w3ctag/design-reviews/issues/207).]** >https://w3c.github.io/sensors/ Section 4.1.4 and 4.1.5 could go into more detail about what they mean. In 4.0 there is mention of tracking across origin. Cross-Device linking and out-of-band communication is not listed in 4.1. These threats are Ambient Light Sensor specific per privacy expert review, and the concerns are noted in https://w3c.github.io/ambient-light/#security-and-privacy >https://w3c.github.io/sensors/ Section 5.6 does not mention two of the mandatory conditions listed in 4.2: Secure Context and Permission has been granted (or decided not to be required). Proposed changes: https://github.com/w3c/sensors/pull/347 >Various similar security checks seem to be missing from the algorithms in 8.1 (which contains only the policy-controlled feature check), 8.2 (which has none), 8.3, and pretty much all 8.x items. I'm not sure if these algorithms should have the security checks, but I'm not sure why not especially when one of the checks is present in 8.1. Checks prior to `start()` would be redundant since no readings are exposed prior to `start()` invocation. Given the constructors are annotated with `[SecureContext]` they are not exposed in non-secure contexts. >The timestamp property of a Sensor is a high res timestamp that can be used as the base for various attacks; but this is not mentioned. Sensors that produce regular frequency readings can also be used to build a high-res timestamp. Generic Sensor API reuses `DOMHighResTimeStamp` defined in [High Resolution Time Level 2](https://www.w3.org/TR/hr-time-2/) that was recently updated to incorporate advise regarding timing attacks, and implementations have been updated accordingly to reduced time precision: [Mozilla 2 ms](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now#Reduced_time_precision) and [Chrome 5 μs](https://developers.google.com/web/updates/2018/02/meltdown-spectre#high-resolution_timers). >https://w3c.github.io/ambient-light/ Section 3: I seem to recall there was an attack/trick that used ambient light sensor to detect user heartbeat (when one held the phone with one's body covering or near the sensor.) Generic Sensor API identifies a generic threat user identification which this is a special case of, see https://w3c.github.io/sensors/#user-identifying. Proposed changes: https://github.com/w3c/ambient-light/pull/49 If there's a reference to a related paper or proof of concept that discusses this attack we'd like to reference it from the spec. >https://w3c.github.io/ambient-light/ Section 3: It omits mentioning device fingerprinting. Generic Sensor API identifies device fingerprinting attack vector: https://w3c.github.io/sensors/#device-fingerprinting Proposed changes: https://github.com/w3c/ambient-light/pull/49 >https://w3c.github.io/ambient-light/ >https://w3c.github.io/accelerometer/ >https://w3c.github.io/gyroscope/ >https://w3c.github.io/magnetometer/ "There are no specific security and privacy considerations beyond those described in the Generic Sensor API [GENERIC-SENSOR]." Which are so large and numerable this statement could probably be applied to all of the sub documents. But punting on the specific threats relevant to Accelerometer does not provide feedback to the implementer as to whether to require a permission prompt; nor does it provide specific recommendations to limit sampling frequency or accuracy. Proposed changes: https://github.com/w3c/ambient-light/pull/49 https://github.com/w3c/accelerometer/pull/38 https://github.com/w3c/gyroscope/pull/33 https://github.com/w3c/magnetometer/pull/41 https://github.com/w3c/proximity/pull/34 (also updated, although not in scope of this review) >https://w3c.github.io/magnetometer/ Security and Privacy Considerations does not make any mention about the difference between calibrated and uncalibrated. I'm skeptical that Calibrated sensors actually entirely eliminate outside interference of nearby objects, but let's assume it does. It seems like uncalibrated could be used to perform Keystroke Monitoring if you happen to be wearing a piece of jewelry that affects the reading (or maybe even not). Also, exposing the bias values themselves seems concerning and could provide user fingerprinting, cross device linking, and device fingerprinting. It omits mentioning device fingerprinting. Keystroke monitoring attack vector is identified in the Generic Sensor API: https://w3c.github.io/sensors/#keystroke-monitoring Proposed changes: https://github.com/w3c/magnetometer/pull/41 ## Security questionnaire comments **[Responses to the questions regarding security questionnaire responses, specifically 3.5, 3.12 and 3.13.]** >https://github.com/w3c/accelerometer/blob/gh-pages/security-questionnaire.md >https://github.com/w3c/gyroscope/blob/gh-pages/security-questionnaire.md >https://github.com/w3c/magnetometer/blob/gh-pages/security-questionnaire.md >https://github.com/w3c/orientation-sensor/blob/gh-pages/security-questionnaire.md >https://github.com/w3c/ambient-light/blob/gh-pages/security-questionnaire.md >https://github.com/w3c/proximity/blob/gh-pages/security-questionnaire.md >3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to? Why do all of these say "No"? All sensor specifications conform to the same-origin policy. >3.12 Does this specification expose temporary identifiers to the web? It seems like all of the sensors would qualifier as temporary identifiers. Especially things that change less frequently, like proximity and ambient light. The security questionnaire is concerned of explicit identifiers such as “TLS features like Channel ID, session identifiers/tickets” and as such it seems sensor readings would not be considered such identifiers. >3.13 Does this specification distinguish between behavior in first-party and third-party contexts? I thought it did, based https://w3c.github.io/sensors/#losing-focus According to the security questionnaire this question is applicable to the IETF Internet-Draft 6265 https://tools.ietf.org/html/draft-west-first-party-cookies-07 handled on the HTTP level. Proposed changes: https://github.com/w3c/sensors/pull/349 >I also think that the specification should define the maximum allowed frequency to ensure end user security and interoperability. (There's some text on this, but it's not specific.) The group thinks this is a quality of implementation issue. Implementers are made aware of all known security and privacy issues in https://w3c.github.io/sensors/#security-and-privacy and for sensor-specific issues in respective concrete sensor specs to be able to make an informed decision in terms of maximum allowed frequency to satisfy their product requirements while ensuring their users’ security and privacy protection. >Another concern re: fingerprinting. The existence of a sensor provides some fingerprinting information. This is a generic concern that applies to any feature on the platform that has variance across implementations. The concern has been noted in https://w3c.github.io/sensors/#device-fingerprinting -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/sensors/issues/299#issuecomment-369924348 using your GitHub account
Received on Friday, 2 March 2018 13:45:31 UTC