Skip to content

Latest commit

 

History

History
259 lines (220 loc) · 14.4 KB

CG-08-08.md

File metadata and controls

259 lines (220 loc) · 14.4 KB
Raw

WebAssembly logo

Agenda for the August 8th video call of WebAssembly's Community Group

  • Host: Google Hangouts
  • Dates: Tuesday August 8, 2017
  • Times: 9:00am–10:00am Pacific Time
  • Location: link sent to registered participants
  • Contact:

Registration

Sign-up

Logistics

The meeting will be a Google Hangouts call.

Agenda items

  1. Opening, welcome and roll call
    1. Opening of the meeting
    2. Introduction of attendees
  2. Find volunteers for note taking (chair to volunteer)
  3. Adoption of the agenda
  4. Proposals and discussions
    1. Follow-up from Kirkland meeting
      1. Mailing list reshuffling:
        • public-webassembly is now for discussions, requires signup.
        • public-webassembly-announce is moderated and low-traffic, auto-signs up all CG members.
    2. Discuss timing of next in person CG meeting.
    3. Hold these video calls regularly? What schedule? (JF Bastien)
    4. WebAssembly Working Group (Brad Nelson)
      1. Planning and Logistics
      2. Discuss scheduling of future WG meetings
    5. Content Security Policy and WASM (Brad Nelson)
      1. Discuss clarifying current tight WASM CSP restrictions
        1. Strawman (for near term):
          • Similar to JF's proposal WebAssembly/design#1092
            • But avoids throwing from promise-returning methods Fails earlier (at compile)
            • Allows Tables + Memories Has baked in the understanding that we revisit loosening this at some point, likely as modules + WebAssembly becomes clearer.
            • When under an unsafe-eval policy, all methods are allowed.
            • When not under an unsafe-eval policy:
              • Throws a CompileError:
                • WebAssembly.Instance
                • WebAssembly.Module
              • Returns a promise rejected with a CompileError
                • WebAssembly.instantiate / WebAssembly.instantiateStreaming
                • WebAssembly.compile / WebAssembly.compileStreaming
              • Always allowed:
                • WebAssembly on the global object
                • WebAssembly.Memory
                • WebAssembly.Table
                • WebAssembly.validate
                • WebAssembly.CompileError
                • WebAssembly.LinkError
      2. Discuss allowing WASM in more places (in the future)
        1. Strawman (longer term):
          • WebAssembly modules or instances compiled from a Response with a URL set are treated similarly to JS code loaded via a script tag from a URL. Wasm compilation from a Response falls under script-src strict-inline has no effect on wasm compiles as they have no equivalent of inline.
          • The 'integrity' field in fetch()'s 'init' parameter can be used to specify sub-resource hashes at the request site, equivalent to <script integrity=. Combined with script-src , this allows execution of safelisted resources by content hash, not just URL..
          • There is no equivalent to <script nonce= (or need for it as there is no wasm equivalent to inline).
          • A Response is fine under policy if any of the following hold:
            • unsafe-eval is allowed
            • wasm-eval is allowed
            • It has a URL that is allowed by script-src
            • It has integrity metadata (piped through from its originating request, e.g. via fetch(..., { integrity })) that is allowed by script-src
          • When a Response is fine under policy all methods behave as currently specced.
          • When a Response is not fine under policy:
            • Returns a promise rejected with a CompileError:
              • WebAssembly.instantiateStreaming
              • WebAssembly.compileStreaming
          • When neither wasm-eval nor unsafe-eval are allowed:
            • Throws a CompileError:
              • new WebAssembly.Instance
              • new WebAssembly.Module
            • Returns a promise rejected with a CompileError:
              • WebAssembly.instantiate
              • WebAssembly.compile
          • Always allowed:
            • WebAssembly on the global object
            • WebAssembly.Memory
            • WebAssembly.Table
            • WebAssembly.validate
            • WebAssembly.CompileError
            • WebAssembly.LinkError
    6. Coordinating spec tests with WebPlatformTests (Ben Titzer)
      1. Discuss advantages / disadvantages of changing source of truth for some or all of Wasm tests to WPT.
      2. POLL: Should we strive to have some version of all Wasm tests as part of WPT?
      3. POLL: Should the source of truth for Wasm Web embedding tests live in WPT?
      4. POLL: Should the source of truth for Wasm JS embedding tests live in WPT?
      5. POLL: Should the source of truth for Wasm binary format tests live in WPT?
      6. POLL: Should we automate the process of commiting Wasm tests to WPT?
      7. POLL: Should we automate the process of commiting WPT test changes to Wasm repos?
    7. Presentation on JS/wasm modules integration, mostly stage-setting (Domenic Denicola)
    8. Bulk Memory Instructions (Ben Smith)
      1. WIP proposal
      2. Some initial performance numbers
  5. Closure

