Intent to Ship: WebAssembly Content Security Policy

[Francis McCabe]

Contact emails

ad...@chromium.org

f...@chromium.org

Explainer

https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md

Specification

https://github.com/w3c/webappsec-csp/pull/293

Design docs

https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md

Summary

Enhancements to Content Security Policy to improve interoperability with WebAssembly.

The change involves adding a new CSP source keyword: wasm-unsafe-eval that would allow a web page to compile and execute WebAssembly modules. 

Blink component

Blink

Search tags

wasm, webassembly, csp

TAG review

Not needed in our view, as this is a very small change to existing CSP functionality.

TAG review status

Risks

Interoperability and Compatibility

Gecko: https://github.com/mozilla/standards-positions/issues/580

WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-August/031974.html

Web developers: There has been a considerable amount of discussion of this within the WebAppSec WG and there is some pressure from developers to adopt this (see https://bugs.chromium.org/p/chromium/issues/detail?id=841404 and https://bugs.chromium.org/p/chromium/issues/detail?id=948834 and https://bugs.chromium.org/p/chromium/issues/detail?id=915648)

Debuggability

Is this feature fully tested by web-platform-tests?

Yes * CL https://chromium-review.googlesource.com/c/chromium/src/+/3171519 under review

Flag name

Blink feature flag WebAssemblyCSP

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=841404

Estimated milestones

M96

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5499765773041664

[Mike West]

LGTM1.

We've talked about this approach in WebAppSec a few times, and I think there's general agreement on the approach. I'd like to see the spec language land before shipping this, but it looks like there aren't any substantive outstanding questions, and I'm confident you can work out the details.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE65UWAc3Y07YDx%2B%3DiKRboZZGFGXzE5FbufUnY__0_w8nsXSRA%40mail.gmail.com.

[Daniel Bratell]

Hi Francis,

I read in the explainer that you had explored reusing currently exiting script-src policies but thought that would break existing content. Could you expand a bit on how you reached that conclusion?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Ddo5P0QE4k9uyxCo0HoWUBGYkd6BB4d4uc1GmKhX%3Dh-qA%40mail.gmail.com.

[Francis McCabe]

Note: this was pointed out to me by mkwst@ ... 

The scenario is that a web site publishes a script-src policy (without otherwise mentioning webassembly), not expecting it to enable any wasm execution. Extending the coverage of script-src would extend the footprint of files accessible from that developer's domain.

Note: in discussion between mkwst@ and ann...@mozilla.com, they agreed that this is not necessarily a serious extension. I am not personally sure of the conclusion they reached.

In the end, there was consensus multiple levels that it would (a) not be a good idea to  extend script-src and (b) to have a new policy source tailored for WebAssembly. Tentatively called 'wasm-src'. One potential feature of this could be that it would not support any white listing of domains; i.e., only use nonces (hashes don't seem to be a good fit because wasm files can be extremely large).

However, any new wasm-src policy effort will take significant time to develop and this proposal should not be gated on that.

I hope that this helps.

Francis

[Oliver Dunk]

Hey! Just to confirm, it seems like this change wouldn't impact extensions at all? My understanding is that the current implementation supports extensions by adding the chrome-extension:// URL scheme to an allow-list. With that in mind, I imagine the implementation here would be removing that allow-list but keeping the behaviour for extensions otherwise the same?

[Francis McCabe]

Confirming: there is no current plan to modify how extensions would work.

I was alluding to semi-solid thoughts on how a possible wasm-src policy would work. But, in any case, wasm-unsafe-eval would continue even without any new wasm-src.

Also, currently, extensions (and only extensions and chrome apps), can use the 'wasm-eval' policy source keyword. There was a lot of discussion about using wasm-eval for normal web pages but the community eventually decided against doing that.

wasm-eval will continue to work for extensions. But, IMO, that sets up a problem for the future. Chrome extensions will be able to use wasm-eval; but noone else will (they will have to use wasm-unsafe-eval, or, in the future, a wasm-src policy). I can see there being some pressure to normalize this down the road.

[Yoav Weiss]

LGTM2

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339519e8-ab1c-4a84-b332-dc49bdcd6b72n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWaXo5d362EEhmtcHAMtmJPPqc9rOk2J9N_58mzELnG9A%40mail.gmail.com.