Meeting minutes
ghurlbot, this is webmachinelearning/webnn
<ghurlbot> anssik, OK
anssik: Welcome back after the break!
… we may consider adjusting out meeting time to be more Sydney friendly
Privacy review response and questions from PING
->
Web Neural Network API 2022-06-30 > 2022-09-30 https://
anssik: PING is very happy: "Thank you to the WG for such a thorough and detailed account of the work the group has undertaken on privacy since the last review. This is the model that all WGs should follow. Thank you."
anssik: today, I'd like us to review as as group Privacy Interest Group's review feedback #280 that is the most subtantial
<ghurlbot> Issue 280 Items from privacy review (sandandsnow)
anssik: let's discuss this feedback in parts:
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."
anssik: This suggests no changes to the spec as of now.
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.)"
anssik: the concrete feedback here is:
"should include an analysis of the privacy implications of those use cases as well as mitigations (e.g. transparency, policy and/or user controls)"
anssik: our group's approach has been to discuss the ethical implementations in the separate deliverable we published and continue to refine
Ethical Principles for Web Machine Learning
anssik: one approach to address this feedback would be to link the use cases enumerated in the spec with ethical and privacy implications expanded in the Ethical Principles W3C Note
… to give a concrete example, we could link "Face Recognition" use case with an "Accuracy" ethical issue
anssik: This type of Use Case-Ethical issue mapping couldn't be complete, but provide examples
… thoughts? Would this be worth it? We could ask PING whether this approach would be preferred.
Chai: is the purpose to keep a record for future reference?
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.")"
anssik: here's the full context what we say in Privacy Considerations:
"The WebGPU API identifies machine-specific artifacts as a privacy consideration. Given the WebNN API defines means to record an ML worload onto a WebGPU-compatible GPUCommandBuffer, compute unit scheduling may under certain circumstances introduce a fingerprint. However, similarly to WebGPU, such fingerprints are identical across most or all of the devices of each vendor, mitigating the concern. Furthermore, software
implementations can be used to further eliminate such artifacts."
anssik: This clause "software implementations can be used to further eliminate such artifacts" is inherited from WebGPU spec:
anssik: do we have a concrete software implementation (or an abstract example if it) we could refer to here to address PING's feedback?
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?"
anssik: thoughts on mitigations? I suppose the less fragmented the implementations are, the less fingerprinting is a concern. I suspect there are some learning from WebGL extensions
Chai: I think is is a good observation, I tend to believe even if you define an API people can detect when you fail and understand what happens underneath
… that may suggest an abstraction is broken, even if the app wants to use NPU it should just work from app's PoV
… how it works is an implementation detail, an impl can fall back to something that can produce the result and app can detect it in some manner
… for example, try infer via runtime performance
… an API that fails a lot on certain device types not a good sign, hard for apps to work with such an API
… this is something we think at Microsoft, how to have a robust fall back in our driver model
… this is the way how we view this, it is the platform's responsibility, not the app's responsibility
… the bulk of the work we're doing is to make sure the app can benefit from WebNN, we define the ops so that they're common across frameworks, if the API keeps failing, it is impossible for frameworks to use the API
… automatic fallback to other device types would mitigate this concern
ningxin_hu: we have an explicit requirement to have the graph compiled on specific device, would this fallback break this requirement?
Chai: it's never 100%, unless you want CPU, even on GPU today
… there are some ops that do not run on GPU, reshape etc. layout adjustment
… if you look how it's implemented, it's a few lines of CPU code
… I see the point of not calling it a hint
… to address Dom's feedback we want to not handwave, if we say CPU we want CPU
… with NPU in the future, it may fail and fallback to either CPU or GPU
… it'd not mean "everything will run on NPU"
ningxin_hu: generic question about fingerprinting and feature detection
… how do we distinguish the two, we need feature detection for some use cases
… is there any design principle?
anssik: feature detection can be used for legit use cases too, in which case we could make it explicit to allow UAs to e.g. ask the user for permission
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."
anssik: this suggestions seems reasonable, and I'd suggest we reword our spec accordingly.
… From: "In general, implementers of this API are expected to be familiar with the WebGPU Privacy Considerations."
… To: "In general, implementers of this API are expected to apply WebGPU Privacy Considerations to their implementations where applicable."
… comments? Sounds good?
<Chai> +1
<ningxin_hu> sgtm
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?)"
anssik: I'd suggest we respond that setting a 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.
Chai: I'd add that, we have no API that the app can call and get the answer when they set the default option (part of Dom's earlier feedback to define device type as an explicit ask)
… no way to query what device is picked up
ningxin_hu: Anssi you're right, no API to measure power consumption, can someone argue that based on performance (latency of graph compile) this could be fingerprinted?
… timing could be used to distinguish different device
Chai: right, but depends on what they want to find out?
… the power preference can be taken into account, but in the end there's no API to ask which device is in the end being used
… the implementation will still pick e.g. GPU, but will not stop selecting the GPU, power preference will not change that, GPU could be in low power or high perf mode
ningxin_hu: other examples: low power GPU, high performance CPU
… PING's first feedback was about timing attack, I'm trying to see if that and power preference are related, or have interactions
Chai: timing attacks are rather hard to fully mitigate
… if an app wants to measure those metrics, implementers can not do too much, e.g. how long a conv op takes to execute
… mostly thinking, does the API have ways to programmatically figure that out
… I don't thing we have that
anssik: I will take an action to create a response to PING
WebGPU and WGSL wide review request
Wide Review for WebGPU and WGSL
anssik: WebGPU WG has approached us:
"The GPU for the Web Working Group has made significant progress on first
versions of the WebGPU and WebGPU Shading Language (WGSL)
specifications. The group is now firming up the specifications with a
view to requesting publication as Candidate Recommendations later this
year.
The Working Group would like to invite you to review the latest versions
of the specifications:"
- WebGPU: https://
- WGSL: https://
anssik: the WebGPU WG sets the following expectations in terms of stability and integration with WebNN:
"Working drafts are updated on a continuous basis but there should be no
more breaking changes at this stage. Feel free to review dated versions
of the specifications to avoid looking at a moving target.
Integration of WebGPU with WebNN is being tracked in [1], with possible
WebGPU adjustments considered for a future revision of the
specification. If breaking changes seem warranted to interoperate with
WebNN, the GPU for the Web Working Group would be keen on hearing
requirements."
anssik: DL for comments in 15 October 2022 via https://
… I'd like to note the WebNN-WebGPU interop issue is explicitly mentioned in this request
… I think this is a great opportunity to reinvigorate our dialogue with the WebGPU WG by updating #2500 with changes to the API since January 2022 and future plans
<ghurlbot> Issue 2500 [not found]
Investigation: how WebNN / WebGPU interop could be happening
anssik: we also have a related issue open re CommandBuffer usage:
#264
… thoughts?
<ghurlbot> Issue 264 CommandBuffer usage clarification: internal, external, both? (bbernhar)
ningxin_hu: I opened webgpu#2500, after creating this issue Chai introduced MLCommandEncoder and polished integration story, we could give WebGPU WG an update on the latest developments, not feedback on the WebGPU API spec but introduce a plan for WebNN-WebGPU interop
<ghurlbot> Issue 2500 [not found]
Chai: Rafael is working with Bryan to resolve #264
ningxin_hu: should I hold on updating #2500 until Rafael and Bryan have resolution on #264?
Define ULP (unit of least precision) tolerances for testing
#265
Add WebNN API operations tests #34287
… Bruce has an open PR for w-p-t that proposes new ULP-based assertions
… it seems Bruce is blocked on w-p-t infra team to know whether testharness.js can be augmented with these new assertions?
… If that is not possible, can be add these assertions in the WebNN specific test suite and upstream them to testharness.js later?
… I know Dom and possibly also other reviewers are on vacation, so thus no response
<ghurlbot> Issue 34287 [not found]
ningxin_hu: I think there are two blockers for Bruce's work, one is ULP-based assertions
… possible solution to look into whether the assertion can be added to WebNN-specific test suite per Anssi's proposal
… another one is the issue itself, #265 where Bruce proposes ULP tolerances for certain ops, open for participants feedback
… if we agree with the proposal Bruce will go implement the test cases based on the proposal
Chai: I can help look at these tolerances
<anssik> s/… Bruce has/anssik: Bruce has