Update Security Considerations per review feedback #251
Conversation
anssiko
force-pushed
the
security-considerations
branch
from
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. |
anssiko
requested review from
huningxin and
wchao1115
and removed request for
huningxin
- 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 |
|
@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.
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.
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 <[email protected]>
Co-authored-by: Ningxin Hu <[email protected]>
Note: to be adjusted if the selection becomes normative Co-authored-by: Dominique Hazael-Massieux <[email protected]>
Co-authored-by: Dominique Hazael-Massieux <[email protected]>
Co-authored-by: Chai Chaoweeraprasit <[email protected]>
|
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