- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2019 07:51:51 +0000
- To: public-device-apis-log@w3.org
The [mitigations](https://w3c.github.io/sensors/#mitigation-strategies) section is marked non-normative since it is a summary of normative mitigations inlined in the algorithms. For example, [4.2.1. Secure Context](https://w3c.github.io/sensors/#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](https://www.w3.org/das/roadmap) that extend the Generic Sensor API cherry-pick [additional mitigations strategies](https://w3c.github.io/sensors/#mitigation-strategies-case-by-case) 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](https://w3c.github.io/sensors/#mitigation-strategies-case-by-case). @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. -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/sensors/issues/397#issuecomment-546244763 using your GitHub account
Received on Friday, 25 October 2019 07:51:53 UTC