@dontcallmedom and @xfq, below I drafted a proposal for the wide review announcement to be sent to [email protected] using the RfC Template, please take a look:

Subject: RfC: wide review of Sensor APIs Pre-CR WDs
To: [email protected]
Bcc: [email protected]
Reply-to: [email protected]

Hi,

The Device and Sensors Working Group requests review of the following
specification before 2017-12-31:

   Generic Sensor API
   https://www.w3.org/TR/generic-sensor/

Including the following concrete sensor specifications that extend
the Generic Sensor API:

   Ambient Light Sensor
   https://www.w3.org/TR/ambient-light/

   Accelerometer
   https://www.w3.org/TR/accelerometer/
   
   Gyroscope
   https://www.w3.org/TR/gyroscope/

   Magnetometer
   https://www.w3.org/TR/magnetometer/

   Orientation Sensor
   https://www.w3.org/TR/orientation-sensor/

Informative background material (not in scope of the wide review):

   Motion Sensors Explainer
   https://w3c.github.io/motion-sensors/

   Sensor Use Cases
   https://w3c.github.io/sensors/usecases

The group requests feedback via the respective specifications' GitHub
repositories, or via email to [email protected].

These publications are Pre-Candidate Recommendation Drafts under the
2017 Process [1]. Therefore, the group is looking for confirmation
that it has satisfied its relevant technical requirements and
dependencies with other groups.

Thanks,

-Anssi (Device and Sensors WG Chair)

[1] https://www.w3.org/wiki/DocumentReview

In addition, my plan is to tailor separate wide review request mails or GitHub issues based on the above to the following (horizontal) groups indicating the focus areas of the wide review for each (inspired by the das-review proposal and previous wide review request):

• TAG https://github.com/w3ctag/design-reviews/issues

Overall design and integration in the platform, draft review request at #319

• [email protected]

In particular the group requests review of the use of Permissions,
Feature Policy, and Secure Contexts specifications.

• [email protected]

In particular the group requests review of the privacy considerations.

   Security and Privacy Self-Review Questionnaire results:
   https://github.com/w3c/sensors/blob/master/security-questionnaire.md

• [email protected]

In particular the group requests review of the security considerations.

   Security and Privacy Self-Review Questionnaire results:
   https://github.com/w3c/sensors/blob/master/security-questionnaire.md

• [email protected]

In particular the group requests review of the Ambient Light Sensor
specification and its intersection with the light-level CSS media
feature defined in the  Media Queries Level 5 specification.

• [email protected]

In particular the group requests review of the intersection with
movement detection in WebVR, security and privacy considerations
shared with WebVR, reuse in gamepad extensions, and Magnetometer
that enables magnetic input for WebVR.

• [email protected]

In particular the group requests review of the use of Web IDL.

Some specific questions:

• Accessibility and Internationalization. It was proposed that the specifications in questions do not touch these domains and as such we do not need to complete the respective questionnaires, and may not need to ask explicit wide review feedback from these horizontal groups. Is it enough of a paper trail to document the decision in this meta issue? Is the public-review-announce@ request enough, or should we reach out to these groups direct?

• Should we use the latest ED, latest TR, or a dated version of a TR in the wide review request? I think TAG will prefer the bleeding edge so planned to give them the EDs. For public-review-announce@ I proposed we use the latest TR since the request talks about "Pre-Candidate Recommendation Drafts". Recommendations?

• The subject line is a bit wordy, but it tries to follow the established best practice. Note I only included "Generic Sensor API" and not the concrete sensors in the subject line. How to improve?

• Should we add more background into the review request or can we assume people with interest will find and read the Generic Sensor API introduction section themselves? I feel a concise mail might work better.

re reaching out to other potential groups, I suggest sending a mail to [email protected] as well - this serves as a catch-all for any group we might not have identified as relevant.

+1 on using the TR draft URL for these review requests

re subject line, I would say "s/Generic Sensor API/Sensor APIs", but otherwise LGTM

+1 on keeping the mail short (i.e. no need to include background) - that said, we had mentioned including a reference to the motion sensor explainer as well to help reviewers

Thanks @dontcallmedom, I will Bcc [email protected] in the mail sent to [email protected]. I updated the proposal per your feedback, added Motion Sensor Explainer and Sensor Use Cases document as "Informative background material (not in scope of the wide review)".