Schedule constraints

None.

Dates and locations of future meetings

Dates Location Host
2017-11-06 to 2017-11-07 Burlingame, CA TPAC

Meeting notes

Roll call

  • JF Bastien
  • Arun Purushan
  • Dan Gohman
  • Tyler McMullen
  • Deepti Gandluri
  • Richard Winterton
  • Pat Hickey
  • Brad Nelson
  • Ben L. Titzer
  • Vincent Belliard
  • Ben Smith
  • Thomas Lively
  • Domenic Denicola
  • Jason Yu
  • Arjun Sreedharan
  • Martin Becze
  • William Maddox
  • Peter Jensen
  • Sergey Rubanov
  • Luke Wagner
  • Eric Holk
  • Unbug Lee
  • Lars T Hansen
  • Mike West
  • Jacob Gravelle
  • Michael Holman
  • Limin Zhu
  • Benjamin Bouvier
  • Rick Byers
  • Michael Hablich
  • Andrew Koroluk
  • Ulrik Sorber

Agenda adoption

Brad seconds.

Mailing list reshuffle

JF explains reshuffle.

Timing of next in person CG meeting

Mozilla and Intel can host the next meeting. Intel in Santa Clara, Mozilla in Mountain View. Let’s just go with Intel for now.

Ben Titzer: is VC equipment good? Richard: yes. JF: Hosting process JF: try something between 1st and 3rd of November, just 2 days.

Video call regularity

JF: meetings have had enough content each time. Maybe hold bi-weekly, same time and Hangout link. Will continue sending official invites to list, but we can assume meeting is always happening. Brad: should I send a calendar invite? (yes)

WebAssembly Working Group

  • Brad: we now have an official Working Group. Finalize spec test, publish recommendations. Need to start holding meetings, imagining primarily video calls. Some timers in the W3C start when you have the first working draft, want to do that soon. Imaging monthly video calls. Will have brief face-to-face at TPAC, my not have any items of business. Will need to discuss JS and Web embeddings, should we block on those or tackle separately? Tentatively will hold first video call next week, Monday.

  • Join here

  • Home page

Content Security Policy and WebAssembly

Brad Nelson presenting.

  • CSP issue
  • CSP allows pages to set restrictions.
  • Would like to get everyone on the same page.
  • Browsers currently do different conservative things.
  • Promises should probably reject, not throw.
  • Throw EvalError, like other JavaScript things.
  • JF implemented compilation allowed because a Module can be postMessage’d.
  • Mike: threat model for CSP isn’t protecting bugs in implementation. It’s preventing user-generated content from being executed. Compilation without execution isn’t something CSP cares about.
  • Luke: agreed. It’s about strings finding themselves in eval strings.
  • Domenic: it’s also binary blobs.
  • Brad: CSP folks don’t care because it’s about code execution?
  • Mike: I don’t care about protecting V8. As long as we prevent code execution I’m fine.
  • Brad: given this, I don’t have a preference.
  • Brad: in original WebAssembly API resources aren’t URL-bound, this allows JIT-code generation. A better approach would tie in with streaming API, script-src locations would “enhance” Response, and URL wouldn’t be forgeable.
  • Mike: I think CSP already assumes URL can’t be forged. Step 5 already checks outgoing response, and 17 checks the incoming Response.
  • Brad: there’s option on fetch to specify a hash. Integrity field. You can carry it through and reference it elsewhere.
  • Mike: would be useful to distinguish SRI and CSP.
  • Domenic: I thought so too, but CSP has script hash.
  • Mike: I think it’ll work different from script tags. We call fetch internally when dealing with a script tag. Whereas with WebAssembly you fetch, pull data, and do work on the blob.
  • Mike: currently we don’t persist SRI information in response.
  • Domenic: that’s the proposal, allow integrity field to carry through.
  • Mike: it might not be a big deal to do this.
  • Brad: allows more flexibility about where the hash goes.
  • Mike: allows you to allow scripts from arbitrary sources, as long as the hash matches.
  • Brad: in addition to unsafe-eval, also have wasm-eval allowing just WebAssembly and not JavaScript.
  • Luke: let’s also have discussion of whether unsafe-eval covers WebAssembly, has consequences. Let’s do it as a separate issue.
  • Action item JF: will file tracking issue, Brad to champion.

