15:02:12 <RRSAgent> RRSAgent has joined #e2ee
15:02:16 <RRSAgent> logging to https://www.w3.org/2024/09/25-e2ee-irc
15:02:18 <tpac-breakout-bot> RRSAgent, do not leave
15:02:18 <tpac-breakout-bot> RRSAgent, make logs public
15:02:19 <tpac-breakout-bot> Meeting: End-to-End Encryption (E2EE) on the Social Web
15:02:19 <tpac-breakout-bot> Chair: Dmitri Zagidulin
15:02:19 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/89
15:02:19 <Zakim> Zakim has joined #e2ee
15:02:20 <tpac-breakout-bot> Zakim, clear agenda
15:02:20 <Zakim> agenda cleared
15:02:20 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
15:02:21 <Zakim> agendum 1 added
15:02:21 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
15:02:21 <Zakim> agendum 2 added
15:02:21 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
15:02:23 <Zakim> agendum 3 added
15:02:23 <tpac-breakout-bot> Zakim, agenda+ Discussion
15:02:23 <Zakim> agendum 4 added
15:02:23 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
15:02:23 <Zakim> agendum 5 added
15:02:23 <tpac-breakout-bot> tpac-breakout-bot has left #e2ee
21:36:54 <cristianolongo> cristianolongo has joined #e2ee
21:42:09 <dmitriz> dmitriz has joined #e2ee
21:44:38 <robbiemc> robbiemc has joined #e2ee
21:47:38 <rigo> rigo has joined #e2ee
21:47:42 <goto> goto has joined #e2ee
21:47:44 <ddworken> ddworken has joined #e2ee
21:47:45 <dmitriz> present+
21:47:46 <estark> estark has joined #e2ee
21:47:51 <rigo> present+
21:47:53 <goto> Joe, Chrome Security
21:47:56 <goto> Camile, Chrmoe Security
21:48:04 <estark> present+
21:48:04 <goto> Daniel, Proton
21:48:06 <npdoty> npdoty has joined #e2ee
21:48:11 <npdoty> present+
21:48:15 <sysrqb> sysrqb has joined #e2ee
21:48:20 <dmitriz> Sam Goto, Chrome Platform APIs
21:48:37 <goto> Erica, Legendary Requirements
21:48:46 <goto> Matt Finkel, Security/Privacy, Apple
21:48:49 <ericaconnell> ericaconnell has joined #e2ee
21:49:02 <goto> Nick Doty, Center for Democracy and Technology
21:49:06 <goto> Dimitry, Co-chair of Social Web CG
21:49:30 <goto> Evan Pomodrou, Co-author of ActivityPub, E2E task force
21:49:34 <goto> (from zoom)
21:49:59 <trwnh> trwnh has joined #e2ee
21:49:59 <goto> Robbie, Google Chrome team, Web Platform, PWAs and IWA
21:50:09 <goto> Bob Wyller, used to be at Google, no more
21:50:38 <goto> Christiano Longo, University of ___, researcher on the field of Semantic Web and description logics
21:50:43 <jdeblasio> jdeblasio has joined #e2ee
21:50:49 <bobwyman> bobwyman has joined #e2ee
21:51:14 <goto> Evan: problem space, solutions, selection down to a few we are considering, next steps for E2EE within activity pub
21:51:54 <goto> Evan: activity pub = distributed social network API and protocol, roots in RSS, idea of a feed
21:52:21 <goto> Evan: but than it transforms significantly from there, JSON-LD, much more structure within the feed, things like profile, events like "liking", "sharing", "replying"
21:52:31 <goto> Evan: push distribution structure
21:52:46 <goto> Evan: privacy mechanism, so that i can choose who can receive what i send ...
21:52:56 <goto> Evan: also extensible, add new vocabularies
21:53:08 <goto> Evan: REST API, creating. new content,
21:53:23 <goto> Evan: clients interact with their servers, sending data
21:53:30 <goto> Evan: server based protocols between domains
21:53:39 <goto> Evan: each person has a dedicated serve that they use, similar to email
21:53:40 <twiss> twiss has joined #e2ee
21:53:47 <goto> Evan: the server takes care to routing it to other people on the social web
21:54:01 <goto> Evan: ~30K servers, 20M registered users, ~2M MAUs
21:54:19 <goto> Evan: best known implementations, flipboard, wrodpress, threads, mastodon, ghosto.org
21:54:48 <goto> Evan: expectations was that there was a lot of trust between the user and the server, sort of like email
21:55:16 <goto> Evan: how it is shaking out today is that it is low affinity, open registration server, hobbiers
21:55:42 <goto> Evan: they tend to have higher risk user base that don't feel comfortable in other places, LGTB+, political, information security, etc
21:55:50 <goto> Evan: low affinitiy user-server
21:56:08 <goto> Evan: when people make posts, they can choose just a single receipient, e.g. just for Dimitry
21:56:15 <goto> Evan: encrypted in flight with HTTPS
21:56:25 <goto> Evan: however, the posts are stored, in the clear, in the server
21:56:32 <goto> Evan: both on the sender and the receiptient
21:56:58 <goto> Evan: consequently, because things are stored in the clear, "my posts are stored in the server they could look at it"
21:57:17 <goto> Evan: for this reason, in the mastodon UI, they have a disclaimer "please don't share sensitive information over mastodon".
21:57:29 <goto> Evan: sending E2EE in social networks is pretty important
21:57:38 <estark> q+
21:57:44 <goto> Evan: a situation where we have low trust in the directed messages inhibits this growth
21:57:53 <goto> Evan: one solution to this is to integrate E2EE into Activity Pub
21:58:12 <goto> Evan: encrypt it at the client side, and decypt it a the receiptient
21:58:25 <goto> Evan: a proposed proposal out of the CG
21:58:40 <goto> Emily: do you need to support groups? and if so, groups of arbitrary sizes?
21:58:58 <goto> Evan: good question. Let me walk you through the user stories.
21:59:55 <goto> 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).
22:00:15 <estark> q-
22:00:18 <sysrqb> q+
22:00:21 <goto> Dimitry: we are starting from non-encrypted, so 1:1 is more incremental/easier and a starting point
22:00:58 <sysrqb> sysrqb has joined #e2ee
22:01:29 <goto> Evan: links are low effort
22:01:36 <goto> Evan: initiation and handoff
22:01:59 <goto> Evan: Full external protocol support
22:02:32 <goto> 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.
22:03:03 <goto> Evan: another way that we could do things is to use an abstract protocol, and use activity pub as a substrate.
22:03:27 <goto> Evan: the Mastodon API is very cloned, unfortunately not very extensible, with each of the messages is hard.
22:03:51 <goto> Evan: the other option is the extensible points in Activity Pub, using an abstract protocol built on top of the Acvity Pub protocols
22:04:05 <goto> Evan: in terms of the integration model, the first 5 aren't great, we are looking into the last one
22:04:09 <npdoty> npdoty has joined #e2ee
22:04:16 <goto> Evan: candidate abstract protocols
22:04:22 <rigo> q+ to ask whether they have considered just blunt RDF encryption
22:04:23 <goto> Evan: how do we do end to end encryption?
22:04:26 <npdoty> is that the not-widely-implemented Client-to-Server API part of ActivityPub?
22:04:37 <goto> Evan: looked at a number of protocols.
22:04:40 <goto> Evan: PGP/MIME
22:05:20 <goto> Evan: a series of RFCs, hard to scale past > 100 recipients
22:05:24 <goto> Evan: lots of libraries, simple
22:05:40 <npdoty> recently updated set of RFCs, for what it's worth. might be surprising how actively implemented and developed it is.
22:06:18 <goto> Evan: S/MIME
22:06:30 <goto> Evan: well standardized
22:06:37 <goto> Evan: OTR, something mid 2000s
22:06:41 <goto> Evan: designed for IM
22:07:10 <goto> Evan: implemented in XMPP, nice properties that makes it more robuts, probelsmw ith the network, slightly more complex, not very widely implemented
22:08:04 <goto> 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
22:08:12 <goto> Evan: widely used, trusted,
22:08:55 <goto> Evan: That's what DMA is nudging
22:08:55 <goto> Evan: chatty
22:09:14 <goto> Evan: ActivityPub works more like email than IM, kinda of complex
22:09:45 <goto> 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
22:09:52 <goto> Evan: Messaging Layer Security (MLS)
22:10:13 <goto> Evan: similar structure to Signal, IETF RFC 9420, designed to meet exactly the scenario we are doing
22:10:23 <goto> Evan: it scales nicely, uses a tree structure, royalty free
22:10:39 <goto> Evan: kinda of complex, key updates, group membership updates
22:10:46 <goto> Evan: it is in CISCO WebEX
22:11:23 <goto> Evan: PGP/MIME "too old", S/MIME "too old", OTR "too obscure", Signal "company control", MLS
22:11:56 <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...
22:12:44 <goto> Evan: recommendation result, activity pub extension, MLS
22:12:44 <npdoty> OpenPGP RFC was last updated July 2024
22:13:27 <goto> Evan: ways for discoverying keys, mls:Keys
22:13:35 <goto> Evan: given an Actor, can you give me their keys?
22:13:43 <goto> Evan: mls:Groups
22:14:14 <goto> Evan: you group things by conversation
22:14:21 <rigo> rrsagent, pointer?
22:14:21 <RRSAgent> See https://www.w3.org/2024/09/25-e2ee-irc#T22-14-21
22:14:22 <goto> Evan: mls:n namespace
22:14:43 <goto> Evan: mapping them into JSON-LD and making it into an extension
22:15:32 <goto> Evan: what happens next? working on a draft proposal
22:15:33 <estark> q?
22:15:37 <estark> q+
22:15:46 <goto> Evan: partner with Tom Coatest in a foundation
22:15:51 <npdoty> q+ on what the server admin could do about your listed keys
22:16:23 <npdoty> ack sysrqb
22:16:34 <goto> sysrqb: seems like a good choice
22:17:02 <npdoty> matt suggests that mls in particular seems like a good choice
22:17:25 <goto> 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
22:17:28 <twiss> q+
22:17:42 <goto> evan: can we verify that it is end to end enough?
22:18:03 <goto> evan: the key storage is going to happen on the client side, e.g. a web client or a native client
22:18:22 <goto> evan: so, the server would not be able to decrypt it
22:19:01 <sysrqb> q-
22:19:36 <goto> 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
22:20:07 <goto> 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
22:20:23 <goto> evan: the best solution that we've seen is for people to do manual out of band key checks
22:20:54 <goto> evan: not great solution
22:21:45 <goto> dimitry: mobile browser vs native apps, waiting for WebAuthn to support key agreement keys, to be added to the credential API, or for federation
22:21:56 <goto> dimitry: i can use external keys
22:22:06 <goto> dimitry: have you looked at the WebAuthn PRF extension
22:22:20 <goto> s/dimitry/estark
22:22:31 <dmitriz> q?
22:22:33 <npdoty> ack rigo
22:22:33 <Zakim> rigo, you wanted to ask whether they have considered just blunt RDF encryption
22:22:40 <estark> WebAuthn PRF extension
22:22:56 <goto> 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
22:23:07 <goto> rigo: it is just going after perversive monitoring
22:23:42 <goto> rigo: why do we do complicated when we can do simple?
22:23:44 <npdoty> what about message franking / moderation?
22:24:22 <goto> 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
22:24:56 <goto> rigo: a standard that can be implemented at a large scale, may merit a blank sheet approach
22:25:37 <goto> 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
22:25:49 <goto> Evan: it may reduce our ability to keep users safe
22:26:06 <goto> Evan: changing user's perception of the system
22:26:13 <dmitriz> q+ to respond to Rigo
22:26:23 <goto> Evan: having a broadly supported simple mechanism, better than narrow mechanism
22:27:07 <goto> 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 ...
22:27:25 <goto> rigo: if you are really doing very secretive things, maybe you should use Signal instead
22:27:37 <goto> rigo: that's why i think it is worth talking about the threat model first
22:27:45 <bobwyman> What is "a little bit secret?" Ain't no such thing.
22:27:51 <goto> rigo: lots of myth about the danger for the private messaging
22:28:32 <npdoty> q+ simon
22:28:38 <npdoty> ack estark
22:28:43 <dmitriz> ack estark
22:28:51 <goto> estark: there is a lot of incfeasing energy on adopting the wbe platform to support the E2EE threat model
22:29:07 <goto> estark: that would be awesome, Web App Sec
22:29:29 <Simon> Simon has joined #e2ee
22:29:44 <goto> estark: at some point you painted OTR, they are legitimate security problems, not nearly the same security guarantees as Signal
22:29:58 <estark> q-
22:30:09 <rigo> ack npdoty
22:30:09 <Zakim> npdoty, you wanted to comment on what the server admin could do about your listed keys
22:30:17 <goto> npdoty: moderation
22:30:25 <estark> q+
22:30:50 <goto> 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.
22:31:19 <goto> Evan: it is a really good question that we have not looked into
22:31:34 <goto> Evan: my expectation is taht by definition it would be impossible to do anything about it
22:31:45 <npdoty> do you need a capability for message franking and reporting a message?
22:31:53 <goto> sysrqb: meta has some systems to report abuse
22:32:24 <goto> dimitry: moderation is hard for decentralized social networks, we do have a whole Task Force, you definitely want to join that conversation
22:32:31 <goto> evan: it is a very interesting question
22:32:31 <bobwyman> But, would there be anything in the protocol for moderation? I think not.
22:32:43 <dmitriz> ack twiss
22:32:52 <dmitriz> q-
22:33:17 <goto> 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.
22:33:55 <goto> q+
22:34:09 <sysrqb> https://faq.whatsapp.com/1142481766359885/?cms_platform=web ("Report Someone": WhatsApp receives the last five messages sent to you by the reported sender or group, and they won’t be notified.)
22:34:45 <dmitriz> q+
22:34:47 <goto> twiss: key transparency working group, with MLS in mind, and also other use cases
22:35:15 <goto> twiss: mozillla has been working on implementing a MLS API, would chrome be thinking about the same
22:35:29 <goto> estark: early days for mozilla also, would also be a game changer for you all?
22:36:04 <npdoty> I'm not clear what a WebMLS API would be exactly
22:36:59 <goto> twiss: implement the primitives in WebCrypto and then polyfill
22:37:03 <goto> twiss: performance
22:37:10 <goto> estark: may be more secure too, side-channels
22:37:12 <estark> q-
22:37:17 <dmitriz> ack simon
22:37:32 <goto> simon: to follow up on that, we want to consider who wants to be in control of the keys
22:38:04 <goto> simon: what are the challenging parts about this
22:38:16 <goto> simon: do you just want to have what whatsapp is doing?
22:38:39 <goto> simon: maybe it works for for few people differently than many people
22:38:49 <goto> evan: the primary focus has been on encrypted DMs
22:38:54 <goto> q-
22:39:56 <bobwyman> Even unencrypted but signed DMs would be interesting for some uses.
22:40:13 <goto> 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
22:40:36 <goto> dimitriz: if MLS exists, what's the hard part?
22:41:21 <goto> 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?
22:41:26 <goto> evan: i mentioned WebEX earlier
22:41:32 <goto> evan: open standard i dunno
22:41:41 <dmitriz> q?
22:41:45 <dmitriz> ack dmitriz
22:42:16 <goto> 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
22:42:32 <goto> evan: a task force, we meet monthly, it is on the community group calendar
22:42:45 <goto> npdoty: is there a mailing list?
22:44:00 <goto> 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 ....
22:44:31 <goto> dimitriz: lets say MLS is perfect use case, the hard part is, e.g. how do you discover the user's public key?
22:44:48 <goto> dimitriz: uses the actor's profile and extends it to expose the public key
22:45:04 <goto> dimitriz: a JSON object, useful metadata, and list of the public keys,
22:45:17 <goto> dimitriz: one of the tricky parts of the going across domains
22:51:31 <dmitriz> dmitriz has joined #e2ee
22:55:46 <rigo> rigo has joined #e2ee
22:57:36 <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.
23:04:22 <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://datatracker.ietf.org/wg/keytrans/about/ which I think Daniel or Emily mentioned already anyway.
23:15:45 <rigo> rigo has joined #e2ee
23:16:38 <rigo> RRSAgent, please draft minutes
23:16:40 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-e2ee-minutes.html rigo