WebAssembly 2024-10-07 > 2024-10-31

[dschuff]

In the issue title above add the document name followed by the date of this request, then the date of your proposed deadline for comments.

• name of specs to be reviewed: WebAssembly Core 2.0, WebAssembly JavaScript Interface 2.0, WebAssembly Web API 2.0

• URL of spec: https://www.w3.org/TR/wasm-core-2/, https://www.w3.org/TR/wasm-js-api-2/, https://www.w3.org/TR/wasm-web-api-2/

• What and when is your next expected transition? CR for 2.0, to transition as soon as reviews are finished (the date provided is not a hard deadline)

• What has changed since any previous review? The specifications contain change history sections summarizing additions to each spec (core, JS, Web)

• Does your document have an in-line Privacy Considerations section, ideally one separate from the Security Considerations? If not, correct that before proceeding further. Yes, although the considerations are spread out across the 3 layers as appropriate, as many considerations which may arise on the web (e.g. same-origin policies) are outside the scope of the core and/or JS specs.

• Please point to the results of your own self-review (see https://w3ctag.github.io/security-questionnaire/ , https://w3c.github.io/fingerprinting-guidance/, https://tools.ietf.org/html/rfc6973): Self-review of security and privacy questionnaire for 2.0 CR transition WebAssembly/spec#1830

• Where and how to file issues arising? https://github.com/WebAssembly/spec/issues

• Pointer to any explainer for the spec? The spec as a whole does not have an explainer but see below.

This is a request for transition for version 2.0 of all 3 WebAssembly specifications, namely the core spec, which defines the core code format and semantics;
the JS API specification, which provides a JavaScript API for interacting with WebAssembly; and the Web API specification, which describes the integration of WebAssembly with the broader web platform.

For review convenience, here is a list of the explainers for the proposals that have gone into 2.0, compared to 1.0 (currently in REC state). These are informal descriptions of the proposed changes and are not canonical, but describe an overview of the feature and could be useful in determining whether there is anything of interest for horizontal reviewers.

Note also that the specifications contain change history sections summarizing additions to each spec (core, JS, Web)
listing and summarizing additions since version 1.0. The table summarizes the effect on the JS spec. The Web spec is unchanged since 1.0

Explainer	Specs affected
Nontrapping float-int conversion	Core
Sign-extension operators	Core
Multi-value block and function returns	Core, JS
JS BigInt Integration	JS
Reference Types	Core, JS
Bulk Memory and table instructions	Core
SIMD Vector instructions	Core

[NalaGinrut]

hi folks!
Thanks for all the efforts!
I'm the IE of PING. And I'll spend some time to take a look at it.

[NalaGinrut]

Here are the brief result of the review. This review is only for the new released part, if I think there's any part should be reconsider, I will raise other issue. The privacy review result will be showed with ⭕ or ❌ or ❓.
For the ❓ case, please answer my question. Thanks!

WASM Web API

Registration for the application/wasm media type. ⭕

Result: fine.

WASM JS API

Multiple Values ⭕

Result: It's an abstract concept within the VM implementation layer, simply wrapping function returned multiple values into an array. This process is generally transparent to web users, so from this perspective, I don’t see a privacy concern.

BigInt Integration ⭕

Result: support bigint, no privacy concern.

Reference types ❓

Question: If I wrap a privacy info into a closure, and export it from a module to other module, considering WASM blob is a blackbox, is there effective way to mark this closure, or trace its activity in the Call Hierarchy?

WASM Core API

Reference types ❓

Same question as above.

Others ⭕

Thanks!

[dschuff]

An externref-typed reference can refer to any JS value and (from the point of view of core wasm) is opaque; there is no way to specially-designate or mark a reference as having a particular property such as containing sensitive information. Having said that, I think the general problem of taint-tracking values as they flow around the program is basically the same in the JS+Wasm system as it is with plain JS. Reference-typed values that flow into (or out of) Wasm are passed via an import or export; for example being passed in as an argument to an exported function, as a return value from an imported function, or written into a table via the argument to the Table.set() API. If you had an existing JS taint-tracking system and you wanted to follow such values into Wasm, you would augment that system to be aware of wasm instructions that handle references (currently there are few, e.g. getters/setters on locals, globals, and tables; select, ref.func). Then you would make it understand the wasm instantiation API so that it could follow values as they travel from JS to wasm and back. Actually the problems seems much more tractable compared to the already-existing problem you'd have with JS alone, since wasm is statically-typed and validated, and has no APIs outside of the interface to JS.

[pes10k]

hi @NalaGinrut , i just wanted to check on the status of this review.

If there issues or questions that need to be discussed (or discussed more) before the spec advances, could you please do the following:

• open an issue for each item in the WebAssembly repo's issue list
• link to them from this issue (to document that the issue was created from the PING / PrivacyWG review
• close out this issue (or let me know and I will)

Our goal is just to make sure this repo is accurately tracks what reviews still need to be conducted.

Thanks for your help, care, and expertise!

[NalaGinrut]

@pes10k I think it's finished. I may raise issue for new concerns. Now I close it.
To all folks here, thank you very much for all the support!