- Where: zoom.us
- When: August 21, 4pm-5pm UTC (August 21, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: JF Bastien
- Email: [email protected]
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email JF Bastien or Ben Smith to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- AI(titzer@): Discuss w/ domenic@ and others about WebAssembly CSP
- AI(dtig@): collect previous CG notes about SIMD into GH issue
- Update on WebAssembly threads spec work progress (Conrad Watt)
- Proposal to specify dependencies between features (Thomas Lively)
- Discuss change (PR) to WebAssembly ES module integration (Lin Clark)
- Discuss licensing for WebAssembly source code (see discussion here) (Alon Zakai)
- Review of action items from prior meeting.
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Benjamin Bouvier
- Ben Smith
- Ben Titzer
- Conrad Watt
- Deepti Gandluri
- Derek Schuff
- Jacob Gravelle
- Jay Phelps
- JF Bastien
- Lars Hansen
- Lin Clark
- Luke Wagner
- Sergey Rubanov
- Shiv Kushwaha
- Sven Sauleau
- Thomas Lively
- Till Schneidereit
- Tyler McMullen
- Yury Delendik
Deepti seconds
I had an internal conversation about this, tried to take polls of where things are. Eric holk wrote a proposal, I inherited. Discussed with Domenic. We need to get buy-in from other browser vendors. JF will implement what is spec’d. Luke less enthusiastic. Haven’t heard from MS.
Potential API design issue -- subresource integrity. Adding a URL that is robust to responses. May have effects on web API surface. Like to hear from other people on the call.
LW: Can you briefly summarize what is in the proposal.
BT: Basically activates certain APIS depending on what directives are there. For example wasm-eval. Unsafe-eval activates all of them.
[BT presenting csp proposal]
We should figure out what the table should like and get everyone to have the same values.
LW: Presumably instance is also allowed?
BT: I think there’s an entry missing.
LW: instantiate is tricky since it has two different behaviors. One can get modules from lots of places. Some may be blocked others might not.
BT: Includes wasm-eval directive which enables these things but nothing else. Also includes adding origin to response, so that link is always there and trustable. Wherever that response goes it comes with URL and that would be allowed according to CSP policy.
LW: Where did the SRI fit in to it?
BT: tbh, I don’t understand that part of the proposal.
JF: SRI says you match based on hash instead of origin.
LW: I thought that was per resource, how does that work site-wide.
BT: Basic mechanism makes sense, how does that work with certain APIs. Do you have to provide hash to compilestreaming and instantiatestreaming. May need API changes.
JF: I thought the next step is to get a meeting with CSP subgroup. Two people at Apple would want to be in that. Brad had lukewarm enthusiasm on Google side. I think that’s the next step.
BT: JF can you help me connect with those people. And other people in the room on board.
LW: [csp person @ mozilla]
JF: [csp people @ apple]
I’ll send you the names on Apple’s side. I think it was supposed to be a w3c subgroup that does this.
BT: Part of the web-embedding is that the idea?
AI(BT) set up the meeting with relevant security folks.
DT: I’ve done that. Not sure there is something to discuss right away. But if folks have things to take a look. I’ve summarized the instructions, feel free to update the issue. WebAssembly/simd#37
CW: Since the last update semantics hasn’t changed. The wider spec has changed. JF pointed on that we should perform bulk-memory operations byte wise and should perform a trap if oob.
We’re using abstract time stamps, instead of JS way. It fits on just a few pages. In terms of spec work, we’d like to move to stage 2. For this work it’s easier to do formal first and english afterward. Are people OK with this first? Kind of procedural question. Actual semantics is pretty fixed. Interop with bulk-memory op is up for question.
AR: To add to that: streamlining formulation makes it nicer to digest for reader. Try to put it into shape that fits with style of spec, smaller on paper. Easier to understand. There’s massaging to do still.
People seem ok with formal part of spec first for stage 2.
TL: Coming at this from a practical perspective. Some SIMD instructions require sign-extension logic. Would be nice to reuse logic from sign-extension proposal. Trivial catalyst for this idea. Specify that certain features depend on other features. SIMD depends on sign-extension for example. To be spec-compliant would require sign-extension for SIMD.
Make testing simpler: if they are independent it is more combinations. Reduces the number of test cases. Reduces the number of executables that need to include.
Just an idea.
LH: We already decided to do this for threads proposal since we split it up.
DS: We kind of agreed to this, though threads doesn’t really require the other split proposals.
BT: This will happen again with GC proposal requiring reference types.
TL: Can’t really say that SIMD requires sign-extension directly -- we may just want to do it to limit the combinatorial explosion.
LW: There’s a difference between dependent features, and optional features. We should try to get SIMD everywhere so folks don’t have to scalarize. If you want to operate in that 2-year window where you have features that are in some browsers but not others. But it shouldn’t be the case for the future.
DS: I was thinking about this already with tools, since I don’t think browsers will have SIMD without sign-extension. Also w.r.t. Optional features. We decided we wouldn’t have versions, rather have feature testing. Now you’re saying something more like versions?
LW: I think there’s a difference between optional and non-optional features. Depends on rollout. Fundamental difference between rollout window things and optional features. Blockchains may never have threads.
DS: Do we want to formalize any of these things.
LW: During the rollout, to make people’s lives easier, lets implement things in this order.
DS: We’ve got these implementation defined limits, not part of the formal spec but it makes it easier.
LW: I see this now.
DS: For example: Please nobody do threads w/o bulk memory.
AR: Similar issues with spec writing, some things are easier in one order.
TL: right now we have a feature flag for “give me SIMD”, but you expect that some of these features will be non-optional in the future. So would you be OK with remove the flag from LLVM at that point?
LW: I don’t know about that, maybe the default flips to on. Toolchain thing: maybe you have a wasm-standard-2019 or something.
DS: I think there will be a product decision for the toolchain, spec can say what it will.
BT: Some implementations may never have SIMD, standalone or embedded. Polyfill SIMD, user-level wasm but may just want scalar.
LW: They may do that at their own peril -- may be given wasm modules that they won’t understand.
DS: This happened with NaCl, Samsung put it in a TV, will happen with wasm too.
AR: Some things we may want to be optional in the spec: threads, SIMD. I think there are good reasons for this.
LW: Just lowering to scalars?
BT: It’s a bunch of work.
AR: It’s code size too.
LW: Surprised if it was a factor of 2. Some of these tiny devices, they’re precompiling the wasm to machine code. Anyway, this feature is a fair amount of work to optimize. Not prohibited by the platform.
JP: Might not support SIMD so it’s clear that you won’t get performance benefit.
LW: Came up before -- we discussed this with intel vs arm ops that you may be able to probe whether an instruction is fast or slow.
BT: I’m not going to advocate not implementing SIMD.
...
AR: isn’t this about when we move stuff into the repo?
TL: my example was about dependency on sign-extension.
BT: Might not call sign-extension a feature.
TL: Even small things maybe should be. So we can have different meanings of spec-compliant.
AR: Separate problems: optional features vs. order of features that are added to spec.
AI(TL): Thomas will write up this point.
LW: You can imagine a graphviz doc about this, showing dependencies.
DS: For feature testing, that would be useful. It would not rise to the order of actual feature dependencies, but it might
AR: Don’t want to encourage fine-grained feature testing of non-optional features. Version of standard supported is right granularity, testing matrix too large otherwise.
BT: We may want an appendix to that describes the difference between 1.0 and 1.1 -- this delta named sign-extension. Non-functional otherwise, but puts a name on the group. Will allow fine-grained slicing.
AR: We do want a changelog appendix somehow.
BT: In some ways we’re forced to do fine-grained logging in the spec process. It’s not normative, just happens to be useful.
Discuss change (PR) to WebAssembly ES module integration (Lin Clark)
LC: That PR gives the detail, but I wanted to give more status on this. We need to restructure how modules work since last time I discussed this. How it is integrated I mean. They will link the ES module instantiation phase, but not do the instantiation work in that phase. It would run that step later. There is some concern on the terminology. Till had a suggestion to rename the phases in TC39. I’m going to try to do that. Wanted to let folks on this call know. There’s also an update on future progress: Dan E. from Igalia will work with us, doing the spec text after PTO on Sept 5th. If you have concerns about how we’re doing this, please chime in before then. They’re also going to do tests for bundlers so we can know whether they’re following the semantics we intend. Expect to complete before TPAC, ready for implementation -- some engines have said they’re interested in working on this so I’ll reach out to them.
DS: On the tools: is this something that... no concrete plan to generate anything compatible with this. Rust folks?
LC: We have been working with the rust folks, can circle back with them when we’ve made progress on the spec text.
LW: There is a bug on emscripten that says it is stuck.
AZ: We have a flag [missed this]. There’s no work on that that I’m aware of.
DS: It’d be cool, but it would be a lot of work.
JP: What about the loader spec?
LC: That’s not being worked on.
TS: For rust The plan is to emit ES6 modules, we also have wasm-bindgen tool. For must uses people will want to load a JS module that wraps the wasm module into a higher-level API. But where possible we’ll want that.
Discuss licensing for WebAssembly source code (see discussion here) (Alon Zakai)
AZ: This is about a specific angle. Binaryen and wabt are apache2 license. Good license, but not good for embedding in GPL2 like QEMU. The person who wants to do this, but the license worries them. LLVM is in the same situation, maybe we should change our code projects to apache2 + exceptions. Any thoughts or issues about this?
DS: No questions, but I think we need to check with lawyers. Following LLVM seems good. They’ve done good work here. I trust their process.
AZ: They’ve documented all the stages for how they’ve done this.
DS: We’ll have to track down the contributors and convince them. Another thing: do we even want this to be owned by the CG? Currently need to be a member of the CG to contribute. It is true for these 2 projects. We talked about removing them from the subgroup. If we did that, it wouldn’t be something that the CG would have to take an opinion on this.
BS: Someone needs to be on the hook for this.
DS: I would be ok taking this on AI(DS) figure out relicensing. As long as we brought it up: do we have opinions about removing wabt and binaryen as projects of the CG?
JP: I wasn’t around for that discussion -- tl;dr for benefits of it being under the CG?
DS: The reason it was under the CG in the beginning to be conservative and careful. I don’t think there’s much risk here. Most of the other projects don’t have this problem, just the 2. I’m pretty comfortable with moving them out, but haven’t made any progress on this.
Does anyone care if I push forward with this?
[silence]