Meeting minutes
Announcements
Survey about TPAC 2022
i'm getting coffee, so i'll let Dom/Anssi start with the scribing
anssi: tpac 2022 plans - a few weeks a survey was sent to the chairs to figure out what we would like to do for the next TPAC
… tentatively scheduled Sep 12-16 in Vancouver, as a hybrid meeting
… lots of uncertainty on whether that meeting can be held in person vs a fully virtual meeting as the previous 2 years
… If you feel like sharing (possibly privately) about your ability to be in Vancouver or lack thereof, this would help me to inform W3C TPAC organizers
… ideally before our next meeting
… my observations on this: this WG hasn't met in person yet, but we've been executing above my expectations given the environment - thank you everyone
… we had a short CG F2F back in 2019
… that's our only physical meeting experience
… TPAC is useful for x-group interactions and making informal connections, which can help resolve challenging issues
dom: none of us can predict the future, any information on personal willingness, company policies is welcome
Update on Ethical Considerations
anssi: an update from James on ethical considerations
James: a reminder on the process I proposed in December for our work on ethical considerations:
… first a literature review, consultation with experts and stakeholders, leading to a set of guiding principles
… that could be used as a draft note, and then a set of discussions where these principles would be reviewed & brainstormed on
… to identify high level risks & mitigations
… integrate the outcomes of the sessions into a note that would be presented to the group
… literature review is ongoing, we'll have a draft of guiding principles available next week on github
… the review & brainstorm sessions would be end of March or early April
… we could have the updated draft WG note around April 21st
anssi: I'll work with you & Dom in circulating the invitation to these sessions
… eager as others to see drafts!
… Thanks James! more on this soon
Security review response
Update Security Considerations per review feedback
anssi: thanks to everyone who provided input & feedback
PR Preview: Guidelines for new operations
anssi: I've added a commit to this pull request with guidelines for new operations
… incorporating also input from the ONNX TPAC session
Notion that the API introduces a new scripting language
anssik: WG asked: "The group did not agree with the notion that the API introduces a new scripting language and wants to understand what aspects of the API are of concern?"
… Alex responded:
… "My security concern is that the network is compiled into a program that is entirely under an attackers control. While not as powerful as javascript it is likely powerful enough to make some exploits easier as a result. It argues for careful implementation, and avoiding introducing too much control of control-flow at the API side. Hopefully these concerns can be considered as new operations are introduced."
anssik: can we formulate this into an informative note for security considerations?
dom: briefly looked at this, not still fully clear what would typically mitigate this problem?
… conceptually understand where the reviewer comes from with expressiveness of the API and concerns around that
… the reviewer seems to want some additional information to think about the security properties of the API
chai: we takes security very seriously in my team working on Windows; when we go through security review, we start by identifying the threats that the system may be exposed to
… that includes understanding what data comes in & out the system, and whether it should be treated as trusted or untrusted
… e.g. a PDF displayed in a browser is considered untrusted because the attacker may be in control of the content to exploit vulnerabilities
… in the context of WebNN API, a legitimate question is whether any data that can be produced by someone in your browser through WebNN can be considered untrusted
… another question is whether a format that would feed into WebNN is vulnerable to attacks - e.g. does it give ability to change boundary checks that can lead e.g. to buffer overruns
… In practice, the only time you attack the system is when you make it _execute_ something
… WebNN, as I clarified in #243, is not about executing the data - it's about defining the data
… the graph builder interface doesn't execute anything, it constructs a piece of data
… the attack is limited to when you bind the data to the graph before your execute it in the compute method
… assuming an untrusted ML model, the question is how to harden the compute method
… the key is ensuring that compute honors the boundary of data
… where compute needs to fail if these boundaries aren't respected
… That's how I look at security in general, not sure how it maps to the feedback we got
anssi: this could be part of our security considerations section
… part of our goal is to ensure anyone evaluating the spec can determine the answer to that kind of questions we're getting
dom: building on what was said, two things we want to do: 1) provide all the information we can to implementers so they avoid security bugs 2) surface information that help security reviewers make assessment on the risks
… we should explain how the API is sufficiently hardened, principles behind the design should be explicit in the spec so reviewers and implementers can feel confident
… Anssi's proposal to add Chai's model in the Security Considerations would be great
Update Security Considerations per review feedback PR #251
anssi: this PR is where we hope to address these issues - providing feedback on it would be very useful
Operation level metadata
anssik: WG asked: "The group was not sure what "operation level metadata" exactly means in this context? (Would addressing #243 satisfy all "operation level metadata" requirements?)"
… Alex responded: "Yes, that would be a helpful step."
Op metadata that helps avoid implementation mistakes
anssik: I notice Chai clarified in #243 the MLGraphBuilder API isn't a data execution API, but rather a data definition API. Thanks for that input.
dom: in terms of data definition vs. model execution -- what errors implementers must identify and fail on for each?
… I think making this distinction is important, but the question is when we compile or compute when we need to fail, can we be explicit when?
chai: adding the buffer-metadata to the description of operations feels redundant
… eventually, you'll compare the size of the data you receive with the one you're expecting to receive, you fail
… graph builder defines the size of data you expect to receive
… the size of each buffer within each location within the graph is already defined
… the problem of lack of metadata; the implementation will have to walk the graph to calculate the shape of the data
chai: the important part is when you call compute
dom: if you're doing security analysis of a spec, having an easy way to figure out what op creates a risk for computation because the shape may change between input and output, that may make it easier to write your attack test suite to verify you haven't missed something
… not sure if metadata approach is a practical one
… trying to say, not just guiding implementers only, but guiding reviewers
chai: the graph builder approach is actually a very robust approach to harden this problem space
… because you don't specific the size of the output of the ahead of time, instead based on the operation semantics
… the output size is not in control of the attacker with such a model
… this allows to calculate output size at every single step of the graph
… adding metadata is a security hole
<Zakim> dom, you wanted to react to dom
dom: we are not required for data itself to provide metadata
chai: in that case read the definition of each op
dom: not needing to dive into each op algorithm to understand if boundary risks might be created
chai: for simple operations, it's trivial, for complex operations like conv2d or recurring networks, you can't simplify it
ningxin_hu: for conv2d, we have a formula to calculate the output size based on the parameters of the operations
… would this be useful to the reviewers, or for machine processing?
dom: perhaps highlighting such formulas in the spec would work?
Running timeable things out of process
anssik: WG asked: "The group would like to understand how running timeable things out of process works as a mitigation?"
… Alex responded: "This is a concern of lower importance - mainly adding an ipc step will confuse any accidental high precision timers. Realistically there is not a lot to be done here!"
dom: IPC step mitigates the issue, but is it guaranteed to happen in all implementations?
RafaelCintron: I agree with Dom, we should not add IPC as a mitigation
dom: my suggestion is to mention the problem and mention the same mitigations as with high precision timing might apply here
Next step: Wide review for security
Security Considerations of "High Resolution Time" spec
Update Security Considerations per review feedback PR #251
Responses to the Self-Review Questionnaire: Security and Privacy
anssi: we have ongoing discussions on all issues except for #175
WebGPU Security Considerations
anssi: the WebGPU WG has done quite a good job on this topic, we should re-use what we can from them
Rafael: I know the WebGPU has gone through Google internal security review, and is about to go through the W3C review
… it has been under TAG review for quite some time
anssi: overall, it feels we're on good track to resolve these security issues
… once the pull request lands and hopefully addresses the issues, we can start the W3C security review
Candidate Recommendation technical scope
The baseline implementation of WebNN ops [cr]
The baseline implementation of WebNN ops
WebML WG Teleconference - 10 February 2022 resolutions
… review in progress, anything to report Ningxin?
ningxin_hu: we're waiting for a review from chai & his team on the conv2d implementation
Should WebNN support async APIs? [cr]
Should WebNN support async APIs?
chai: I'm working on a PR for this
anssi: thanks, very important work
Should restrict the sync APIs to only exist in Workers? [cr]
Should restrict the sync APIs to only exist in Workers?
anssik: on our 13 January 2022 call we decided to request feedback from ML framework authors, how this proposed change would impact the frameworks, in particular their Wasm backends.
… no responses received
… any new information to be shared?
… are we still happy to keep this issue in scope for CR?
WebML WG Teleconference – 13 January 2022
Integration with real-time video processing [cr]
Integration with real-time video processing
anssik: it seems the outstanding topic is the support for async API and interaction with GPU timeline, these changes will have an API shape impact
… is it fair to say this issue #226 is blocked on issue "Should WebNN support async APIs? #230"
Should WebNN support async APIs? #230
anssik: Ningxin, do you want to give an update on the Chromium prototype for WebNN/WebGU interop?
[Chromium Prototype] WebNN / WebGPU interop #929
ningxin_hu: formulating a plan for the prototyping assignment, working on that along with spec discussion
Add method steps to operations [cr]
<chai> i should have a PR out for #230 soon.
Add method steps to operations
anssik: this is just work that needs to happen, any questions to be recorded in the issue
anssik: Thanks everyone for joining and for your contributions!