Spec should include mandatory mitigations for privacy harms / risks

[pes10k]

While the spec does a great job discussing the risks associated with the exposed functionality, there is relatively little in the way of required mitigations. We think its bad practice to have standards require privacy risky functionality, but then leave it up to implementors to figure out non-standard ways of protecting users; the protections are just as much a part of the web platform as the functionality. The spec should be updated / modified to specify the steps implementors must take to keep their users safe from the risk the standard adds.

[anssiko]

The mitigations section is marked non-normative since it is a summary of normative mitigations inlined in the algorithms. For example, 4.2.1. Secure Context translates into [SecureContext] in IDL. All those mitigations summarized in that section have normative counterparts defined in IDL and/or normative spec prose.

Concrete sensors that extend the Generic Sensor API cherry-pick additional mitigations strategies on top of the mandatory "core" mitigations. All these mitigations are recommended by research in the field referenced in the specs. The additional mitigations are specified in respective concrete sensor specs, while the Generic Sensor API again summarizes the available options.

@snyderp what additional concrete mitigations we should add to the Generic Sensor API? Can you give a concrete example of a "non-standard ways of protecting users"?

If there's a good mitigation applied by some implementer as a non-standard extension and it is proven to be effective, we should consider adding that to the spec to improve privacy protection and interoperability.

[pes10k]

This is partially overlapping from the convo here w3c/deviceorientation#85 (comment) but including here for completeness:

1. Part of this is my reviewer error, since in most specs the "considerations" sections are written to not include mandatory mitigations / requirements for complete implementation. I see (because you pointed it out to me ;) ) that i missed the existing "MUST"s, so that addresses most of this. I still suggest the change from my comment though, integrating, or at least pointing to, these mandatory steps in the algorithm description parts of the spec

2. I suggest adding the "user gesture" requirement too (to address cases for first person "bounce tracking")

[anssiko]

1. This is addressed by the (thankfully!) automatically generated index of terms defined by reference.

2. For this, you'd need to suggest changes to the new information about the user’s intent definition in the Permissions API. The Generic Sensor API references Permissions API algorithms, that in turn reference this particular definition. The Generic Sensor API and its extension specifications are agnostic with respect to any user interface aspects. An informative reference to this definition is proposed to be dropped in Update "Security and privacy considerations" and "Permissions API" #400.

My assessment is this issue can be closed without further changes to the Generic Sensor API. @snyderp can you confirm and open a new issue in the Permissions API repo to discuss new information about the user’s intent definition?

[pes10k]

@anssiko is your assessment that there should be no floor / minimum set of protections for all sensor APIs, beyond permissions? This was (one of) the intents of this issue, to establish a common floor of mandatory privacy protection on all sensor APIs. User gestures seem like a good, plausible example (top level frame too). Is it the WG's feeling that this is not approproiate?

[anssiko]

The group agreed common floor is https://w3c.github.io/sensors/#mitigation-strategies

Concrete sensor specs recommend additional mitigations on top of this floor from this bucket https://w3c.github.io/sensors/#mitigation-strategies-case-by-case

Those additional mitigations are defined in each concrete sensor spec that extends the Generic Sensor API. The common floor is always inherited from the Sensor base class.

[anssiko]

@snyderp please let us know if these clarifications address your concern satisfactorily so that we can proceed with the CR publication w3c/transitions#189

[pes10k]

@anssiko I see. I think we've circled back to the original ask them :) The ask is to add user gesture to this list, and in 5.6, to prevent tracking by bounce trackers. Is there a reason the WG thinks this is not appropriate?

[anssiko]

@snyderp do you actually mean https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation when you say user gesture? There was possible confusion over terminology.

If so, triggered by user activation requirement would fit in the Permissions API request() https://wicg.github.io/permissions-request/#dom-permissions-request and in the Generic Sensor API start() https://w3c.github.io/sensors/#sensor-start

5.6 https://w3c.github.io/sensors/#can-expose-sensor-readings is invoked on each sensor reading, so requiring every reading to be triggered by user activation does not provide a reasonable UX. One click, one reading, while some use cases would need possibly 60 readings per second.

I think this ask would be satisfied reasonably if https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation would be added to https://w3c.github.io/sensors/#sensor-start as a condition for success.

@reillyeon would Chrome be supportive of this change?

All - any other concerns or issues with this proposal?

