This security issue was raised by @quidity (Thanks Alex!) in WebNN Chromium CL review where Alex mentioned:

it can't be good for the weights to be changed during the computation

I'm worried about compromised renderers - while JS can't change the weights a compromised renderer can. I'm not convinced that there won't be control flow differences or changes to assumptions based on weights (now or in the future) - for instance I could imagine an optimization that checks if something row is zero then retains that assumption throughout a computation.

This attack should be discussed in WebNN's Security Considerations section.

There are some related discussions in current WebNN spec:

1. The MLGraphBuilder.constant() method algorithm, in particular step 5 & 6, specifies that the content of weights is copied from the user-supplied ArrayBuffer and a platform constant tensor is created with that content.

Step 5. Let bytes be the result of invoking get a copy of the bytes held by the buffer source given bufferView.

Step 6. Make a request to the underlying platform to register operand as a tensor constant with bytes as value and store a reference to the corresponding implementation-defined object to operand.[[operand]].

2. There is also a Graph Initialization stage that does "weight preprocessing"

"weight preprocessing" where all the constant inputs to the graph are preprocessed and cached at the operating system level for subsequent graph execution calls.

IIUC, once the graph is fully compiled and initialized, the content of weights is copied to platform constant tensor and the platform constant tensor are preprocessed and cached by operating system. The WebNN implementation won't access the weights in user-supplied ArrayBuffer anymore, and there is not a surface where the JS / comprised renderer can access the platform constant tensor, so the comprised renderer should not be able to change the weights during the computation for such a attack.

/cc @wacky6 @RafaelCintron @wchao1115 @fdwr