Skip to content

Commit

Permalink
Create 2024-05-15-minutes.md
Browse files Browse the repository at this point in the history
  • Loading branch information
dveditz authored May 15, 2024
1 parent 2319805 commit 5d1bc5d
Showing 1 changed file with 94 additions and 0 deletions.
94 changes: 94 additions & 0 deletions meetings/2024/2024-05-15-minutes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
WebAppSec WG - 2024-05-15
============

## Attendees

* Luke Warlow (Igalia)
* Artur Janc (Google)
* Krzysztof Kotowicz (Google)
* Philippe Le Hegaret (W3C)
* Simone Onofri (W3C)
* Tom Van Goethem (Google)
* Anne van Kesteren (Apple)
* Daniel Huigens (Proton)
* Edward Qiu (Meta)
* Anna Weine (Mozilla)
* Ian Clelland (Google)
* Dan Veditz (Mozilla)
* John Wilander (Apple)


### Agenda

* FYI: [Charter approved, CfP](https://lists.w3.org/Archives/Public/public-webappsec/2024Apr/0004.html).
* Trusted Types: @lukewarlow and friends will update us on specification and implementation progress.
* TPAC is coming, Sept. 23-27. We'd like to understand the group's plans so we can book rooms and times accordingly.


## Minutes

### Charter

* Simone: New charter! We're done for two years. https://www.w3.org/2024/04/wg-webappsec-charter.html


### TPAC

* Simone: This is the last week to book a slot for TPAC.
* Mike: T-Shirt sizing for attendees and topics.
* Dan: Overlap with various other groups: WHATWG, Web Applications
* Mike: Aim for two morning slots, and avoid conflict with WHATWG, privacy groups, etc.
* John: Might be new working groups for some of the work. Private Ads, FedID, Privacy WGs.
* Simone: Masks?
* Mike: Should be consistent with the event: if TPAC requires masks, we should as well.
* plh: Will do a survey of the group, and then we'll discuss it.
* dveditz: Depends on the event space as well. Some places ventilate well, some don't.
* plh: Will follow up on that.


### Trusted Types

* Luke: Since the start of this year, Igalia has been working on the Trusted Types spec and implementation in WebKit and Gecko. Lots of cleanup in the spec, mostly editorial, some normative changes. Integration upstreamed: most of HTML, most of Service Worker, Editing, 1 of two DOM, a few others. Implementation changes are mostly around edge cases that people probably won't come across. One was that instead of using an IDL attribute, we switched to a union type in IDL and did checks at the callsites. Lots of updates to tests. Some lacked coverage in some areas; they've been updated along with the spec to clarify the intention.

* Luke: No longer need the integration with IDL. Bits left: script element enforcement, metadata APIs (need a rewrite), event handlers (mostly editorial). TC39 changes approved to stage 3; requires some changes in Chrome but nothing too major. Now we can upstream changes to CSP and HTML (also fixes a longstanding issue with CSP about how `eval()` was defined and protected).

* Anne: Not the literal piece, right? Just `eval()`?

* Luke: The literal aspect has been deferred from v1 of the spec. Was in the spec, was slightly broken in the spec, and never shipped in Chrome, so we made the decision to defer it. There is work in TC39 to get the baseline nechanism into the JavaScript language that we'd make use of, so we hope to come back to it in the future.

* Luke: WebKit impementation is largely complete. Once the PRs under review are merged, there's just interop work left. Make sure the tests match the spec, make sure Chrome matches the spec, etc.

* Luke: Script enforcement. Might require spec changes in DOM. Script elements, when parsed, are trusted by default. Are cases in which the content of the script can be modified before parsing completes. Chrome handles this in an unspecified way. Issue doesn't seem to appear in WebKit or Gecko. Need to look into that more.

* Luke: Firefox's implementation is a little further behind. But CSP integration is proceeding, and we should be able to speed up implementation soon.

* Luke: Main bits that impact this group are CSP integration: some areas in which the JS API allows you to create a policy with a name that can't be specified by CSP headers: empty name, characters outside the CSP header range. Discussed that, but haven't looked into it as a spec group. Would be good to get eyes on it. [w3c/trusted-types#504](https://github.com/w3c/trusted-types/issues/504)

* Luke: PR to CSP that updates it against the TC39 changes. w3c/webappsec-csp#???

* Luke: New keyword for the `script-src` directive that would enable only enabling `eval()` when TT is enforced. No mechanism to protect in browsers with TT and without TT with the same policy. New keyword might help. `'trusted-eval'` or similar. Simple to spec, probably not hard to implement. Mainly just a question about what the group thinks is reasonable.

* Dan: You mentioned being able to drop the integration with IDL. What was the integration?

* Luke: The enforcement was a `StringContext=Trusted*` attribute in IDL, which built TT checks into the bindings code. This was nice from an implementation perspective, but it was very TT-specific, and was awkward to specify due to side-effects. Also made conditional enforcement difficult (e.g. `execCommand()`). So we switched to a union type and migrated the checks to the callsites. This was not too much extra work, but does keep complication out of IDL.

* Dan: If people invent new specs, they can't do it via IDL.

* Luke: Right. Just an extra line at the callsite.

* Dan: New keyword for `eval()`. Do you mean `eval()` or all the other things it means.

* Luke: All the things. `eval()`, `new Function()`, etc.

* plh: Can we update the doc automatically.

* Mike: Yes.

* plh: Simone and I can do that.

* plh: Need to get to CR. Can we begin wide review?

* Luke: Sure. Still some monkey patching, but basically good.

* plh: Simone and I will take care of that once the 2 pull requests are merged

0 comments on commit 5d1bc5d

Please sign in to comment.