Web Neural Network API 2025-03-20 > 2025-06-20

[anssiko]

• name of spec to be reviewed: Web Neural Network API

• URL of spec: https://www.w3.org/TR/webnn/

• What and when is your next expected transition? CRS planned in Q2 2025

• What has changed since any previous review? See Other comments.

• Does your document have an in-line Privacy Considerations section: https://www.w3.org/TR/webnn/#privacy

• Please point to the results of your own self-review: https://github.com/webmachinelearning/webnn/blob/main/security-privacy.md

• Where and how to file issues arising? https://github.com/webmachinelearning/webnn/issues

• Pointer to any explainer for the spec? https://github.com/webmachinelearning/webnn/blob/main/explainer.md

Other comments:

This API has received privacy review in 2021, 2022 and 2024. The following are the key changes that the group believes are of interest to privacy reviewers since the previous review took place:

New API to identify feature support per operator. The opSupportLimits() method allows developers to probe feature support per operator so that the optimal model architecture can be chosen ahead of time. With this information, the compatible model weights can be downloaded on the first attempt without costly trial and error (weights are typically large). The information exposed by this API roughly corresponds to the underlying operating system and/or browser version, thus the group believe this feature does not add to the entropy significantly.

Removal of the device type preference. The device type indicated the application’s preference for the kind of device used for the compute: "cpu", "gpu", or "npu". This device type abstraction represented by MLDeviceType was removed (see Device Selection Explainer) to mitigate the issue reported in the earlier privacy review:

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?

[sandandsnow]

@anssiko, re: New API to identify feature support per operator, does this only provide information about what the browser provides? When you say "roughly corresponds" what do you mean?

[anssiko]

re: New API to identify feature support per operator, does this only provide information about what the browser provides?

Correct. You can think of the WebNN API as an abstraction layer on top of the major ML APIs (that ship with the OS) and libraries (that ship as part of the browser). The WebNN API does not provide any information about the underlying ML APIs or libraries.

When you say "roughly corresponds" what do you mean?

Given the above, the feature support per operator can be inferred from the OS and browser version. We believe the explicit method is a more convenient way for web developers to understand feature support than OS and browser feature detection. This design also provides an extension point for privacy controls should such a need arise in the future, e.g. if the ecosystem would diversify significantly from its current state.

Thank you for your review feedback!

[sandandsnow]

@anssiko as a follow-up from our discussion, it would seem helpful in the spec to explicitly communication that this capability doesn't add entropy, that it is just a more convenient way of discovering feature support information that can be inferred from the OS and browser version already.

Obviously, we are concerned that the capability does not reveal anything more than can be inferred currently from the OS and browser version and that it doesn't do that in the future. We note that the design provides an extension point for privacy controls should the need arise. Rather than waiting, we would ask the WG to ensure those privacy controls and mitigations are in place to prevent the capability from being used for fingerprinting, etc.