Create 2025-08-20-minutes.md

Author: mikewest

meetings/2025/2025-08-20-minutes.md

@@ -0,0 +1,166 @@
+# WebAppSec WG - 2025-08-20
+
+[Minutes from the last meeting (2025-07-16)](https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-07-16-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
+
+* Mike West (Google)
+* Artur Janc (Google)
+* Freddy (Mozilla)
+* Anna Weine (Mozilla) 
+* Simone Onofri (W3C) 
+* Dan Veditz (Mozilla)
+* Joe DeBlasio (Google)
+* Tom Schuster (Mozilla)
+* Simon Friedberger (Mozilla)
+* Simon Wijckmans (c/side)
+* Maxime Guerreiro (Cloudflare)
+* Miguel de Moura (Cloudflare)
+*   (You!)
+
+## Agenda
+
+* Discussing https://github.com/w3c/webappsec-csp/issues/736 (@swijckmans)
+* [Signature-based Integrity](https://wicg.github.io/signature-based-sri) (@mikewest)
+  * Status update. Ready for PRs against SRI?
+  * [Inline Integrity](https://mikewest.github.io/inline-integrity/) interest?
+* Administrivia
+  * Following up on CfCs for publication (@simoneonofri):
+    * [CfC to move CSP-3 to CR < 2025-07-16 #682](https://github.com/w3c/webappsec/issues/682)
+    * [CfC to move Fetch Metadata to CR < 2025-07-16 #681](https://github.com/w3c/webappsec/issues/681)
+    * [CfC to move SRI-2 to CR < 2025-07-16 #680](https://github.com/w3c/webappsec/issues/680)
+    * [CfC to move WebCrypto-2 to CR < 2025-07-16 #679](https://github.com/w3c/webappsec/issues/679)
+    * [CfC to publish Well-Known URL for Relying Party Passkey Endpoints as a FPWD < 2025-07-16 #678](https://github.com/w3c/webappsec/issues/678)
+    * [CfC to publish DBSC as a FPWD < 2025-07-12 #677](https://github.com/w3c/webappsec/issues/677)
+  * TPAC?
+
+
+## Minutes
+
+### [Making CSP more usable for organizations at scale](https://github.com/w3c/webappsec-csp/issues/736)
+
+Simon Wijckmans: Experience from CSide, examining client-side scripts for clients, seeing lots of attacks. Want to protect users, create a safer web for all. Lots of sensitive data entered into a lot of pages. Important to address.
+
+...: Spoken with customers on this topic. Who pushes for CSP adoption in companies? GRC teams, security teams, _not_ the frontend team, _never_ the marketeers in Google Tag Manager. CSP adoption is low, and that is not because people didn't true. Those that want it have to pick their fights.
+
+...: Truth about security teams: general rule of thumb, 50 employees/1 security person. They often don't touch code themselves, or don't own the code they touch. They have to beg for engineering resource, and pushback is the norm. "Wait, these things need constant maintenance? No capacity for that." Often chasing compliance and internal existential risk projects. Any security engineer that brings CSP into a company gets fried.
+
+...: CSP management is a disaster. Chatbots change dependencies, analytics tools, ad networks, marketing teams, etc. No notice for changes, problem is noticed only when it's too late, difficult to make quick changes.
+
+...: How fast can a company ship a CSP change? Normal release cycle is 2-5 days. Emergency changes "couple of hours". What if it's the payment provider's client-side script? Every second counts for revenue-producing scripts.
+
+...: If a proxy is necessary, probably the standard is broken in the first place.
+
+...: How do I know what to put in a CSP? Report-only is noisy, ugly: warning in the console is confusing "[Report Only] Refused to load" => still loads?! By the time I have reports, it's already outdated.
+
+...: How CSP is implemented? Who built a reporting endpoint from scratch recently? Spec is interpreted broadly. Hundred ways spec is implemented, some better than others.
+
+...: CSP is a headache.
+
+...: Strict-Dynamic is intended to fix some of these issues. But, customer interviews: "What? If I have a CSP that says anything from this asset is fine, why am I implementing CSP in the first place?" Closing gate, then opening it. Hard to understand.
+
+...: Nonces: concerns about static sites. A "very magento take on things", tools won't flag things from GTM, seems like a clear bypass of the intent of CSP. Should keep this, makes things flexible, but a large cost to that dynamism.
+
+...: Not built with today's internet in mind. Dyanmic, CSR, NPM, not built understanding how companies operate.
+
+...: What people want and ask for: Ability to silence report-only console logs. Fix the shouty wording of a non-blocking report-only console logs. Allow to set CSPs elsewhere, not hard coded, not in a proxy, not in a meta tag, and a janky server-side dynamic element. Need to handle the ambigity of a dynamic page elsewhere.
+
+...: Questions I've been asked: what about CSP in `<meta>`. Happy it exists, but logical separation between code and headers is a feature, not a bug. Limitation of features is a thing. Doesn't solve most of the problems raised before.
+
+...: Sure, but <meta> and a server-side component? Sure, but I can build Doom in PDF. The specification isn't good if you need to be creative to get basic functionality.
+
+...: Objections: latency of a renderer blocking 3p fetch. Sure, but folks add proxies to their flow to add CSP today. This just moves the latency. Also, latency isn't a fatal blow: SSL was slow. Security will add latency, that's fine.
+
+...: Sample size: but CSide exists because CSP is failed. CSP adoption is low, customers come to us because CSP failed.
+
+Simon Friedberger: You want CSP directive that says "look over here"?
+
+Simon W: I'd like a third-party endpoint which specifies the CSP for a page.
+
+Simon F: So we'd have to make a request to that endpoint before navigating?
+
+Simon W: Yes.
+
+Dan V: Have you asked your customers to use Firefox 10? We had `policy-uri`.
+
+Simon W: Consistency across browsers is a problem.
+
+Dan V: FF implemented that because we thought it would be too complicated for a header, but it wasn't used and we removed it. Sounds like a good idea, but doesn't actually work.
+
+Simon W: These things only work if they're cross-browser.
+
+Dan V: Sends lots of data on every response if everythign's in the header. Crazy-long policies in HTTP Archive.
+
+Artur J: Paper we discussed a few years back: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/calzavara. Dynamic policies, different components setting CSPs. I don't think it was implemented, but the use case has come up in the past. Question, though: if we come back to an endpoint that sets CSP, I'm not sure how that solves the problems you're raising. If you have one endpoint that sets CSP, there's still no easy way for it to be aware of the components of the application. If that's the problem, it doesn't really matter where the policy is defined.
+
+Simon W: Important to separate goals: dynamic assets is one problem, I wouldn't trust a third-party to set a CSP. Last week we found a third-party dependency that didn't renew its domain, renewed and went malicious. If we're going to trust the third-party to set the CSP, that doesn't solve the issue. There will be exploits. The other issue: endpoint just addresses the release process and slowdown between alert and reaction. Example in our own company: Intercom changed something and went down. Wouldn't have needed to push code with an external endpoint.
+
+Dan V: Third-party scripts, or some other department in a big company. Dependencies you don't control, but you want to control it with CSP. Either you have a strict list, and they exceed it because they don't coordinate. Or you have `strict-dynamic` and say you trust them to run code on your side and use CSP to monitor. Seems like a fundamental conflict. Dependencies suck.
+
+Simon W: You can't trust untrustworthy dependency to set security for you.
+
+Dan V: Dependencies are the problem.
+
+Simom W: World is big. Lots of client-side scripts out there. GTM runs ~25 scripts.
+
+Maxime G: The issue isn't untrusted dependencies, the issue is that you want to allow only trusted dependencies. If there was a way to say "I want to allow Intercom and their dependencies." that might represent what we actually want to allow.
+
+Simon W: That's strict-dynamic. It's not really a solution.
+
+Simon F: You discarded proxies, but reverse proxies are common. Good way to separate CSP header from other infra if you want that. Also, CSP is essentially a way for people who have lost control of their code to impose some restrictions on what they can do. Not a way of sandboxing dependencies.
+
+Simon W: In practice, it's not fulfling its promises. PCIv4. Client side credit card theft. Now a requirement to have protections locally: CSP is mentioned, but it is not solving the requirements. Should CSP evolve? Yes. It's the only real client-side security that exists. But we need to address common client-side requests.
+
+Artur J: This is an interesting thought. Seems like we're talking about a different thing than CSP aimed to solve. XSS protection against loading malicious scripts that could inject scripts into a page that didn't intend to load them. Main defensible use case is XSS. You're mostly talking about dependencies. If you load a script you don't trust, CSP doesn't do the things you'd like it to do because it wasn't designed for that. If you load something that might be malicious, intentionally, we might need a different approach rather than saying that CSP looks like the thing that should protect us from this attack.
+
+Dan V: Main problem CSP wanted to solve was XSS. There was another thread of folks who wanted to control the things a site could load. Two fundamentally different things. CSP is best for the former.
+
+
+
+
+### Integrity
+
+#### [Signature-based Integrity](https://wicg.github.io/signature-based-sri) Status
+
+* https://github.com/w3ctag/design-reviews/issues/1041
+* https://github.com/mozilla/standards-positions/issues/1139
+* https://github.com/WebKit/standards-positions/issues/434
+* https://groups.google.com/a/chromium.org/g/blink-dev/c/R6isgRnE1j4/m/MZRDE_dEAgAJ
+
+mkwst: we talked about CSP control of scripts. another way is via integrity checks in sub-resource integrity (SRI) spec. You are able to remove trust in the server -- it has to be the content you expect. Great -- but it's brittle. It also doesn't work with intentionally dynamic scripts. We've talked about a signature-based integrity approach: you're not trusting the exact content, but the provenance of the resource. (there's an HTTP-header based signature RFC).
+
+...: Chrome has implemented this and a small origin trial seems successful. Please take a look at the proposed spec so we can make forward progress. One commen comment is that the approach is useful, but needs a better way to handle key rotation. I'll be evaluating what approaches might work best. 
+
+...: please review the spec, and the _comments_ on the proposal.
+
+
+#### [Inline Integrity](https://mikewest.github.io/inline-integrity/)
+
+* https://github.com/w3ctag/design-reviews/issues/1135
+* https://github.com/mozilla/standards-positions/issues/1283
+* https://github.com/WebKit/standards-positions/issues/540
+
+mkwst: Currently SRI only works with remotely loaded resources, but many modern sites are built by front-end proxies that inject snippets or combine multiple resources for efficiency. Currently no good way to use integrity here, but an inline version could work. There's an implementation in Chrome behind a flag. Please try it and see if it's a plausible proposal or needs tweaks. 
+
+simone: <missed, sorry>
+
+mkwst: someone asked in chat can't whatever is doing the merging just supply the hash? Inline script injections currently don't support hashes (the hash would also have to be injected into the CSP), and the script is dynamic, so putting the hash into the pages CSP would be difficult. Signatures support assertions about provenance, which might be helpful.
+
+### Administrivia
+
+### CfCs for CSP3, Fetch Metadata, SRI2, WebCrypto2, Passkey Endpoints, DBSC
+
+Simone O: FPWDs will be published tomorrow. Yay. Specs that want to move to CR: after this call, I'll open a large issue with subissues to manage wide review. We need a changelog, other details. Need to give groups ~1 month to review, would be ideal to send them as soon as we can, need to demonstrate independent implementations. Need to show that just reading the spec is enough. Then some other parts to take care of, but this will require some work.
+
+mkwst: Would be ideal to talk about next next steps: snapshot CR process, snapshot RECs, etc. Can you help us get feedback on folks' experience in the W3C?
+ 
+Simone: Yes, I can help with that. Can make it a topic for TPAC.
+
+(Punting TPAC to next time)