- Abdulrahman Alqabandi
- Arthur Sonzogni
- Artur Janc
- Camille Lamy
- Dan Veditz
- Daniel Vogelheim
- David Dworken
- Frederik (Freddy) Braun
- Giorgio Maone
- Ian Clelland
- Jeff Hodges
- Jonathan Kingston
- Jun Kokatsu
- Mike West
- Sam Weiler
- Wendy Seltzer
- Yoav Weiss
https://github.com/w3c/webappsec/blob/2021-charter/admin/drafts/2021-charter.md
mkwst: ^ current charter proposal. No substantive changes in scope; update for clarity. Not intended to change the kind of work the group is appropriate for. ... Please take it back to folks at your orgs to see if you can support. ... A few minor questions re naming of deliverables, whether we should remove suborigins.
dveditz: suborigins, recognizing the reality that no one is currently working on it
mkwst: reflect that in the charter.
weiler: a few internal steps before it goes to AC review
mkwest: so share as heads-up, coming soon.
https://github.com/WICG/sanitizer-api
mkwst: Daniel Vogelheim and Freddy Braun.
vogelheim: Trying to build a sanitizer into the platform. Trying to make it easier to user, better hardened (because the browser knows what will cause script execution), and make sure the defaults are good. Things are moving. Spec is shaping up. Still working on some details. Chromium has an implementation behind a flag, not heavily tested yet. Firefox also has an implementation behind a flag.
...: Direction is clear. Two implementations in progress. Details to work out.
freddyb: We know what the thing will look like. Will traverse a DOM tree, remove anything that could execute script. Our implementation is reasonably far along: reusing an existing sanitizer we had in place for Thunderbird.
...: This group is a good place to ask for testers, so test! In Firefox, you can turn this on by going to about:config and set the "dom.security.sanitizer.enabled" preference to true and play with it on e.g., https://freddyb.neocities.org/sanitizer.html
...: Next steps, Web Platform Tests, TAG review, detail questions.
mkwst: great. Keep working in WICG, get to point where you're comfortable with shape and implementations. Seems a fit within our charter scope (current and new). Hope you'll bring it here when you think it's ready. Would it be useful to talk about any of the details or open debate points?
vogelheim: Default handling. Should not be able to create an unsafe sanitizer. Our current plan is to have a very safe set of defaults, with a looser baseline of settings that can't be overridden. Some questions around unknown/custom elements.
...: Also questions around the interaction with Trusted Types. It seems like these should go well together. Questions around whether it could create TrustedHTML, etc. directly.
freddyb: Agree. Specifying basic infrastructure now, looking for feedback from developers.
...: Things that might be fun for the group: given a <foo> element, lots of attributes (global attributes) actually work! Also, <template> elements are interesting. Do we want to traverse into those elements?
...: Nothing terribly contentious, though. We agree on the simple core: string -> XSS-free string or fragment.
...: Not really a new capability. Lots of userland libraries. We're simply moving the responsibility for doing it well to the browser, and removing the potential for mismatch between the library and the browser.
vogelheim: mXSS is something we need to work on a little more. string -> string leads to risks we haven't solved yet.
freddyb: mXSS: serializing HTML to a string leads to different behavior based on context. Unclosed <p> or <style> do very different things in an SVG namespace vs HTML namespace. mXSS happens when DOM is serialized and then reparsed. I think it's important that we nudge developers as much as possible towards an API that provides a DocumentFragment rather than a string. Alternative would be to have some sort of sanitizer API that takes a context, and always sanitizes for that context, and then (as the developer) bind yourself to only using the result in that context.
dveditz: Isn't that the point of Trusted Types? You say what kind of type you want?
freddyb: For HTML, it's just all HTML.
vogelheim: Trusted Types -> TrustedHTML. Enforcement mechanism, lets you decide what text gets parsed into HTML, but relies on developer to make proper distinctions.
jun: Do you plan to support SVG? MathML?
vogelheim: Yes, but unspecced.
freddyb: Focused on HTML right now, but I think we do want to support MathML and SVG.
vogelheim: I expect it'll be more or less copy/paste from HTML, it's more or less a question of configuration. There's a TODO in the spec.
freddyb: It must be namespace aware, so that's clear.
mkwst: Next steps for folks in this call?
freddyb: GitHub issues in https://github.com/WICG/sanitizer-api. File issues, join discussion. Mostly a small set of folks working on it right now. The more the merrier!
mkwst: an extension to COEP which we're currently calling "Credentiallessness" (but looking for a better name)
...: Core idea is that we see cross-origin isolation as an important primative we want websites to opt into for features that make spectre attacks easier, like sharedArrayBuffers. We're getting feedback from sites using chrom that this is difficult to deploy. COOP seems ok, but COEP requires your dependencies to ALSO opt-in, and that's not always possible to do. In the case of an iframe the 3rd party site would have to implement both COOP and COEP.
...: so far sites have been able to opt into CORP. Sites with user-generated content in sandboxed frames, for example, could be including anything and that might then be blocked or the parent page can't use COOP. A credentialless mode (no cookies, etc) should return only public information, so the thinking is that this kind of content should be safe to include in a context that might be at risk to a spectre attack. If the content is not personalised the attacker could requiest the information directly.
...: subreasources are straightforward, but frames introduce additional problems. Do we send the request but not allow the frame to access it's own storage? Arthur and Camille can talk about points of contention.
Camille: we have questions about what to do about frames, to the extent that we thought about having two modes. if you load content from a CDN it's probably all public and you don't have to care as much about what the subresources are doing. In a frame you have no idea what's there and how it's maintained, especially the transitive 3rd party resources it requests. In the inheritance you have to make every subrequest credentialless, to 3rd parties as well as the resources 1st party to the frame.
...: if you are imposing COEP on the child frames you include we aren't sure, We have another issue. Arthur wrote a document about respecting the process boundary. We've seen new APIs come up on the web that present a threat comparable to the spectre, so we require sites to be cross-origin isolated. It works for document.memory, but getting cross-origin media is another problem. Imagine a google doc with an embedded media that you want to share in Google meet. The main tab can embed whatever it wants and broadcast it whereever it wants. we considered restricting this behind cross-origin isolated and require an opt-in, but that's complicated to deploy. Consumers of this content might have no way to deploy COEP.
...: another point I should mention-- we have a proposal that non-CORS requests be credentialless, should CORS also default to credentialles in this context? We are not fully sure of the use-cases of this yet.
mkwst: we think this proposal is an important part of the deployment story for cross-origin isolation. Would appreciate people taking a look at the TAG review discussions and see the feedback from other vendors. Arthur has sent an intent to implement so we can play around with this and see if it solves the problems we see and respects the security boundaries we intend.
jun: From the summary, it seems like we need to have at least two processes on a page. We'd expose cross-origin isolation to the top-frame; other frames would be punted to a frame that wasn't cross-origin isolated. COI needs to be in a separate process, won't have anything to read.
...: Need a baseline of out-of-process iframes (OOPIF).
Camille: Our goal is precisely to avoid that. To provide a way to use powerful APIs even without OOPIF. We do that either by requiring resources to opt-into being embedded in these contexts, or to make the requests without credentials, so that we only get public versions of the resources.
jun: Iframe request also credentialless?
Camille: Yes.
jun: That would work. If you don't do that, I don't see a place where we can enforce something other than OOPIF.
Camille: Goal is not to force process separation. Either the frame will be requested without credentials, no storage, all its requests are similarly credentialless, etc; or the frame will opt-into being embedded in the context that could attack it. Just thinking about credentiallessness as obviating the need for opt-in.
jun: Not a CORS request for the frame. Need some other way to say it requires credentials.
Camille: Yes.
jun: Sounds good.
Artur: One point, might be interesting for folks at Mozilla: credentialless mode makes things easier for developers, and expands the set of sites that can adopt isolation. So far, though, Chrome and Mozilla have aligned on the set of characteristics required for cross-origin isolation. Since this proposal would expand that scope, it's important for browsers to align. Otherwise, developers may do the easy thing, but if it doesn't work in all browsers, we get back to the bad status quo. TL;DR: This proposal works in practice only if it's cross-browser.
mkwst: generally agree. Chromium perspective: Something easier than status quo seems necessary. Hope we can find mech that meets deployment needs in the wild, that we can all agree upon and ship reasonably timely.
abdul: The idea is to remove personalization from cross-origin requests. What about intranet?
Camille: In parallel, we're looking at implementing CORS-RFC1918 (https://github.com/WICG/private-network-access/). We hope that's a reasonable solution for the intranet problem, which is something we want to address regardless of whether or not credentiallessness is a thing.
...: Complicated sometimes to gain access to intranet resources via HTTPS. We think that mixed content protections will already substantially mitigate the intranet risk, as COI is only available over HTTPS.
mkwst: we've been looking at the set of things that make us comfortable giving access to APIs we know can be abused for Spectre and similar attacks. a numbers of docs on threat model and what we need to care about. Artur, Anne van Kesteren.
... I'm trying to pull together these docs in something this group could agree upon and stamp as this group saying something about security properties fo the web we think are important; give web devs good advice about how they should handle their resources. It's not enough for you as a webdev to opt in to protections, you need to take care of your resources so an attacker can't coopt. Would like this group to come together on -threat model, recommended mitigations. I've started in this doc, borrowing from Artur and Anne. It's far from done. Would appreciate feedback. Add pointers to resources, example best practices; help craft set of recs this group can make to devs. Something we could ultimately publish as a Note.
... Let me know whether this is something you'd be interested in working with as a group product. Think it would be useful for conversations with developers and implementers.
jun: Is this only related to resources?
mkwst: subresources and docs are the things on whcih I've seen webdevs needing advice
jun: data: URL iframes. <iframe srcdoc sandbox>. These are in-process. Not a mitigation for Spectre. We should mention those as well. Or just process-isolate them.
ArthurS: In Chromium, we're thinking about using a separate process for sandboxed frames. But yes, we need to think deeply about loading local schemes.
mkwst: Great, please file a bug on this doc. We should add some advice re these kinds of frames. 2, issue somewhat mitigated since the privilege to be x-origin isolated has to be granted by the embedder. Reasonable to not grant that privilege to things you don't like.
https://github.com/mikewest/post-spectre-webdev
-
Charter
-
Sanitizer API: There's an ongoing set of discussions around this API, both in its shape and in its integration with Trusted Types.
-
COEP: Credentialless: There's good discussion going on in the TAG review, and it's worth reviewing the proposal in this forum.