Meeting minutes
Joe, Chrome Security
Camile, Chrmoe Security
Daniel, Proton
<dmitriz> Sam Goto, Chrome Platform APIs
Erica, Legendary Requirements
Matt Finkel, Security/Privacy, Apple
Nick Doty, Center for Democracy and Technology
Dimitry, Co-chair of Social Web CG
Evan Pomodrou, Co-author of ActivityPub, E2E task force
(from zoom)
Robbie, Google Chrome team, Web Platform, PWAs and IWA
Bob Wyller, used to be at Google, no more
Christiano Longo, University of ___, researcher on the field of Semantic Web and description logics
Evan: problem space, solutions, selection down to a few we are considering, next steps for E2EE within activity pub
Evan: activity pub = distributed social network API and protocol, roots in RSS, idea of a feed
Evan: but than it transforms significantly from there, JSON-LD, much more structure within the feed, things like profile, events like "liking", "sharing", "replying"
Evan: push distribution structure
Evan: privacy mechanism, so that i can choose who can receive what i send ...
Evan: also extensible, add new vocabularies
Evan: REST API, creating. new content,
Evan: clients interact with their servers, sending data
Evan: server based protocols between domains
Evan: each person has a dedicated serve that they use, similar to email
Evan: the server takes care to routing it to other people on the social web
Evan: ~30K servers, 20M registered users, ~2M MAUs
Evan: best known implementations, flipboard, wrodpress, threads, mastodon, ghosto.org
Evan: expectations was that there was a lot of trust between the user and the server, sort of like email
Evan: how it is shaking out today is that it is low affinity, open registration server, hobbiers
Evan: they tend to have higher risk user base that don't feel comfortable in other places, LGTB+, political, information security, etc
Evan: low affinitiy user-server
Evan: when people make posts, they can choose just a single receipient, e.g. just for Dimitry
Evan: encrypted in flight with HTTPS
Evan: however, the posts are stored, in the clear, in the server
Evan: both on the sender and the receiptient
Evan: consequently, because things are stored in the clear, "my posts are stored in the server they could look at it"
Evan: for this reason, in the mastodon UI, they have a disclaimer "please don't share sensitive information over mastodon".
Evan: sending E2EE in social networks is pretty important
Evan: a situation where we have low trust in the directed messages inhibits this growth
Evan: one solution to this is to integrate E2EE into Activity Pub
Evan: encrypt it at the client side, and decypt it a the receiptient
Evan: a proposed proposal out of the CG
Emily: do you need to support groups? and if so, groups of arbitrary sizes?
Evan: good question. Let me walk you through the user stories.
Evan: our primary user story is "can we get 1:1" encryption, we want group messages, do we want social groups (e.g. < 100 people) or telegram scale (e.g. < 1K or 1M groups).
Dimitry: we are starting from non-encrypted, so 1:1 is more incremental/easier and a starting point
Evan: links are low effort
Evan: initiation and handoff
Evan: Full external protocol support
Evan: there are existing encrypted direct messaging systems, such as matrix or XMPP, if you are implementing activity pub, implement XMPP. High requirements for developers and administrators.
Evan: another way that we could do things is to use an abstract protocol, and use activity pub as a substrate.
Evan: the Mastodon API is very cloned, unfortunately not very extensible, with each of the messages is hard.
Evan: the other option is the extensible points in Activity Pub, using an abstract protocol built on top of the Acvity Pub protocols
Evan: in terms of the integration model, the first 5 aren't great, we are looking into the last one
Evan: candidate abstract protocols
Evan: how do we do end to end encryption?
<npdoty> is that the not-widely-implemented Client-to-Server API part of ActivityPub?
Evan: looked at a number of protocols.
Evan: PGP/MIME
Evan: a series of RFCs, hard to scale past > 100 recipients
Evan: lots of libraries, simple
<npdoty> recently updated set of RFCs, for what it's worth. might be surprising how actively implemented and developed it is.
Evan: S/MIME
Evan: well standardized
Evan: OTR, something mid 2000s
Evan: designed for IM
Evan: implemented in XMPP, nice properties that makes it more robuts, probelsmw ith the network, slightly more complex, not very widely implemented
Evan: Signal Protocol, 800 pound gorilla in IM encryption, developed in the 2010s,licensed for use in a number of different messaging systems, whatsapp, facebook messenger, google's RCS, lots of nice features
Evan: widely used, trusted,
Evan: That's what DMA is nudging
Evan: chatty
Evan: ActivityPub works more like email than IM, kinda of complex
Evan: trademark system, licenses it, very defensive about it, saying "this is a signal system" they want to make sure that it is implemented properly
Evan: Messaging Layer Security (MLS)
Evan: similar structure to Signal, IETF RFC 9420, designed to meet exactly the scenario we are doing
Evan: it scales nicely, uses a tree structure, royalty free
Evan: kinda of complex, key updates, group membership updates
Evan: it is in CISCO WebEX
Evan: PGP/MIME "too old", S/MIME "too old", OTR "too obscure", Signal "company control", MLS
<bobwyman> "Too old...." Ageism... We invested a great deal of resources in S/MIME back in the mid-90's... That wasn't *that* long ago...
Evan: recommendation result, activity pub extension, MLS
<npdoty> OpenPGP RFC was last updated July 2024
Evan: ways for discoverying keys, mls:Keys
Evan: given an Actor, can you give me their keys?
Evan: mls:Groups
Evan: you group things by conversation
Evan: mls:n namespace
Evan: mapping them into JSON-LD and making it into an extension
Evan: what happens next? working on a draft proposal
Evan: partner with Tom Coatest in a foundation
sysrqb: seems like a good choice
<npdoty> matt suggests that mls in particular seems like a good choice
sysrqb: threat model that you are envisioning, in most cases, it seems all of these messages are going to be under the control of who is running the server
evan: can we verify that it is end to end enough?
evan: the key storage is going to happen on the client side, e.g. a web client or a native client
evan: so, the server would not be able to decrypt it
evan: probably the biggest threat, if i have a mobile client, a web based client, and a desktop client, i'd have to have 3 public keys for people to send to, and they'd have to send to
evan: i'm going to get an array of keys, 3-7, and the way that the server can steal is by throwing the 8th key and read it
evan: the best solution that we've seen is for people to do manual out of band key checks
evan: not great solution
dimitry: mobile browser vs native apps, waiting for WebAuthn to support key agreement keys, to be added to the credential API, or for federation
dimitry: i can use external keys
estark: have you looked at the WebAuthn PRF extension
<Zakim> rigo, you wanted to ask whether they have considered just blunt RDF encryption
<estark> WebAuthn PRF extension
rigo: activity pub is JSON-LD, we should agree on a threat model, i don't think it is supposed to do what Signal does
rigo: it is just going after perversive monitoring
rigo: why do we do complicated when we can do simple?
<npdoty> what about message franking / moderation?
rigo: actiivty pub is linked data, why haven't you looked at LD, you have Verifiable Credentials, to encrypt your activity pub, fully as RDF, and keep it in your system
rigo: a standard that can be implemented at a large scale, may merit a blank sheet approach
Evan: first, on simplicity, we have about 100 implementation, each supporting unencrypted messaging, if we choose a complex standard, problably few implemenations can get to it
Evan: it may reduce our ability to keep users safe
Evan: changing user's perception of the system
Evan: having a broadly supported simple mechanism, better than narrow mechanism
rigo: all clients/serve talk TLS, the only additional value, is that the directed messages is not visible in the server, it arrives already here, and you just need a gateway ...
rigo: if you are really doing very secretive things, maybe you should use Signal instead
rigo: that's why i think it is worth talking about the threat model first
<bobwyman> What is "a little bit secret?" Ain't no such thing.
rigo: lots of myth about the danger for the private messaging
estark: there is a lot of incfeasing energy on adopting the wbe platform to support the E2EE threat model
estark: that would be awesome, Web App Sec
estark: at some point you painted OTR, they are legitimate security problems, not nearly the same security guarantees as Signal
<Zakim> npdoty, you wanted to comment on what the server admin could do about your listed keys
npdoty: moderation
npdoty: abuse in the fediverse, as any social network, a massive porble,, you report to the admin, the admin takes action. maybe that won't be as straightforward if E2EE.
Evan: it is a really good question that we have not looked into
Evan: my expectation is taht by definition it would be impossible to do anything about it
<npdoty> do you need a capability for message franking and reporting a message?
sysrqb: meta has some systems to report abuse
dimitry: moderation is hard for decentralized social networks, we do have a whole Task Force, you definitely want to join that conversation
evan: it is a very interesting question
<bobwyman> But, would there be anything in the protocol for moderation? I think not.
twiss: OpenPGP person here, will say for the record that the new RFC is only 3 months old, and addresses many problems, MLS is a greenfield protoocl, a better fit for your use case.
<sysrqb> https://
twiss: key transparency working group, with MLS in mind, and also other use cases
twiss: mozillla has been working on implementing a MLS API, would chrome be thinking about the same
estark: early days for mozilla also, would also be a game changer for you all?
<npdoty> I'm not clear what a WebMLS API would be exactly
twiss: implement the primitives in WebCrypto and then polyfill
twiss: performance
estark: may be more secure too, side-channels
simon: to follow up on that, we want to consider who wants to be in control of the keys
simon: what are the challenging parts about this
simon: do you just want to have what whatsapp is doing?
simon: maybe it works for for few people differently than many people
evan: the primary focus has been on encrypted DMs
<bobwyman> Even unencrypted but signed DMs would be interesting for some uses.
dimitriz: harm minimization, we are dealing with plain text directed messages, do we want to solve the easier problem of 1:1 and then move on to the harder cases
dimitriz: if MLS exists, what's the hard part?
dimitriz: MLS is an abstract protocols, it is not a concrete protocol, that would be MIMI (?), my question to all of you familiar with MLS, are there success stories that you are familar with?
evan: i mentioned WebEX earlier
evan: open standard i dunno
evan: this great conversation on E2EE, wondering how to keep this conversation going, sounds like Web App Sec is a great place to be there and be part of the conversation
evan: a task force, we meet monthly, it is on the community group calendar
npdoty: is there a mailing list?
dimitriz: on what's the hard part about this, it is of course, distributed identity, the decentralized social web, unlike whatsapp, is that it is in a central zone of authority, we are dealing with directed messages, across domains, across user accounts ....
dimitriz: lets say MLS is perfect use case, the hard part is, e.g. how do you discover the user's public key?
dimitriz: uses the actor's profile and extends it to expose the public key
dimitriz: a JSON object, useful metadata, and list of the public keys,
dimitriz: one of the tricky parts of the going across domains
<Simon> dmitriz: That is definitely a hard problem and afaik it's actually also unsolved in the whatsapp case. In that case you have to trust Facebook to give you the right key for the person you are talking to.
<Simon> In theory people can manually verify and thus discover a server who is attacking them. A good starting point for that would probably be https://