-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Security Considerations per review feedback #251
Conversation
206eda5
to
4549a67
Compare
@wchao1115 @huningxin I'm marking this PR as "Ready for review". My expectation is the first PR that lands will be amended in subsequent PRs as we receive further review feedback. It is fine to have inline issues as reminders in the spec too, but if we're able to fix those via PR review process that'd be of course great. |
- Add reference to [security-privacy-questionnaire] - Editorial updates
Address the following security review feedback: - "Notion that the API introduces a new scripting language" - "Running timeable things out of process"
Here's a direct link to the visual diff of the Security Considerations this PR updates: https://pr-preview.s3.amazonaws.com/webmachinelearning/webnn/251/19a09ab...69db252.html#security |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this PR, @anssiko !
@dontcallmedom @wchao1115 PTAL prior to the WG's call this week. |
|
||
Issue: Hinting partially mitigates the concern. Investigate additional mitigations. | ||
|
||
The API design minimizes the attack surface for the compiled computational graph. The {{MLGraphBuilder}} interface that hosts the various operations is a data definition API and as such doesn't execute anything, only constructs data. What follows, is that the potential for an attack is limited to when binding the data to the graph before executing it by invoking the {{MLGraph/compute()}} method. This enables implementers to focus on hardening the {{MLGraph/compute()}} method. For example, by making sure it honors the boundary of data and fails appropriately when the bounds are not respected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will need an editorial update if/when #257 lands
index.bs
Outdated
|
||
Issue: Investigate side channel attack feasibility considering the current state where CPU is shared between processes running renderers. | ||
|
||
In order to not allow an attacker to target a specific implementation that may contain a flaw, the [[#programming-model-device-selection]] mechanism is a hint only, and the concrete device selection is left to the implementation. As a further mitigation, no device enumeration mechanism is defined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually important for the applications to understand how a device is selected and that the device selection rule, if we would have one, should be a normative behavior and not merely informative.
@wchao1115 @dontcallmedom @huningxin thanks for your comments, we're iterating toward a mergeable PR. For discussion on this week's call. |
Co-authored-by: Ningxin Hu <ningxin.hu@intel.com>
Co-authored-by: Ningxin Hu <ningxin.hu@intel.com>
Note: to be adjusted if the selection becomes normative Co-authored-by: Dominique Hazael-Massieux <dom@w3.org>
Co-authored-by: Dominique Hazael-Massieux <dom@w3.org>
Co-authored-by: Chai Chaoweeraprasit <wchao1115@hotmail.com>
During today's call https://www.w3.org/2022/03/24-webmachinelearning-minutes.html#t02 we agreed to merge this PR to better enable another round of review and further iteration as more feedback comes in. |
@dontcallmedom can you check gh-pages deploy for issues. Build passes but not yet deployed. |
it seems to have gone through now |
Fix #241
Preview | Diff