-
Notifications
You must be signed in to change notification settings - Fork 148
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
119 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,119 @@ | ||
| WebAppSec WG | ||
| ============ | ||
|
|
||
| ## Attendees | ||
| --------- | ||
|
|
||
| * _You?_ | ||
| * Dan Veditz (Mozilla) | ||
| * Abdulrahman Alqabandi (Microsoft) | ||
| * Artur Janc (Google) | ||
| * Krzysztof Kotowicz (Google) | ||
| * Kyra Seevers (Google) | ||
| * Philippe Le Hegaret (W3C) | ||
| * Lukas Weichselbaum (Google) | ||
| * Luke Warlow (Igalia) | ||
| * Ian Clelland (Google) | ||
| * Frederik Braun (Mozilla) | ||
| * Simon Friedberger (Mozilla) | ||
| * Leonardo Balter (Salesforce) | ||
| * Daniel Huigens (Proton) | ||
| * Edward Qiu (Meta) | ||
| * John Wilander (Apple) | ||
| * Camille Lamy (Google) | ||
| * Caridy Patiño (Salesforce) | ||
|
|
||
| ## Agenda | ||
| ------ | ||
|
|
||
| * [Trusted Types](https://w3c.github.io/trusted-types/dist/spec/): @mozfreddyb will briefly discuss Mozilla's revised position on the feature, and point to some outstanding work that we should ensure happens. | ||
|
|
||
| * [`:visited` partitioning](https://github.com/kyraseevers/Partitioning-visited-links-history): @kyraseevers will discuss the current state of this proposal in Chromium, as well as any feedback the group can provide. | ||
|
|
||
| * CSP Maintenance: @bakkor pointed to some specific bugs against CSP, which highlights the broader problem that we're not doing a great job maintaining this feature. We should discuss our options. | ||
|
|
||
| * Charter | ||
|
|
||
| If you would like to add an item to the agenda, please open a PR against [this document](https://github.com/w3c/webappsec/new/main/meetings/2024/2024-01-17-agenda.md) | ||
|
|
||
| ## Minutes | ||
|
|
||
| #### Trusted Types | ||
|
|
||
| * Freddy: Mozilla's standards position has been in an undecided state for a while. Received a lot of feedback. Long story short, we're interested in Trusted Types. | ||
| * Saw some issues here and there, found some things Chrome's implemented behind a flag that aren't in the spec. Some things in the spec that aren't implemented. Requires cleanup, nothing shocking. | ||
| * Igalia is going to work on a Firefox implementation, and help keep the spec up to date. | ||
| * We'd like this to be upstreamed to HTML/DOM, fully specified. | ||
| * WebKit? | ||
| * Luke: Yes. I'm working on it in WebKit. | ||
| * Leo: Salesforce is sponsoring that work in WebKit. I still think WebKit's position isn't entirely positive, but I think they've accepted the feature under a flag. | ||
| * Luke: Yes. They're accepting patches. Already started. | ||
| * John: We've noted Igalia's work. Going back to our earlier feedback on the proposal. Generally there's nothing now telling us or you we want to stop the work. Fine to add this behind a flag. Will come back with fresh feedabck. | ||
| * koto: Glad to see this reinvigorated! Monitoring new tickets and PRs against the spec, lots of good and necessary cleanup work. Looking forward to another implementation. | ||
| * Leo: Salesforce's interest: new regulation in NL (and Europe?) DigiD: authentication must stop working if any page header uses CSP with `unsafe-eval`. Tried many workarounds, Trusted Types is our best working solution. | ||
| * Other workarounds are very costly, won't meet the deadline (May 2024). Even with development work ahead of us, this seems like the right path. | ||
| * Not pushing for an extension to TT. Can come as a separate discussion later. The things we need are currently in the spec, looks like a good path. | ||
| * Luke: I'm implementing in WebKit. Largely implementable. Not come across too much that's really hard. Some questions around `fromLiteral`, not sure if that should be in V1 or can be deferred. | ||
| * Most concerning thing is reliance on Stage 1 ECMAScript proposals. Hopefully can avoid those. [LINK?]. | ||
| * Otherwise, just cleanup and minor fixes. | ||
| * koto: | ||
| * `fromLiteral`: Will be a decision based in how difficult implementation is. If we can implement it, let's include it. If there are major blockers, we can wait (especially since it's not shipping in Chrome yet). | ||
| * dynamic code brand checks: Enforcement of `eval()` in TT relies on an ECMAScript feature that's currently in Stage 1. Even the implementation in V8 is a little hacky. `new Function()` isn't yet supported. Ideally we should finish this in TC39. Problem is mostly who owns that work. Don't know if I have the capacity to drive it these days, so need to find an owner. Chrome just implements the `eval()` hook, we don't want to regress on that. Perhaps we can do that from the web platform specs, not TC39. Still, don't recall major blockers. Just aligning on understanding of the feature. | ||
|
|
||
|
|
||
| #### :visited partitioning | ||
|
|
||
| * Kyra: Thanks for your feedback at TPAC! Brief recap: [explainer](https://github.com/kyraseevers/Partitioning-visited-links-history) describes partitioning `:visited` history by top-level site. Implementation in Chrome is chugging along. Incorporated some of the feedback from TPAC. Self-links, exploits described at TPAC in which (not) clearing browing data might reveal additional state. | ||
| * In Chrome, we're implementing in phases. Collected triple-keyed data in first milestone. Currently code relies on shared memory, need to look into defending against compromised renderers. Mostly internal details, but might be shared between browser impementation. | ||
| * In next phase, we'll address some of TAG's feedback, and collect some metrics about the user experience around this feature (how many `:visited` links are rendered as visited, etc). | ||
| * Interested in feedback! | ||
| * Dan: Is dbaron aware? | ||
| * Kyra: Yes. Very interested. | ||
|
|
||
|
|
||
| #### CSP Maintenance | ||
|
|
||
| mkwst: CSP -- been around for a while, old and creaky. Fairly stable implementations of a lot of it, especially the script execution part. There are lots of little features that haven't gotten as much attention, not always implemented or implemented consistently. Sometimes the spec is unclear and we have issues filed by people trying to use the feature. Many of these things are fairly minor and annoying. Not major, but still bad that it's been neglected. | ||
|
|
||
| ...: we, collectively, have not been doing appropriate maintenance on the spec in the past few years. We need to rekindle that discussion and find a way to maintain the spec since I haven't been able to devote time to it. What can we do about it? Can we decide it's not a problem? will someone step up? What should we do now? | ||
|
|
||
| dveditz: I'd love to wrap this up, clean it up. I have no interest (and likely no one at Mozilla does) in expanding the feature set. If the goal is to finish up what we've got, fix the discovered issues, prune out the stuff that's not working or not implemented, I'd be interested in working on that. Need to figure out if I have time. | ||
|
|
||
| mkwst: Pointing to Artur's hashing proposals. | ||
|
|
||
| dveditz: Sure, as a separate thing. | ||
|
|
||
| koto: Patch to CSP: Trusted Types integration. Thankfully that's written up, just needs to move from one to the other. | ||
|
|
||
| dveditz: In the spec currently, there's a registry. We set that up with IANA. Can take that path for TT. Might be worth referencing, but not integrating it into CSP. | ||
|
|
||
| koto: Sure. Only concern is that monkeypatching is bad. Just pointing this out as a potential addition to think through. | ||
|
|
||
| dveditz: Is TT in our working group? | ||
|
|
||
| freddy: Yes (currently at FPWD). | ||
|
|
||
| aaj: I wonder if it would make sense to think through the classes of improvements we could make to CSP/implementations that we're excited about. Three different kinds of work: 1) changes, new capabilities, etc. As Dan noted, no large changes are on the table, but things like the hashing proposal would be practically useful. 2) Bugs in CSP. If there are semantic problems with it, missing details around workers where things don't work quite right. Should align between browsers on behavior. Again, not fundamental changes but tactical improvements in places where we see developers struggling. 3) Lots of other bugs in CSP that don't have practical significance. Maybe we can continue successfully ignoring them, and prioritize things people actually care about. | ||
|
|
||
| Luke: Relevant to Salesforce: TT has a requirement for `unsafe-eval` as an expression in CSP. That's the case even if you want `eval(TrustedScript)`. I could see value in some sort of `trusted-eval` variant. No `eval()` without TT. I think this was originally planned, fell off. Could be a good addition. | ||
|
|
||
| dveditz: To aaj: 1) These aren't things I think we should never do, but I think we need to finish the things we currently have, and then come back to these. 2) This is the primary set of things I think we should do. 3) Yes. Too many bugs, we do need to prioritize. Doesn't need to be perfect, just good. | ||
|
|
||
| aaj: CSP is not good. Maybe "ok". Generally agree otherwise. | ||
|
|
||
| #### Charter | ||
|
|
||
| Comments from PING: https://github.com/w3c/webappsec/pull/640 | ||
| Drop timeline expectation for Credential Management (MikeW), Permissions (MarcosC, MikeT), Permission Policy (IanC)? (all Working Drafts) | ||
|
|
||
| plh: We're late, my fault. Current charter runs out in Jan. Need to start review of new charter ASAP. PING wants to be in the loop for some of the deliverables, created a PR to do that. Security/Privacy for cookies, guidelines for developers, and e2e for email. | ||
|
|
||
| ...: Also, our timelines are absurd. Maybe we should remove the dates. | ||
|
|
||
| dveditz: These are somewhat unedited. | ||
|
|
||
| mkwst: If we can get away without a timeline, we should. | ||
|
|
||
| aaj: Looking at the charter PR: there's a note that work should be coordinated with the privacy group. Great, we've talked about this in PrivacyCG. Discussion is great. But what does "should be coordinated" mean? The work on the cookie security model has happened primarily in this group, what more should we do? | ||
|
|
||
| plh: We should make them aware. Not a joint deliverable. Work will happen here. |