Re: Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata
Peter Saint-Andre <[email protected]>
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
On 1/20/26 12:28 PM, Goffi wrote: > Le mardi 20 janvier 2026, 19:45:35 heure normale d’Europe centrale Thilo > Molitor a écrit : >> To be honest, I don't understand the "encrypted roster" discussion. >> Even if the server does not see the roster at all, it is able to fully infer >> which jids are part of a user's "roster" by just checking the PubSub >> subscriptions and fetches of that user. >> >> Isn't an "encrypted roster" implemented this way just a farce? >> Or do I miss something important here? >> >> -tmolitor > > The JID is not visible, it's a random ID in the pubsub items, and the fetches > are done whenever client want to sync. There is a single node to subscribe, > you can't get any information from that, beside a very approximate size of the > roster, and the <reserved> element is there to make it muddy. > > The server can know who you are communicating with by checking "from" and "to" > from message (until we have something like sealed sender), or checking PEP > requests (for OMEMO for instance), but the goal here is to hide the sensitive > metadata (name, and groups, possibly other things). > > This is a first step toward metadata reduction. The server can vaguely guess > the relations of the entity, but it has less information than before. From the perspective of a privacy-respecting server administrator, I would say there are benefits in not knowing the "social graph" (e.g., there is precedent for governmental authorities to request the roster for JIDs of interest). There are also costs (e.g., in the past I have asked users who've lost their password to verify JIDs in the roster as a way to verify JID "ownership"). However, it seems to me that the benefits outweigh the costs. Peter _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]