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