POLL: encourage work in the general direction of the strawman presented by Brad

Yes

Coordinating spec tests with WebPlatformTests

Ben Titzer: There’s a repository for web platform wide tests. There’s tests in the spec repository which tests implementations, then JS and Web platform tests. Question is where all that should live. With the spec right now, there’s the reference interpreter which has the wasts for the engine tests, and place-holders for what would be web platform tests. They need more work. Question is where they should live. Where would the source of truth be? Rossberg thinks wast tests and JS API tests should stay in spec repository. For developing WebAssembly adding new things is easier if it’s all together.

  • Rick Byers: over the last year we’ve shifted how the web evolves. Disciplined about testing, it used to be a disaster. Web platform interoperability as of 1.5 years ago. We created a dashboard at wpt.fyi. We (Google) have about 10 people working on this. CSS folks a while ago moved all their tests into the web platform test repo instead of duplicating tooling. We also have tooling for pull requests, will run tests on all platforms, won’t allow flaky results. WHATWG has a policy: all normative changes must come with a web platform test PR. It’s a bit of a pain to track in separate repos, but people love it eventually.
  • Luke: we’ve done some work, but looking at contracting Igalia to sync tests bi-directionally. Having web tests in web platform tests seems fine. Keeping wasts in spec tests sound good. The JS ones are kind of in the middle. We could do whatever.
  • Domenic: agree. We do lose some of the benefits of the tooling if you keep them with the spec. It sounds like wast tests require more infrastructure.
  • Ben Titzer: the granularity is coarse. Maybe we can move them in coarse grain to the web platform tests.
  • Luke: non web platforms will want to run the wasts.
  • Domenic: there’s good support for this on the web platform test infrastructure. Maybe having a generation step.
  • Rick: we invest heavily, 10 person team, includes a contract with Bocoup who do test262. Anything that leverages web platform tests we can help.
  • Brad: would you be able to set up a two-sided commit for a slide of the test that lands in V8?
  • Rick: we can explore. How do we generalize import / export. I don’t know enough.
  • Mike Holman: yeah it’s complicated for us because all our JavaScript stuff is on GitHub and we have to integrate back to get web platform tests. Anything that would make it better would be great.
  • Tyler from fastly: there are applications for WebAssembly outside of browsers. It would be fine in WPT, but having source of truth in spec would be good. Our applications are outside of browsers. Having the web platform tests is weird, but it could be fine.
  • JF: good point, would it be OK for WPT to run non-web gating tests?
  • Rick: there’s a public test infra mailing list. Could be OK.

Links from Rick on WPT: W3C web-platform-test blog Centered around investments specifically in web-platform-test Chrome has a ~10 person team Ecosystem Infrastructure team charter Web-platform-test chromium infrastructure status update Web-platform-test dashboard PR build bot - being replaced with a more powerful results server Chromium and Firefox have tooling for import/export, Apple and Microsoft looking at something similar Using web-platform-tests in chromium

JavaScript / WebAssembly module integration

Punt to next meeting.

Bulk memory instructions

Punt to next meeting.