+ Security and Privacy Considerations on Core and JS-API

[ericprud]

These sections will make it easier to transition to CR, and they are sections that folks habitually look for in specs.

ISSUES:

1. added as a regular section in JS-API but added as an appendix in CORE. probably fine.
2. broken refs to import and export in the JS-API Security section; should link into CORE

[rossberg]

Hm, I think this falls squarely into the category of design considerations and rationale. There is a lot that could be said and explained in that regard, not just about security, which is just one among many topics. Therefore, the CG decided early on that the spec is not the right place to include such discussion. So far, the design docs have been the place to document such considerations. The core spec's introduction only includes a very high-level summary of the design goals, which mentions sandboxing.

[binji]

This is a common section in w3 technical reports, see for example Pointer events, Accelerometer, Web Audio, etc.

Are you suggesting we have a link to the design docs in the spec document? Or that we omit this section entirely? Or perhaps reword the contents?

[rossberg]

It might be more adequate to move it to the Web API spec, because it seems specifically relevant to the web environment. For example, I can’t tell how privacy is even a meaningful consideration for an ISA on its own.

But on second thought I agree that it also might be helpful to briefly explain the basic security model enabled by Wasm and that it's mostly up to the embedder. This is closely related to the section on "Scope" in intro/introduction.rst, so introducing a new subsection right after that would be the most natural place (it seems a little short for its own appendix anyway). May I suggest the following wording:

.. index:: ! security, host, embedder,  module, function, import
.. _security:

Security Considerations
~~~~~~~~~~~~~~~~~~~~~~~

WebAssembly provides no ambient access to the computing environment in which code is executed.
Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking :ref:`functions <function>` provided by the :ref:`embedder <embedder>` and imported into a WebAssembly :ref:`module <module>`.
An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import.
Such considerations are an embedder’s responsibility and the subject of :ref:`API definitions <scope>` for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host's hardware, it is potentially vulnerable to side channel attacks on the hardware level.
In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.

(Intentionally leaves out Privacy as well as singling out specific embeddings or proposals.)

[Ms2ger]

It's not just common in W3C specs; it's formally required to enter the CR stage: https://www.w3.org/pubrules/doc/rules/?profile=CR#document-body

[rossberg]

@Ms2ger, well, that specifies a "should", notably not a "must". :) The points and questions listed in the guidelines are very specific to the Web context and mostly inapplicable to the Wasm core spec.

So one can argue that the Web API spec is the right place to satisfy this criterion at large. But I agree that a generic statement about security makes sense in the core spec.

[binji]

This security section looks good to me, @ericprud what do you think? I agree that many of the w3 checklists are difficult to apply to the core spec: I like to tell people "wasm can't really do anything." :)

[ericprud]

I updated the PR with @rossberg's suggestions:

@@ -1,10 +1,15 @@
+.. index:: ! security, host, embedder,  module, function, import
-.. _security-considerations:
+.. _security:
 
 Security and Privacy Considerations
 -----------------------
 
-On its own, WebAssembly provides no access to the native computing environment; all I/O is performed by marshaling data through functions exposed by the :ref:`import <syntax-import>` and :ref:`export <syntax-export>` operators.
-An implementation could provide access to native libraries by e.g. pre-defining standard functions.
-Such a system would have to define its security and privacy behavior.
+WebAssembly provides no ambient access to the computing environment in which code is executed.
+Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking :ref:`functions <function>` provided by the :ref:`embedder <embedder>` and imported into a WebAssembly :ref:`module <module>`.
+An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import.
+Such considerations are an embedder’s responsibility and the subject of :ref:`API definitions <scope>` for a specific environment.
+
+Because WebAssembly is designed to be translated into machine code running directly on the host's hardware, it is potentially vulnerable to side channel attacks on the hardware level.
+In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.
+
-As of the data of publication, the only host binding is the :ref:`Javascript Interface js-api`, which states how WebAssembly interacts with the web environment.
+As of the data of publication, the only embedder is the :ref:`Javascript Interface js-api`, which states how WebAssembly interacts with the web environment.
-Future versions will provide threads which can be used to create a high-resolution clock, which can be used for timing-based attacks (e.g. spectre).

I kept the "Privacy" part of the heading because:

1. it's a handy convention and a lot of people look for it during and after the transition to REC.
2. the description applies equally to privacy and security.

I kept a reference to js-api because I think that's what I think almost all readers will be looking for. If I understood how to do links into js-api, I'd add a link to that security section.

I moved the file up one level (hopefully correctly) so it would appear just before Conformance.

@rossberg, are you convinced by my arguments for "and Privacy" and the ref from core to js-api?

[rossberg]

I kept the "Privacy" part of the heading because:

• it's a handy convention and a lot of people look for it during and after the transition to REC.
• the description applies equally to privacy and security.

I don't see it saying or implying anything about privacy, nor can it. This document defines a virtual ISA, nothing else. An ISA is orthogonal to questions of privacy -- in the same way that no CPU manual could meaningfully talk about privacy.

I kept a reference to js-api because I think that's what I think almost all readers will be looking for. If I understood how to do links into js-api, I'd add a link to that security section.

I understand, but please remove it anyway. So far, the core spec -- very consciously -- avoids any reference to a specific embedder spec anywhere. For one, to underline that all embedders are equal and none has specific privileges, and perhaps also to avoid circular dependencies between documents. (FWIW, that ref won't work, it's just gonna be an undefined xref in Sphinx.)

I moved the file up one level (hopefully correctly) so it would appear just before Conformance.

Ah, we shouldn't create any rst files besides index.rst at the toplevel. Can you integrate the text into the existing intro/introduction.rst, such that it appears as a section after Scope? I think that's the most logical place for it.

[binji]

I've added an agenda item to discuss this tomorrow.

[rossberg]

Thanks!