- Jun Kokatsu (Google)
- Camille Lamy (Google)
- Vincent Lee (Meta)
- Simone Onofri (W3C)
- Daniel Huigens (Proton)
- Dan Veditz (Mozilla)
- Artur Janc (Google)
- Anshuman Goel (Microsoft)
- Emily Stark (Google)
- Joe DeBlasio (Google)
- David Adrian (Google)
- Marcos Caceres (Apple)
- Zbigniew / Zb Tenerowicz (Consensys/MetaMask)
- Gal Weizman (Consensys/MetaMask)
- Simon Friedberger (Mozilla)
- John Wilander (Apple)
- Introducing @simoneonofri as our new W3C staff contact.
- E2E encryption proposals (@marcoscaceres)
- Document Isolation Policy (@camillelamy)
Simone: I am the new Staff Contact and W3C Security Lead. At the moment, Security at W3C is in three areas:
- Developing Security Standards (e.g., WebAppSec WG)
- Security Reviews (w3c/strategy#449)
- Educating Web Developers (https://w3c.github.io/charter-drafts/2024/swag-cg.html)
Anything needed I am available in UTC+1/UTC+2 and via e-mail simone@w3.org.
Last point is to understand if WebAppSec WG would like to meet f2f at TPAC in September in CA (https://www.w3.org/events/tpac/2024/tpac-2024-hybrid-meeting/ )
marcos: 1st proposal is "remote" cryptokeys -- giving the browser some way to access private keys but not exposing those keys to web javascript. getRemoteKey() -- would present UI to the user to choose a key, used to perform crypto operations. Can be used with existing crypto.subtle operations.
...: keys will be restricted in their usage, like email and communication-like uses.
Daniel: I wrote some questions in the issue tracker. At a high level, for the email use case you expect the browser to manage the S/MIME certificates and this is the key from those, or does the browser create an S/MIME certificate around the key.
marcos: we had explored different ways, but had thought of the browser managing that. will get back to you on your questions in the repo
Simonf: how do we syncronize this across devices? People will want to read their mail on different browsers.
marcos: that's part of the discussion and needs to be figured out
Zb: if we do sync between devices, naming the keys needs to be done so it can't be used to fool the user if another user/page/app could create a key with the same name. Separate issue: how will this interact with web extensions? They are a privilege level between the browser and the web, but will need some access to do what the user wants.
dveditz: what does "remote" mean? on a server? another app?
marcos: we got feedback that "remote" may not be the best name. ambiguous at this point
...: Cryptographic Message Syntax (CMS), old spec, but interoperable with many mail and messaging systems. would be nice to provide the primitives needed so web pages can participate in the existing "signed mail" ecosystem. Propsing a cms namespace added to web crypto with all the usual and expected APIs. Please see the examples in the explainer to see how it works
dveditz: emily, are you and Google involved here as well? any feedback?
emily: we have looked into this and are trying to separate out the use cases and what functionality would be needed to do that. We aren't enthused about putting the cms primitives on the web (BoringSSL has deleted this functionality).
simonf: my opinion cms is complicated and old and we shouldn't put this on the web
Document Isolation Policy (@camillelamy)
Camille: crossOriginIsolation is needed to get access to sharedArrayBuffer, and a number of devs are interested. But adoption of xoriginIsolation is very low because you have to apply it across the whole app. COOP and COEP are hard. Pages with COOP can't talk to cross-origin popups. We proposed COOP restrict-properties but the API is complex.
...: pages can't easily embed authenticated 3rd party content. Especially same-site but cross-origin. XXXX wanted to use it, but everyone who wants to embed them would also have to deploy crossoriginisolation.
...: we wanted COOP/COEP to work with out of process iframes [Spectre worries]. Time to reconsider the tradeoffs because it's preventing use of these feature that people really want to use.
...: per-document header, isolates document with similar documents (same-origin and crossOriginIsolationMode). We use user-agent keying. Logical isolation by actual process isolation when available, but not available on mobile.
...: why not Origin-Agent-Cluster? we want predictability in COI-gated APIs.
...: explainer will move to WICG soon after this meeting.
johnw: will this prevent browsers from lumping different docs from different sites if they want to do this for performance reasons?
camille: we are offering the ability to degrade from actual isolation to logical isolation.
johnw: will the browser inform the page whether this was downgraded? that would let pages leverage this in attacks
camille: we had thought of letting pages know whether this capability was available or not. We currently think that should be an implementation decision. Like on a mobile device you could say "we will never do it, don't have the memory", where a desktop browser could always say they would, even if sometimes they didn't and only did logical.
johnw: if a browser combines B and C in the same process that shouldn't be leaked to either B or C
camille: there are questions about process allocation and we're still working on the details. We are mostly looking at things where we can support the isolation in all of the cases.
dveditz: would we deprecate COOP or origin-agent-clusters?
camille: we aren't going to persue those spec directions, but not sure about deprecation or removal. would depend on usage.
...: feedback can go in the WICG repo once it's moved. there may be a shell under that name already