-
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
178 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,178 @@ | ||
| WebAppSec WG - 2024-03-20 | ||
| ============ | ||
|
|
||
| [Minutes from previous meeting](https://github.com/w3c/webappsec/blob/main/meetings/2024/2024-01-17-minutes.md) | ||
|
|
||
| ## Attendees | ||
|
|
||
| * Mike West (Google) | ||
| * Jun Kokatsu (Google) | ||
| * Camille Lamy (Google) | ||
| * Kai Yuan Thng (Meta) | ||
| * Luke Warlow (Igalia) | ||
| * Philippe Le hegaret (W3C) | ||
| * Ian Clelland (Google) | ||
| * Simone Onofri (W3C) | ||
| * Daniel Huigens (Proton) | ||
| * Javier Fernandez (Igalia) | ||
| * Anne van Kesteren (Apple) | ||
| * David Dworken (Google) | ||
| * Abdulrahman Alqabandi (Microsoft) | ||
| * Aaron Shim (Google) | ||
| * Dan Veditz (Mozilla) | ||
| * Edward Qiu (Meta) | ||
| * Theresa O'Connor (Apple) | ||
| * Artur Janc (Google) | ||
| * Dan Veditz (Mozilla) | ||
| * Tom Van Goethem (Google) | ||
| * Anshuman Goel (Microsoft) | ||
| * _You?_ | ||
|
|
||
|
|
||
| ## Agenda | ||
|
|
||
| * Web Crypto (@twiss, @javifernandez) | ||
| * Adding Ed25519 and X25519 to Web Crypto: [w3c/webcrypto#362](https://github.com/w3c/webcrypto/pull/362). | ||
| * [Modern Algorithms in the Web Cryptography API](https://twiss.github.io/webcrypto-modern-algos/) | ||
| * Feature detection (e.g. [`crypto.subtle.supports`](https://twiss.github.io/webcrypto-modern-algos/#partial-subtlecrypto-interface)). | ||
| * Mitigations Wiki: [w3c/webappsec#639](https://github.com/w3c/webappsec/pull/639) (@aaronshim) | ||
| * Reports for frames in Permissions Policy: | ||
| https://github.com/w3c/webappsec-permissions-policy/issues/537 | ||
| (@shhnjk) | ||
| * Trusted Types (@lukewarlow) | ||
| * Upstreaming pieces to CSP: [w3c/webappsec-csp#651](https://github.com/w3c/webappsec-csp/issues/651) | ||
| * `'trusted-script'` in `script-src`: [w3c/trusted-types#221]() | ||
| * [Document Isolation Policy](https://github.com/explainers-by-googlers/document-isolation-policy/) (@camillelamy) | ||
| * Administrivia (@plehegar) | ||
| * Charter https://github.com/w3c/webappsec/issues/645 https://github.com/w3c/webappsec/issues/646 | ||
| * TPAC meeting request? | ||
| * Introducing @simoneonofri. | ||
|
|
||
| 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-03-20-agenda.md) | ||
|
|
||
| ## Minutes | ||
|
|
||
| ### Web Crypto | ||
|
|
||
| Daniel Huigens: Opened a [PR](https://github.com/w3c/webcrypto/pull/362) to add x25519, Ed25519 to web crypto. That's half the secure curves draft, seems like the half with the most support. Questions around randomness of signatures. WebKit has shipped a randomized version, pedantically not what's specified. I think we should discuss that in the CFRG and not here, but one proposal could be that we specify "signatures made as per RFC 8023 or a later replacement". Other than that no real issues. | ||
|
|
||
| Javier Fernandez: Also don't see blockers to merging this. Some interop concerns. | ||
|
|
||
| Mike: Can you talk more about interop? | ||
|
|
||
| Daniel: Issue with rejecting small order points. Mozilla requested, didn't get pushback on the spec, but my understanding is that Chromium prefers to ship their implementation of x25519 as it is. Technically also not conformant to the RFC. But wider issue applying also to TLS. Discussion needs to happen in CFRG about the behavior. W3C might not be the right place to have those conversations. | ||
|
|
||
| Mike: Help me understand the interop implications? | ||
|
|
||
| Daniel: Can effect whether a signature is considered valid or not. But shouldn't affect "legitimate" users generating legit signatures. Would have implications on specially-crafted input. More difficult to test if different browsers behave differently, could be browser fingerprinting vector. | ||
|
|
||
| Anne: TLS is different, given propensity of arbitrary input via JS. But WebKit's already shipped, so cat's somewhat out of the bag, which is unfortunate. | ||
|
|
||
| Daniel: Could recommend using [`crypto.subtle.supports`](https://twiss.github.io/webcrypto-modern-algos/#partial-subtlecrypto-interface) to see if it's supported, which could help developers understand the implications and level of support in browsers. | ||
|
|
||
| Anne: This is being raised at the IETF level by cryptokit folks. | ||
|
|
||
| Mike: Let's take this to the PR. I don't have a problem with landing the PRrt its implications for Web Crypto, but we can evaluate it there. Might still be interop concerns that block shipping, but that's a separable question. | ||
|
|
||
| Javier: There's another issue. Key sharing algorithm: affects multiple derived algorithms. I also don't think this should block the PR, but would be great to make an effort to get to agreement there as well. Length parameter. https://github.com/w3c/webcrypto/issues/329 | ||
|
|
||
| Daniel: My understanding is that Chromium added telemetry to see if we can make the change. Was a bug in one of those, trying to fix. Derived bits method has a parameter in which you can request any number of bits, including 0. Different implementations: one throws, one returns an empty array, another returns the whole value. Need to align. | ||
|
|
||
| Dan: Are there issues raised for these incompatibilities? Would be simplest to do so in distinct issues. | ||
|
|
||
| Daniel: Many issues raised against Web Crypto. | ||
|
|
||
|
|
||
| ### Mitigations Wiki | ||
|
|
||
| Aaron Shim: We've worked on features that result in more secure web applications. These are comprehensive, but there's a knowledge gap between those specs and web developers. We talked a few years back about pulling usage recommendations into a wiki. Would be ideal to provide pointers for developer adoption. | ||
|
|
||
| https://github.com/w3c/webappsec/pull/639 | ||
|
|
||
| Aaron: What's the right format to host this knowledge? We're suggesting using the GitHub wiki for the moment. Could consider a static site later, WDYT? | ||
|
|
||
| Luke: What about MDN? | ||
|
|
||
| Aaron: MDN defines these features, but doesn't have guided examples. This is something of an extension of what MDN provides. | ||
|
|
||
| Simone: Thinking about a place in which web developers can learn how to make their applications secure. | ||
|
|
||
| Aaron: Looking forward to learning more. For the PR we currently have, what should we do? | ||
|
|
||
| Mike: Wiki as a holding ground sounds fine to me, but I'm also interested in figuring out whether MDN or a W3C hosted location would be more appropriate in the long term. | ||
|
|
||
| Aaron: Ok, then let's err on the side of not losing the words in the PR, land them, and continue to discuss the final home. | ||
|
|
||
| ### Reports for frames in Permissions Policy | ||
|
|
||
| https://github.com/w3c/webappsec-permissions-policy/issues/537 | ||
|
|
||
| Jun Kokatsu: If an iframe tries to use a permission via delegation, reports can be helpful in determining the extent to which a given capability is available. Currently reports aren't sent, as they're an information leak to know what cross-origin frames are doing. We're still interested in understanding whether frames have an `allow` attribute that delegates a particular permission. In order to do that, we're proposing reporting that would send reports whether or not the permission is used in an iframe. From Google's perspective, it's hard to know what we're going to break without good reporting. Any objections to this? | ||
|
|
||
| Ian Clelland: We do send reports, but to the cross-origin iframe, not to the top-level document. Agree that that's not as useful for Google's problem. The proposal here would inform the page that it looks like permission delegation is desired, but wouldn't work. That's a somewhat different kind of report. | ||
|
|
||
| Mike: What about A->B->C nesting scenarios? | ||
|
|
||
| Jun: We don't need to learn about C. Delegating to B, B has the power to delegate to C. B's responsibility to set the policy for itself. | ||
|
|
||
| Ian: With this proposal, you get the information that it was delegated to B. Nothing else. | ||
|
|
||
| Anne: Hard to discuss without diagrams. | ||
|
|
||
| Dan: Let's say B can't use camera. B doesn't try to, but it says C can use camera. C can't, of course, but would we report that? | ||
|
|
||
| Jun: Currently, C gets its reports, B gets its reports, A gets nothing. This proposal would send reports about C to B, but not to A. "You're trying to add an allow attribute to B, but doesn't match your permissions policy. It might break." | ||
|
|
||
| Dan: Specific permission they tried to use seems like too much. | ||
|
|
||
| Artur: As A, you never get additional information beyond what you have (e.g. you can see iframe attributes). We're just informing you that you're trying to delegate a permission that violates the report-only policy. | ||
|
|
||
| Anne: Sounds mostly ok. But there's certainly confusion about what's being proposed. Happy to trust that there's no additional data leakage. Interested in understanding utility. | ||
|
|
||
| Jun: Hard to inject reporting JavaScript to every page. | ||
|
|
||
| ### Trusted Types | ||
|
|
||
| Luke Warlow: How much of TT should we upstream to CSP. Wouldn't be the whole spec, but there's a new directive and changes to `eval()` processing. | ||
|
|
||
| Mike: The `eval()` bits seem clearly upstreamable. CSP can live in a separate document easily. That said, what's the plan for HTML? | ||
|
|
||
| Anne: Given that CSP directives have interdependencies, does it make sense for them to be distributed? | ||
|
|
||
| Dan: Separable directives like `upgrade-insecure-requests` can live separately. Keywords are different. | ||
|
|
||
| Luke: `trusted-eval` Keyword for `script-src`. Similar to `unsafe-eval`, but would require TT enforcement. Would enable disabling `eval()` for browsers that don't support TT, while enabling it only for browsers that do. Helps developers deal with requirements to remove `eval()` usage in certain contexts (regulatory requrements, etc). | ||
|
|
||
| Mike: Doesn't seem harmful to me to add if it's satisfying a developer requirement. | ||
|
|
||
| Luke: Implementation and spec seem straightforward. Is valuable for developers. | ||
|
|
||
| ### Document Isolation Policy | ||
|
|
||
| Camille: Published an explainer for document isolation policy. Enables cross-origin isolation in a way developers should be able to deploy more easily in embedded cases, and for sites that have embedded content. Looking for feedback on https://github.com/explainers-by-googlers/document-isolation-policy/. Please read it! | ||
|
|
||
| ### Charter | ||
|
|
||
| plh: 2 comments. 1: move OTR field to the PrivacyWG. Seems fine. 2: At TPAC, Marcos talked about E2E email. Doesn't seem to have published anything. Propose dropping this from the charter. https://github.com/w3c/webappsec/issues/646 | ||
|
|
||
| Tess: We have a proposal! General objection to adding things that haven't been incubated isn't one to have in the WebAppSec context, more generalized. But in this case, there's an explainer out: https://github.com/WebKit/explainers/tree/main/remote-cryptokeys. Other piece (functions needed to support S/MIME) will have an explainer out shortly. There's a good argument for not including it: this bit is monkey-patching web crypto, we already have that in our charter, so we don't need it. But: shouldn't require every webmail entity to include a megabyte of JavaScript, and there might be additional requirements. Was general enthusiasm from this WG after conversations at TPAC. Fundamental piece of web security we should take care of in this group. | ||
|
|
||
| Dan: Mozilla's objection was mostly that it looked like nothing happened after TPAC. | ||
|
|
||
| Tess: It has been baking, just not visibly. | ||
|
|
||
| plh: Is a link to the explainer enough? | ||
|
|
||
| Dan: I'll ask our AC rep. | ||
|
|
||
| ## Queue | ||
|
|
||
| * _You?_ | ||
|
|
||
| ## Logistics | ||
|
|
||
| * **Minutes**: https://cryptpad.w3ctag.org/code/#/2/code/edit/Pq1xOhFZ9oxeI5vrXwx--B3a/ | ||
| * [Add these events](https://www.w3.org/groups/wg/webappsec/calendar#export) to your calendar | ||
| * **Zoom**: | ||
| * Details at <https://auth.w3.org/?url=https://www.w3.org/groups/wg/webappsec/calendar> | ||
|
|