(Related issue and WG decision at #388 where the group decided not to add a method similar to https://w3c.github.io/deviceorientation/#dom-deviceorientationevent-requestpermission to the Generic Sensor API.)

[reillyeon]

I am supportive of a user gesture being require to request permission to access a sensor. Activation of a sensor for which permission has already been obtained should not require a user gesture.

This is what Chrome intends to implement. Currently sensor permission is granted to all origins by default which renders the user gesture requirement moot. There are plans to change these defaults and require an explicit permission request, which would require a user gesture. Implementing this change will break existing web content and so a migration period is planned.

[anssiko]

Revised proposal: https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation is added to https://wicg.github.io/permissions-request/#dom-permissions-request as a condition for success. This generalizes the already shipping pattern defined in https://w3c.github.io/deviceorientation/#dom-deviceorientationevent-requestpermission

[pes10k]

@snyderp do you actually mean https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation when you say user gesture? There was possible confusion over terminology.

That a frame / context cannot successfully access the feature / until the frame has received a user gesture. This would be similar to Storage Access API, where all requests for the relevant functionality are rejected before prompting for permission until the permission request is being triggered by a user gesture. Future requests in that context can then be made w/o needing to be accompanied by a user gesture.

I believe this matches @reillyeon's statement too

[anssiko]

@snyderp @reillyeon per my assessment the revised proposal #397 (comment) satisfies the requirements of both of you. Can you confirm?

The Storage Access API proposal uses an unspecified notion of "user gesture". My understanding is its standards-equivalent is https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation

[pes10k]

@anssiko the concern here is that https://wicg.github.io/permissions-request/#dom-permissions-request is no where near CR, so it doesn't seem appropriate to move the privacy protections of a spec to something that doesn't seem on its way to CR.

So, suggestion:

1. short term, lets get the user activation text included here
2. if / when https://wicg.github.io/permissions-request/#dom-permissions-request gets to CR, we can clean the text up from these APIs

Thoughts?

[anssiko]

@snyderp IIUC, that suggestion might be in conflict with WG resolution #388 (comment)

To be specific, is your proposal in 1 to copy
https://wicg.github.io/permissions-request/#dom-permissions-request into https://w3c.github.io/sensors/#api and add https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation as an additional step into this copied over permissions.request()?

[reillyeon]

I don't think this suggestion conflicts with the WG resolution. As a matter of specification maintenance I would rather not include additional language that is duplicated elsewhere but I agree on the principle that a CR shouldn't depend on pre-CR behavior.

[plehegar]

as a side note, we documented the considerations for normative references.

[anssiko]

Having read the normative references considerations, my assessment is we're able to normatively reference pre-CR documents in a CR given good rationale considering stability, schedule, and licensing dimensions. @plehegar to clarify.

Since stability of permissions.request() extension [PERMISSIONS-REQUEST] seemed to be the key concern out of these dimensions, I summarize related considerations below:

• Generic Sensor API CR published 20 March 2018 contained a normative reference to the Permissions API.
• The Permissions API spec has not changed substantially since 20 March 2018.
• The permissions.request() extension [PERMISSIONS-REQUEST] has remained stable since 28 September 2017. Chrome has indicated interest to implement this extension.
• Permissions API [PERMISSIONS] has a normative dependency on [PERMISSIONS-REQUEST].
• The permissions.request() defines reusable infrastructure. This suggests it is better defined as a Permissions API extension for reusability reasons, rather than in a domain-specific Generic Sensor API.

Rationale:

• Given [PERMISSIONS] and [PERMISSIONS-REQUEST] have remained stable for ~21 months and there has been implementer interest, we can publish a revised CR with pre-CR [PERMISSIONS] as a normative reference.

Assuming the Director is satisfied with the rationale, I think the following proposal made earlier addresses this issue satisfactorily, reproduced here for clarity:

https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation is added to https://wicg.github.io/permissions-request/#dom-permissions-request as a condition for success. This generalizes the already shipping pattern defined in https://w3c.github.io/deviceorientation/#dom-deviceorientationevent-requestpermission

@snyderp @reillyeon please confirm that you are satisfied with the proposal so that we can advance with the publication. Thank you!

[plehegar]

@anssiko your reading is correct.

The Permissions API spec hasn't been updated on the W3C site since September 2017, and the commits history of the editor's draft isn't compelling. @wseltzer , what's the status of the Permissions API? Can we get an updated WD?

Permission Request is a WICG report, not yet adopted by a Working Group. Not sure how the dependency is important here since it's not referenced by Generic Sensors, nor is it used in the [Permission] definition referenced by Generic Sensors.

(attempting to preempt potential questions from the Director)

[anssiko]

Permission Request is a WICG report, not yet adopted by a Working Group. Not sure how the dependency is important here since it's not referenced by Generic Sensors, nor is it used in the [Permission] definition referenced by Generic Sensors.

It is indirectly relevant. [PERMISSIONS-REQUEST] complements [PERMISSIONS] with an API to programmatically request permissions. The above-mentioned proposal #397 (comment) adds a new privacy protection to [PERMISSIONS-REQUEST] to mitigate an attack known as first person bounce tracking. By adding this privacy protection to this API, also other potential consumers of this programmatic request facility get the same privacy protection.

It is not a normative dependency on the Generic Sensor API since implementers can choose to implement the Generic Sensor API with [PERMISSIONS] but without [PERMISSIONS-REQUEST]. This is what Chrome ships today, but we heard Chrome is planning to also implement [PERMISSIONS-REQUEST] so we felt getting this mitigation in would be important.

[anssiko]

@snyderp please take a look at the latest proposal #397 (comment) and let us know if you have concerns with it.

Based on the latest exchanges in this issue, the Director does not automatically block CR publication with pre-CR references. I believe that addresses the remaining open #397 (comment)

[pes10k]

@anssiko yes i still have the same concern. I still think its not correct to have the privacy properties of a standard moving to CR to hinge on a document in pre-(pre pre pre) CR stage. [PERMISSIONS-REQUEST] does not represent any vendor or community agreement at all, and so could change in any direction at any time, which would undo the privacy gains needed for this issue.

Again, my issue is not W3C process (I don't know if W3C process allows this; i believe you all when you say it doesn't strictly prohibit it), but that for this to move forward, it needs to have unambigious privacy protections, and hinging on a non-CR document makes those privacy protections ambiguous.

[anssiko]

In addition to the earlier proposal, I propose we address the [PERMISSIONS-REQUEST] stability concern by noting it prominently in the Status Of This Document section, and mark the dependency on that feature (via [PERMISSIONS]) as ”at risk”. The intent of the revised CR is to encourage further implementation experience and feedback. This is the most explicit way to do so I can think of.

Copying request permission feature (effectively forking its IDL and prose) would not improve its stability even if we’d place the copy into this CR spec. It would be better to reference the canonical upstream version even if it would not be as advanced in terms of Rec Track. This allows all downstream specs to inherit the additional privacy protections we’re putting in place.

As said, Chrome has indicated interest to implement the feature in question which would provide valuable feedback on the request model and also likely reignite discussion in the wider community on how to solve this important issue that touches many other APIs that expose powerful capabilities, and that in turn, help advance it on the Rec Track.

Seeking comments from all stakeholders on this addition. I can volunteer to submit a PR for review for the proposed amendment.

[anssiko]

Here's the PR #401 for the proposed amendment.

@snyderp please take a look.

[pes10k]

@anssiko Apologies new here, trying to make sure I understand the proposal:

1. Update Sensor API to have a normative / binding dependency on [Permission Request Algorithm](https://wicg.github.io/permissions-request/#permission-request-algorithm.
2. Update Sensor API to note that Permission Request is "at risk" (e.g. could change anytime)
3. To update the "Permission Request Algorithm" algorithm to include the "user activation" requirement
4. To survey main stakeholders (e.g. Moz, Google, MS, Apple) and see if they plan to implement 3

Is this correct?

If so, then I would be fine with that outcome if

• 2 was completed before Sensor API went forward
• all parties in 4 indicated support to implement

(as a side note, if the idea is to generalize, it would be good to move even more of 5.6 into the Permission request Algorithm)

[anssiko]

That is correct. To address your two latter points:

To exit CR we need to evaluate the at-risk dependency per W3C Process and receive adequate implementation experience, that is two independent implementations per DAS WG charter.

It sounds like we have consensus. Any other questions or concerns before we move on?

[pes10k]

wait, sorry, not to pull the rug out from under things, but 3 needs to be addressed too. Is there any expected difficulty in addressing 3 from #397 (comment)? Otherwise, not only is there an "at risk" spec where text could change, but there isn't even text :)

[anssiko]

You can help figure that out by opening a separate issue at https://github.com/WICG/permissions-request/issues

[pes10k]

I am happy to do so, but to clarify, that to-be-opened issue is one that should be owned by your WG, not myself, since your WG is the one relying on it to address your privacy issues.

So, I'm happy to open and push for it there, but your group will need to push on it too (its your proposed solution)

[anssiko]

Thanks @snyderp!

I propose we address WICG/permissions-request#2 together in a non-blocking fashion, i.e. first publish a revised CR of Generic Sensor API followed by an update to [PERMISSIONS-REQUEST] that addresses WICG/permissions-request#2

This is a last call to submit feedback for PR #401 before we publish a revised CR.

[swickr]

If WICG/permissions-request#2 is a prerequisite to close this issue then labeling permission request algorithm as At Risk is odd. I would not expect consensus on advancing if that At Risk feature were dropped.

In any case, we would not expect to advance Sensor API beyond CR until PERMISSIONS-REQUEST moves beyond incubation.

[pes10k]

Partially echoing @swickr , but I agree, it seems impossible to evaluate the privacy attributes of Sensor API w/o PERMISSIONS-REQUEST being more locked down, and so it seems not possible to advance them in parallel

[anssiko]

I propose we add the following clarification from @swickr (with editorial changes) to SOTD to address the remaining concern:

The group does not expect to advance this specification beyond CR until [PERMISSIONS-REQUEST] moves beyond incubation.

[anssiko]

@swickr please see #402 for the proposed changes to address your comments. The group would like to see this clarification incorporated before CR publication. Once this PR is merged, the spec is publication-ready.