Create 2025-01-15-minutes.md

meetings/2025/2025-01-15-minutes.md

@@ -0,0 +1,155 @@
+# WebAppSec WG - 2025-01-15
+
+[Wednesday, January 15th: 17:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250115T1700) (09:00 California, 12:00 Boston, 17:00 London, 18:00 Berlin)
+
+[Minutes from the last meeting](https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-12-18-minutes.md)
+
+### Logistics
+*   **`#webappsec`** on [W3C's slack instance](https://w3ccommunity.slack.com/)
+    * <https://www.w3.org/slack-w3ccommunity-invite> if you haven't already joined.
+*   **Zoom**:
+    * Details at <https://auth.w3.org/?url=https://www.w3.org/groups/wg/webappsec/calendar>
+
+### Attendees
+* Dan Veditz
+* Abdulrahman Alqabandi
+* Artur Janc
+* Yoav Weiss
+* Emily Stark
+* Tom Ritter
+* Tom Schuster
+* Lawson Jaglom-Kurtz
+* Simon Friedberger (Mozilla)
+* Simone Onofri
+* Joe DeBlasio
+* Ciara McMullin
+* Anna Weine
+* Noam Rosenthal
+* Luke Warlow
+* Mike West
+* Victor Huang
+
+### Draft Agenda
+
+*   CSP Triage updates (@ciaramcmullin, et al): It sounds like there are some specific issues which would benefit from wider discussion.
+    * (Allow script-src 'unsafe-hashes' for eval() and new Function)[https://github.com/w3c/webappsec-csp/issues/623]
+    * Choose a consistent model for workers under nonce-based policies - https://github.com/w3c/webappsec-csp/issues/375
+    * [Assigning location.href to a javascript:... is a form of eval](https://github.com/w3c/webappsec-csp/issues/688)
+*   CSP script-src [`trusted-types-eval`](https://github.com/w3c/webappsec-csp/pull/665) keyword addition.
+*   [Signature-based Integrity](https://wicg.github.io/signature-based-sri/) updates (@mikewest)
+    *   In particular, forward-compat concerns in WICG/signature-based-sri#38.  
+*   [`Timing-Allow-Origin` guidelines](https://github.com/w3c/webappsec/issues/664)?
+*   (Reverting the) X-Frame-Options deprecation note in the MDN article?
+     * Original issues where the deprecation flag was discussed: https://github.com/mdn/content/pull/35942 + https://github.com/mdn/browser-compat-data/pull/24466
+
+## Minutes
+
+### CSP Triage
+
+Ciara: We closed 4 PRs. A few were outdated and already done. 4 open issues we tagged with the agenda label that we should discuss: https://github.com/w3c/webappsec-csp/issues?q=is%3Aissue%20state%3Aopen%20label%3Aagenda%2B
+
+dveditz: PR 363, issue 6 and 474(?). Seems like something on which we need to have consistent behavior. Worried about making this processing change without data that helps us understand whether it's safe to do so.
+
+mkwst: maybe point out issues that need further discussion and add them ahead of time for future meetings
+
+dveditz: Sure. For this one, I'd appreciate implementers and developers to provide feedback about the way we handle errors in the policy. Unknown keywords, unknown directives, etc. What about non-ASCII hostnames? Throw the whole thing out?
+
+abdulrahman: Issue 623: [Allow script-src 'unsafe-hashes' for eval() and new Function](https://github.com/w3c/webappsec-csp/issues/623). Open questions: might need a new keyword or directive? Should we handle this in 574? Might be blocked by an [ECMA issue](https://github.com/tc39/ecma262/issues/938).
+
+dveditz: Also, we're working to merge Trusted Types into the spec. Offers a "safe" way to use `eval`.
+
+abdulrahman: I like that. I don't mind putting this in the TT constellation.
+
+dveditz: 
+
+abdulrahman: [Choose a consistent model for workers under nonce-based policies](https://github.com/w3c/webappsec-csp/issues/375). Forces use of `strict-dynamic`, which is non-ideal.
+
+mkwst: sounds reasonable. may be helpful to point to the topics where feedback is needed, but other folks on the call may have not looked at it yet. For the next meeting, we'll pull those out ahead of time. We'll need to deep-dive into them.
+
+ciara: Could also bring folks into the triage meeting if they're still involved in CSP.
+
+abdulrahman: Ok!
+
+mkwst: reasonable suggestion. Some topics are worth talking about in the broader group. We'll just need to prepare for it.
+
+aaj: I'll go through the issues, but let's run through them offline and be able to talk about them next time.
+
+### CSP script-src [`trusted-types-eval`](https://github.com/w3c/webappsec-csp/pull/665) keyword addition
+
+luke: As discussewd earlier, CSP handles `eval()` through `'unsafe-eval'` keyword. That's, generally speaking, bad and unsafe. While TT as an API adds additional protection to `eval()`, there's a scenario in which you have TT enabled and you need `eval()`. In TT-supporting browsers, that's safe! In other browsers, the reliance on `'unsafe-eval'` can open holes in your page. This keyword solves this problem by limiting `eval()` to those circumstances in which trusted types can be enforced. Relatively simple addition: standards positions approval from Mozilla and WebKit, Google is supportive. Question is around changing the spec.
+
+dveditz: Personal opinion: I think this belongs in the Trusted Types spec. Makes no sense without the rest of Trusted Types. Also, CSP is not really a primary security defense. Can prevent some injections, but if using a browser without protections, they're not protected. Shouldn't write code that depends on CSP being the thing that protects you. Not really objecting to this keyword, but worried about the way folks percieve CSP's role. Folks using older browsers are less safe, same as in automobiles.
+
+Luke: On the spec location: slight pushback on the assertion that it should be in Trusted Types: that means we're monkey-patching CSP.
+
+dveditz: Same as directives? I suppose we have a registry for directives but not keywords. I guess you're assuming that folks using trusted types would only add `'trusted-types-eval'`, and not `'unsafe-eval'`?
+
+Luke: Right.
+
+dveditz: I see. If you have a framework that tests whether Trusted Types are available, this means you don't need to weaken your policy via `'unsafe-eval'`.
+
+Luke: Right. Whole concept is that TT is a stepping stone, allows you to move away from these dependencies.
+
+dveditz: 
+
+mike: Process question. We have support from three vendors, implementation, and tests. Whatever the process is, it seems like this would meet it. WDYT?
+
+abdulrahman: Would these strings be nonced in some way?
+
+Luke: Not sure I follow. But we're now unblocked from the ECMA side of things. And perhaps it's reasonable to reconsider `'unsafe-hashes'`? As for other bits, the main thing is that this enables safer TT deployment. If we wanted extra things in the future, we could, it would just work with this.
+
+mkwst: useful to talk about the process question - are we comfortable merging this?
+
+dveditz: I haven't heard objections to this particular issue. Official statements from WebKit and Mozilla in support. If anything could pass the process to get into the spec, this seems good. No process yet, but we'd likely land on something like WHATWG's stages. We've said in the past that two implementers with interest is a reasonable bar.
+
+mkwst: makes sense that this meets the bar. Useful to try to solidify a stages-like process (adopt WHATWG's, tweak, etc). Need a concrete proposal. Dan - interested in putting that together?
+
+dveditz: Yes. I'll put it in an issue. Where would it go?
+
+mkwst: no current process docs beyond the charter. We can put it in the charter or start a new doc. No strong opinion.
+So landing the PR is fine. Dan will put together a process proposal
+
+### [Signature-based Integrity](https://wicg.github.io/signature-based-sri/) updates (@mikewest)
+mkwst: brief update - the spec is coming into shape. It relies on HTTP Message Signatures RFC to specify the HTTP side. So you can sign over the body, specific headers, etc.
+The document defines a narrow set of things that can be signed over, and we're at a point where the Chromium impl behind a flag is relatively complete, and folks at Google are playing with it.
+Folks at Shopify and CF are aware of the implementation.
+Interested in getting feedback from other browser vendors as well as folks that are interested in deploying this.
+Intersting discussions ensued, in particular, forward-compat concerns in WICG/signature-based-sri#38.
+What do we do with malformed headers and things we don't understand.
+We define a set of things we understand - what happens with a parameter we don't understand.
+What about header components we don't understand.
+The details don't matter other than the fact they influence our story around forward compat.
+In one model (the CSP model) we ignore the bits we don't understand. This led CSP to have a lot of complexity.
+At the same time, folks want a clear path towards using new stuff in new browsers without losing old browsers. And reducing overhead for developers is a reasonable concern.
+I'd point y'all towards the issue, and it'd be useful for folks to be involved in the discussion.
+
+dveditz: Mozilla haven't given a position but positive on the broader idea. Seems like a good direction.
+
+### (Reverting the) X-Frame-Options deprecation note in the MDN article?
+
+aaj: X-Frame-Options exists. Does the ~same thing as `frame-ancestors`. MDN suggests that XFO is deprecated and might be removed from browsers. That seems false, as sites depend on XFO today. It'd be nice if we had consensus in this group that XFO is here to say, and that we should remove that warning to not scare developers off. Hopefully uncontrovercial.
+
+Abdul: I agree. Shouldn't deprecate. Security-sensitive, we need it.
+
+Luke: Agree. Still seems reasonable to recommend `frame-ancestors`, but the deprecation warning is too much.
+
+aaj: `frame-ancestors` has the benefit of being more powerful: individual origins, etc. Drawback of making folks set this via CSP is potential developer confusion. Not an injection defense, but embedding defense. If you read the spec, no confusion, but we see confusion here.
+
+Tom Schuster: Many deprecated directives in XFO (`allowfrom`) where we also see confusion.
+
+### `timing-allow-origin`
+
+Noam: This comes up whenever people think about adding things to performance APIs. These APIs usually expose information, and there's always the question of whether TAO is sufficient protection for this new feature, or whether CORS or some other opt-in would be necessary. Likewise, changing the meaning of TAO over time is somewhat risky, insofar as people might be confused about what they're exposing via the header.
+
+dveditz: Worry that it turns into a backdoor CORS.
+
+Noam: That's a worry. There are some things that are obviously timing, others that are obviously content. Others are hard. For instance `Content-Encoding`? Is that the content? Could have the same content with gzip or nothing, same content. Should it be enabled by TAO? Would that have been expected?
+
+mkwst: agree that there are some clear timing-related things, some clear content-related and lots of other things are on a blurry line. It's be helpful for us to help WebPerf get it right.
+Falls between WebPerf and WebAppSec, but we should give you guidance that would help you when evaluating new things. The conversations is complicated by the fact that some things are neither timing nor content. e.g. `nexthop`.
+We talked about revisiting everything - interesting thought exercise, but probably impractical at this point.
+
+Noam: People who work on these APIs change. Would be useful to document what TAO means. We might have already shipped things that perhaps go beyond where we'd like them to, would be useful to guide that conversation as well.
+
+mkwst: would be reasonable for us to produce such a doc and stamp it as being our solid understanding of where the line is. People interested in the conversation should hop over that bug.
+Then we can figure out how we can abstract a doc to clear the line.