Intent to Ship: WebAssembly Content Security Policy

186 views
Skip to first unread message

Francis McCabe

unread,
Sep 23, 2021, 5:36:20 PMSep 23
to blink-dev

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

wasmwebassemblycsp

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



Geckohttps://github.com/mozilla/standards-positions/issues/580

WebKithttps://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

unread,
Sep 30, 2021, 3:15:04 PMSep 30
to Francis McCabe, blink-dev
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

unread,
Sep 30, 2021, 3:19:06 PMSep 30
to blin...@chromium.org

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

Francis McCabe

unread,
Oct 5, 2021, 3:15:44 PMOct 5
to blink-dev, Daniel Bratell
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

unread,
Oct 6, 2021, 2:05:26 PMOct 6
to blink-dev, Francis McCabe
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

unread,
Oct 6, 2021, 6:11:48 PMOct 6
to blink-dev, oli...@oliverdunk.com, 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

unread,
Oct 7, 2021, 3:25:58 AMOct 7
to Francis McCabe, blink-dev, oli...@oliverdunk.com, Francis McCabe
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.

Daniel Bratell

unread,
Oct 7, 2021, 3:58:29 AMOct 7
to Yoav Weiss, Francis McCabe, blink-dev, oli...@oliverdunk.com, Francis McCabe
Reply all
Reply to author
Forward
0 new messages