Repository navigation
Items from privacy review #280
Description
Activity
Thank you @sandandsnow and PING for your careful review! You've been a great partner to us and helped improve our work substantially. The WG discussed your feedback on our 2022-08-12 call and here's the WG's response:
Fingerprinting via execution time analysis
(1) Please keep us posted with the results of your research into the extent of the threat of fingerprinting via execution time analysis and potential mitigations.
Acknowledged. This is an active area of research.
The ethics & privacy implications of the identified and potential use cases of the API
(2) Re: The ethics (and privacy implications) of the identified and potential use cases of the API. PING observed that a number of the use cases that the API would enable are highly privacy-invasive and, therefore, should include an analysis of the privacy implications of those use cases as well as mitigations (e.g. transparency, policy and/or user controls). (Note: While the described use cases are probably only a subset of use cases that this API could be used for, the examples provided in the specification should help guide the use (or not use) of the API in other situations.)
Our group's approach has been to discuss the ethical issues and mitigations in the separate deliverable, Ethical Principles for Web Machine Learning. To address your feedback, and to avoid duplicating information, our proposal is to link the use cases described in the WebNN API specification with the relevant ethical and privacy issues discussed in the Ethical Principles W3C Note.
To give a concrete example, in Use case: Face Recognition we would include a link to Ethical issue: Accuracy that discusses ethical and privacy issues related to face recognition.
Our intent has been to keep the technical specification, WebNN API, focused mainly on technical content and use the separate deliverable, Ethical Principles, as a document where the related ethical (and associated privacy) considerations can be expanded.
Software implementations to eliminate or reduce compute unit scheduling from being a fingerprinting risk
(3) What are the software implementations (or examples) that would eliminate or reduce compute unit scheduling from being a fingerprinting risk? (The text says: " Furthermore, software implementations can be used to further eliminate such artifacts.")
WebNN API takes a dependency on certain primitives (e.g.
GPUCommandBuffer) defined in the WebGPU API and this consideration is inherited from the WebGPU API, see machine-specific artifacts in WebGPU API. In other words, software-based mitigations for eliminating machine-specific artifacts in the WebGPU API implementation would be similarly inherited by the WebNN API implementation. In general, WebGPU API notes that this fingerprint vector is relatively low-signal even without the proposed software-based elimination approach. We'll consult the WebGPU WG for more details on related research as part of WebGPU API wide review and update our spec as appropriate.Future device types and their fingerprint mitigation
(3) [sic] Re: "If a future version of this specification introduces support for new a device type that can only support a subset of MLOperandTypes, that may introduce a new fingerprint", what mitigations does the WG envisage should this occur?
We expect future implementations to mitigate this by falling back to more generic device types (GPU or CPU) without side-effects in such a case. This would not only mitigate the fingerprinting concern, but also provide a better developer experience. We envisage it to be an implementation detail how the workload (graph compilation and execution) is split across multiple devices.
We want to note that using the High Resolution Time API a malicious user could try to infer the device type(s) leverating accurate timing information. That API has deployed mitigations such as relaxed the requirements for resolution to mitigate these vectors.
WebGPU Privacy Considerations dependency
(4) Re: "In general, implementers of this API are expected to be familiar with the WebGPU Privacy Considerations", it would be helpful to state that implementers are expected to apply WebGPU Privacy Considerations to their implementations.
We propose the following rewrite to address your feedback:
-In general, implementers of this API are expected to be familiar with the WebGPU Privacy Considerations. + In general, implementers of this API are expected to apply WebGPU Privacy Considerations to their implementations where applicable.
Understanding "power preference" fingerprinting risk
(5) "Power preference indicates preference as related to the power consumption and is considered a hint only and as such does not increase entropy of the fingerprint." - If power preference is set to default, what might the user agent do, and could that reveal information about the device and/or user? (We discussed this during the PING call, but we were not able to sort out whether the hint is fingerprintable. Could you explain in more detail how the power preference works so we can understand the fingerprinting risk?)
The power preference does not have web-facing observable side-effects that could be used as a fingerprint. This is the case as long there is no Web API to measure power consumption. If such a Web API emerged, then this interaction needs to be considered. Further, these is no programmatic API to query what device is picked up.
Other comments
Possible typo in privacy considerations: "worload" => "workload"; "allow the implementation better select" => "allow the implementation to better select"
Thanks for catching these typos. We'll fix these.
Next steps
Thank you again for your review. We'd appreciate if you could confirm our proposed resolutions outlined in this comment are satisfactory so that we can submit a PR with detailed changes for your review.
@sandandsnow, does the above outline look good to PING?
If so, our next step would be to craft a PR with the outlined changes. We'll take another look at this feedback on today's WG meeting and give an update here if new information emerges from that discussion.
Thanks for your review comments!
@sandandsnow, here's the PR #286 based on the outline #280 (comment)
Please take a look, thanks! We can refine this further as needed.
Apologies for the delay. Here is what we suggest for (2) above.
“Please be aware that some of the use cases described here, are by their very nature, privacy-invasive. Developers who are planning to use the API for such use cases should ensure that the API is being used to benefit users, for purposes that users understand, and approve. They should apply the Ethical Principles for Web Machine Learning and implement appropriate privacy risk mitigations such as transparency, data minimisation, and users controls”
Thank you @sandandsnow, the PR #286 has been updated with your proposal #280 (comment).
See: w3cping/privacy-request#96
(1) Please keep us posted with the results of your research into the extent of the threat of fingerprinting via execution time analysis and potential mitigations.
(2) Re: The ethics (and privacy implications) of the identified and potential use cases of the API. PING observed that a number of the use cases that the API would enable are highly privacy-invasive and, therefore, should include an analysis of the privacy implications of those use cases as well as mitigations (e.g. transparency, policy and/or user controls). (Note: While the described use cases are probably only a subset of use cases that this API could be used for, the examples provided in the specification should help guide the use (or not use) of the API in other situations.)
(3) What are the software implementations (or examples) that would eliminate or reduce compute unit scheduling from being a fingerprinting risk? (The text says: " Furthermore, software implementations can be used to further eliminate such artifacts.")
(3) Re: "If a future version of this specification introduces support for new a device type that can only support a subset of MLOperandTypes, that may introduce a new fingerprint", what mitigations does the WG envisage should this occur?
(4) Re: "In general, implementers of this API are expected to be familiar with the WebGPU Privacy Considerations", it would be helpful to state that implementers are expected to apply WebGPU Privacy Considerations to their implementations.
(5) "Power preference indicates preference as related to the power consumption and is considered a hint only and as such does not increase entropy of the fingerprint." - If power preference is set to default, what might the user agent do, and could that reveal information about the device and/or user? (We discussed this during the PING call, but we were not able to sort out whether the hint is fingerprintable. Could you explain in more detail how the power preference works so we can understand the fingerprinting risk?)
Possible typo in privacy considerations: "worload" => "workload"; "allow the implementation better select" => "allow the implementation to better select"