I think "2014 Process" should be "2017 Process".

@xfq, thanks! Fixed. The "2014 Process" part was inherited from the RfC template. Someone from W3C Staff should update it accordingly.

I observe that neither the 2014 nor 2017 W3C Process document defines the term "pre-CR", also inherited from the RfC Template. It is defined only in https://www.w3.org/wiki/DocumentReview#Terminology_and_Abbreviations AFAICT. And that's what we reference in the wide review request proposal.

All wide review requests have now been sent.

I suggest we leave this meta issue open to track feedback received.

The wide review period has ended. The group received feedback from the TAG, Security IG and Privacy IG, see #299 (comment)

On the 11 Jan 2018 teleconference @alexshalamov and @pozdnyakov volunteered to start address the feedback.

This is a summary of the proposed changes made to the specs in scope of this wide review based on TAG feedback at w3ctag/design-reviews#207. Here's how to read this response:

• Quoted are all the comments made in Sensor APIs w3ctag/design-reviews#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 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 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://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: #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 that was recently updated to incorporate advise regarding timing attacks, and implementations have been updated accordingly to reduced time precision: Mozilla 2 ms and Chrome 5 μs.

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: w3c/ambient-light#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: w3c/ambient-light#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:
w3c/ambient-light#49
w3c/accelerometer#38
w3c/gyroscope#33
w3c/magnetometer#41
w3c/proximity#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: w3c/magnetometer#41

[Edit: added 2018-03-07] Let me restate annevk's question another way: How do you ask the user a question that is both concise and accurate enough that the user's consent is meaningful? Will the user understand, for example, that accurate accelerometer, gyroscope, and magnetometer measurements might reveal all the text that the user types while they're being measured, or what sorts of activities the user is doing, and perhaps their location (based on mapping a pattern of movement to paths that exist on a map)?

Proposed changes: #353

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: #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

Per F2F resolution, the group will start the process to re-publish Generic Sensor API, Accelerometer, Gyroscope, and Orientation Sensor as Candidate Recommendations.

As a prerequisite for re-publishing CRs, we must ask for wide review for the substantial delta since previous wide review.

The proposal is to seek review from the following groups (in separate mails i.e. no crossposting):

• [email protected]; Bcc: [email protected]
• [email protected] - no concerns
• TAG: comment in Sensor APIs w3ctag/design-reviews#207 - no concerns
• [email protected]
  • wide review response - no concerns
  • other privacy feedback Remove text about non-explicit permissions  #396 Spec should include mandatory mitigations for privacy harms / risks #397 addressed by Update "Security and privacy considerations" and "Permissions API" #400
• [email protected] - no concerns

Proposed Request for Comments mail:

Subject: RfC: wide review of WebDriver extensions for Sensor APIs
To: <see above>
Bcc: <see above>
Reply-to: [email protected]

The Devices and Sensors Working Group requests wide review of the
following specs. The only substantial change since the last CR is the
the addition of WebDriver extensions. Please provide your feedback
by 2019-11-14.

WebDriver API and its extensions enable test automation and are not
web-exposed in a normal browsing scenario. The extensions in scope of
this review request are defined in the following Automation sections:

   Generic Sensor API
   https://w3c.github.io/sensors/#automation

   Accelerometer
   https://w3c.github.io/accelerometer/#automation
   
   Gyroscope
   https://w3c.github.io/gyroscope/#automation

   Orientation Sensor
   https://w3c.github.io/orientation-sensor/#automation

The group requests feedback via the respective specifications' GitHub
repositories, or via email to [email protected].

The group is looking for confirmation that it has satisfied its relevant
technical requirements and dependencies with other groups.

Thanks,

-Anssi (Devices and Sensors WG co-chair)

Cc @xfq @reillyeon

Wide review request mails have now been sent and the respective TAG issue has been notified. Deadline for comments was set as 2019-11-14.

Wide review ended with no concerns. A paper trail at #299 (comment)

Other feedback received from PING #396 #397 is being addressed by #400. Although this feedback goes beyond the requested wide review scope, I suggest we incorporate these proposed changes into the Generic Sensor API spec before we publish a revised CR.

I'm working with @xfq and @reillyeon to get the revised CRs published at the earliest opportunity.

All wide review feedback has been addressed and CR transition request w3c/transitions#189 submitted.