Replies (25)

@JeffG @Max I am curious about this statement: A notable exception here is Nostr-based WhiteNoise that avoids the need for an authentication service, relying on user identities being their public keys. The main downside of WhiteNoise remains the lack of participation privacy, as relays have knowledge of all groups where the user participates.↩︎
In retrospect, I should have just copypastaed 😂 **Summary of "MLS: The Naked King of End-to-End Encryption"** The article critiques the Messaging Layer Security (MLS) protocol, a widely-adopted solution for end-to-end encryption in large groups. The author argues that MLS fails to effectively solve the problem of end-to-end encryption in large groups due to its reliance on a trusted authentication service, which can be compromised by the communication provider. **Key Points:** * MLS requires trust in the communication provider, which contradicts the purpose of end-to-end encryption. * The authentication service in MLS can be compromised, allowing the provider to read messages between members. * The author suggests that simpler alternatives, such as Signal's approach, are more effective and secure for medium-sized groups. * MLS's complexity and high development costs make it less practical for widespread adoption. **Conclusion:** The author concludes that MLS, despite its adoption by many technology companies, is not a reliable solution for end-to-end encryption in large groups. They recommend considering alternative solutions that prioritize user security and privacy. Would you like me to elaborate on any of these points?
But the beauty being you can infinite identities, or use a repay by a memeber of the group. Everyone in a group knows you are in a group after all, if you don't one someone knowing you're in a group, use a different identity. Does whitenoise have invite only groups? You could trampoline hop into an anon group and use public relays if you were lazy.
If a relay requires auth, then yes — it could sniff some information. As for the other points: – The welcome event is wrapped in a NIP-17 DM, so it’s not linked to the MLS group. – Group IDs can be rotated, even per message. – IPs can be hidden by using the Tor network. Also, some information can be obtained from the req, but auth is required to identify the sender.
So - we don't have the AS issue because Nostr is our AS. We use pubkeys verify authenticity and you're trusting the key package events signed by those keys when you're adding someone to a group. AFAICT, the participation privacy question is about relays being able to see what groups you're in by seeing what group IDs you're requesting. I believe that we've mitigated this pretty well since we're using random (and rotating) identifier(s) for each group (yes, it can be more than one). We also want to eventually break up the requests into lots of different reqs/subscriptions (probably done over Tor or something similar) to further obfuscate this info.
For those wondering about my thoughts on @SimpleX Chat 's latest article about MLS. tl;dr - I think it's pretty balanced and describes something that we (and the MLS folks) have known from the start. If you have a centralized identity/authentication service telling you who is who, you are trusting them with a pretty important part of the system. As he points out, NIP-EE (the spec about how to use MLS on Nostr) and, by extension, White Noise doesn't have the authentication service problem because Nostr is our AS. We use pubkeys for identity in groups and you're trusting the key package events signed by those keys when you're adding someone to a group. ✅ In general, this is an issue for other MLS implementations though. The authentication service is a "trusted" third party, with all the trappings. AFAICT, the "participation privacy" question is about relays being able to see what groups you're in via the group ID values you're requesting events for. There are two points to make here. First, relays can see what group IDs a given IP address is requesting events for. I believe that we have mitigated this pretty well since we're using random (and rotating) identifier(s) for each group (yes, by design, a single group have more than one visible ID value at a time). Obviously, this is also mitigated by using a VPN or Tor to make requests to relays. We don't yet but White Noise will eventually break up these requests into lots of different reqs/subscriptions (probably done over Tor or something similar) to help here. One thing that he didn't mention but is worth talking about; relays see events with a given "h" tag (the group ID I talked about above). Practically, this means that watching a given group ID value gives relays some idea of the relative amount of activity for a given group. Critically though, they can't see the number or identities of it's members, since all those messages are published via ephemeral keys. It's just a relative amount of activity (at least until the group rotates it's group ID). Happy to answer more questions from folks on the article or on MLS. View quoted note →
But please note the comment in the post (and Nostr post), that Whitenoise smartly avoided authentication service problem. What is the most annoying is that this problem is never mentioned in announcements of companies rolling it out and in media publications about MLS.
frphank's avatar
frphank 4 months ago
Whitenoise didn't "smartly" avoid it. Pubkeys and the identity in nostr, as they are in @SimpleX Chat The AS is a hack to bridge legacy systems that are based on string/"human readable" identifiers into the modern world of pubkey identities.
Keychat's avatar
Keychat 4 months ago
Keychat MLS Group doesn’t have this problem either.