Skip to content

2022-07-28.md

Latest commit

 

History

History
110 lines (104 loc) · 5.01 KB

2022-07-28.md

File metadata and controls

110 lines (104 loc) · 5.01 KB

Meeting 2022-07-28

Attendees

  • Luca Casonato
  • Andreu Botella
  • Chengzhong Wu
  • Daniel Ehrenberg
  • Ethan Arrowood
  • Filip Skokan
  • James Snell
  • Maxim Shirshin
  • Romulo Cintra
  • Tianxing Yang
  • XadillaX Scarlet

Action Items

  1. Create a spec PR for Web Crypto for crypto.subtle.timingSafeEqual() and gather feedback from browser vendors.
  2. Collect usecases for AbortSignal composition that would be useful for us in issue on common API. Communicate this the HTML authors.
  3. Collect usecases for the web where this behaviour change would be useful. Communicate this feedback back to the spec authors.
  4. Post the explainer for WebCrypto streams to the new WebKit spec positions repo.

Notes

  1. Introductions
    • Welcome Andreu!
  2. crypto.subtle.timingSafeEqual():
    • Workers is getting an implementation matching Node.js
    • Proposing this to WebCrypto; no hard disagreement expected
    • Takes two ABs or ABViews (must be same length), and compares them timing safely. Returns a boolean indicating whether they are equal.
    • However, if it doesn’t land there we will make it apart of WinterCG agreement
    • Ongoing work in WASM about constant time operations - if interested get in touch; Daniel Ehrenberg can facilitate
    • What the policy around shipping without explicit buy in from browser vendors?
      • Luca: Deno is ok if there is no pushback from vendors, and no competing alternatives exist.
      • Dan: We should be careful around buyin from browser vendors. The approach seems pragamatic.
    • ACTION ITEM: Create a spec PR for Web Crypto for crypto.subtle.timingSafeEqual() and gather feedback from browser vendors. Can we get buy in?
  3. AbortSignal.any() - composing abort signals
    • Can either be manually aborted or aborted by a timer/automatic
    • Lots of interest, but no forward momentum
    • We as WinterCG can help provide that momentum; don’t expect major pushback
    • Outstanding issue is just the shape of the API. Do we have a preference between composability (signal1 + signal2 -> signal3) vs following signal (mut signal1 + signal2 -> signal1)?
    • Daniel Ehrenberg can help get folks in touch if they are interested in helping
    • ACTION ITEM: Collect usecases that would be useful for us in issue on common API. Communicate this the HTML authors.
    • Also take a look at other AbortSignal conversations in whatwg/dom, like reason, throwIfAborted, and timeout.
    • AbortSignal.reason was never propagated into the fetch spec: whatwg/fetch#1343.
  4. ReadableStream tee backpressure
    • When reading from one branch in a tee’d stream, data will accumulate in the other branch with no back pressure indicator
    • This is an issue for Workers and possibly other server side runtimes.
    • This is unsolved in current spec
    • James is working on a new implementation to solve this
      • First he wants to solve the implementation
      • Then he will draft the proposal for the necessary changes for the spec
      • Expects it to be non-trivial
      • Estimate by Mid August
      • Risk of push back since it could change behavior, but we don’t really know the accuracy of how much this is currently affecting folks
    • Has anyone been affected by this?
    • Pushback from streams spec authors was primarially around complexity. If there are web use-cases for this, they may be more interested.
    • ACTION ITEM: Collect usecases for the web where this behaviour change would be useful. Communicate this feedback back to the spec authors.
  5. Workstream updates:
    1. Common APIs: no updates.
    2. Crypto streams:
      • Some feedback received: some interest, no objections, no one jumping to implement.
      • ACTION ITEM: Post the explainer to the new WebKit spec positions repo.
    3. Fetch:
      • Ongoing discussion on relative URL support
      • Last Call Summary:
        • Agreed that we can ignore CORS and CORS-related requirements
        • Ignored things can be unimplemented (undefined)
        • Discussion on set-cookie header. New API in Fetch being discussed (getSetCookie), we will look to adopt what they decide: whatwg/fetch#1346
        • Half-duplex request streams are landing in Chrome. We made sure that the door is still open for full-duplex request streams in the future. whatwg/fetch#1254
    4. Environment data:
      • Waiting on concrete proposal.
    5. Performance:
      • No progress on this in the repo.
      • Feedback from upstream spec: up to the discresion of the implementation for the size of the timing data buffer.
      • For Node it may make sense to provide a flag to set timing data buffer size.
      • For CFW: no plans to ship an API for the hosted solution, but may make sense for the single tennant open source binary later this year.
      • w3c/user-timing#92