I don't really understand the reasoning between implementing E2EE for video and audio but not for chats in themselves. I feel like for those things, its either all or nothing, otherwise its mostly useless.
The video and audio is ephemeral and only for parties which are present. Chats are expected to be stored and available to people who are not available. That's the big thing. Once you've sent a packet of video/audio, you don't need to use it ever again.
People expect to join servers and have the history available to them to search. E2EE means that history is not available, and all indexing happens client-side, all messages are stored client-side, etc.
You know it's possible to store and serve encrypted data, right? It's not a one time use will-self-destruct-in-30-seconds deal. The data is still decryptable after it's been sent.
Except not really with proper E2EE. Go and join a new Signal or WhatsApp group. You'll notice they're empty. As you were not around for a key exchange when the messages were initially sent.
It's possible to implement shared history systems where newly invited members of a group can request access to the history of a group, while preserving E2EE security.
Bringing up the ephemerality of A/V chats is not about security, it's about the user experience.
> People expect to join servers and have the history available to them to search. E2EE means that history is not available
It's more acceptable to Discord users for video and audio chats to be E2EE because Discord has always offered them as an ephemeral experience: unlike text chats, they never offered audio/video chat history as a feature for users.
I would ordinarily have thought the same, but what immediately came to mind was the TOS update that they "generally do not store the contents of video or voice calls"[0]. (I've since forgotten what it looked like before that but remember a big reaction in the userbase.)
I wonder if those terms would be practically nullified in any way if the E2EE is enabled.
Though, maybe they would attempt to implement something like Apple's offline CSAM policing that almost (IIRC?) came to be. There is also the Whatsapp method (albeit for text-based messages) that the app client of the user reporting you will send decrypted messages to Facebook.
Your other comment got auto-killed because m*sturbating is a flagged word.
That aside, I was only referring to private communications. Moderation in a public server is different, and there should be more visibility for server admins. With that said, Discord has been improving moderation tools, and I'm not sure how trolls can be stopped as long as making (or stealing) an account is easy. Remove that aspect, and half the reason for using Discord is gone.
Totally fair, even if I'd argue that Discord far and away aims to be a social platform (that should be prioritizing straightforward and intuitive control for server/guild administrators) over a private messenger. And admittedly, I'll complain to no end about those moderation tools beyond the point of fruitful discussion.
Thank you for pointing out the dead post; it's good to know for future reference (and looks like a guardian angel has since revived it :)
I'd argue it's because there's a lot of problematic content that gets shared in text that just isn't really much of an issue (or isn't viable to detect) in audio/video.
I'd argue the opposite somewhat: there's a lot of problematic content that's an issue with audio/video, but like you said, it's not viable to detect at scale, so it's better to close the door.
The cynic in me agrees with you here - this is likely a way for them to go "oh no, we couldn't see that information, it's *encrypted* so we have no liability, legal or otherwise, to stop any sort of abuse on our platform since we can't see it"
Well, this is why Signal is fine while the Telegram boss is in jail. As long as you haven't done anything illegal (and aren't explicitly trying to enable illegal activity), it's perfectly fine to just say "we can't do this." I'm really for this; being able to inspect users' data should be a liability.
I don't feel convinced of this takeaway, at least in the context of being applied across the board.
I help administer a semi-large, public studygroup community that sees its share of trolls and the like joining the channels and causing disruptions (up to and including exposing themselves and masturbating/helicoptering) for shock value, etc.
If anything, I find Discord's moderation tools for server administrators painfully lacking. Discord is not Signal.
I would have liked to see this in some form closer to an assignable privilege to send out/upload E2EE data granularly grantable to server regulars, while new people start out without the privilege.
This press release going into cool technical details in order to tout E2EE and namedropping one of the most reputable consultants in the biz feels a little tonedeaf.
more sensibly, and of which i would be really receptive to (as a server/guild administrator), granular setting on a per-channel basis.
of course, this sentiment largely takes for granted that there is any open-facing mission on Discord's part to facilitate community moderation; i definitely tend to lean privacy-first in general.
No, because half their premium features are dependent on them controlling the client. Even excluding relatively new things like client theming, a custom client could enable custom emojis everywhere, or make it easy to offload storage to another site to avoid paying for nitro. As long as a service is free(-to-play), there will always be a somewhat adversarial relationship between the user and the company.
That doesn't mean much when the discord TOS forbids use of anything but the official client to connect to their services. They seem to turn a blind eye to the various unofficial clients mostly, but also do occasionally ban a subset of their users occasionally despite no other TOS violations.
How can I possibly trust the Discord client is actually using that library and not a modified version that calls home? The whole point of using open source is being able to see the entire code of the program, and compile it yourself
If the client is proprietary and controlled by the vendor, E2EE is meaningless.
Last I checked, Discord is a proprietary application that updates itself on startup with freshly baked proprietary blobs straight from Discord Inc. They can say all they want about how great the encryption itself is, sure I believe them, but as long as alternative clients are forbidden and Discord's proprietary self-changing software exists on either end, it doesn't matter.
It's not meaningless (such applications are quite heavily inspected for signs of malfeasance by many parties that would stand to benefit from widely publicizing any backdoor), but it does substantially reduce the value, especially if your threat model includes being specifically targeted for a bypass.
The whole point of all this fancy encryption is to make it mathematically impossible for the vendor to read your messages. It doesn't matter if it's mathematically impossible for them to read messages on the server if it's operationally trivial for them to extract them from the client.
It's end-to-end encrypted, but both ends are wide open for Discord to do what they like. If not them, someone doing a supply chain attack on their frivolously & opaquely updating proprietary clients.
WhatsApp has E2EE, but how do you think they found CSAM on people's devices? Because they control the endpoints.
You really think someone is out there reverse engineering and debugging every inch of the behemoth that is Discord, any part of which could leak the keys, or compromise them in some non-obvious way? In every release? Yeah, right.
Also, you should rethink "many parties ... would stand to benefit from widely publicizing any backdoor." A new bugdoor is found in WhatsApp every six months and nobody cares.
I've been watching a slow enshittification of Discord over the last few years and preparing to move to the Next Thing in a year or two, but this actually seems like a great move, and technically interesting. Is there a downside/drawback I'm not seeing?
This does seem a nice feature and definitely a step in the right direction but why use e2ee for video and audio but not chat? That's afterall where most of Discords activity is happening
Because E2EE causes an absolute ton of friction to the chat experience. Stuff that you expect to just work like chat history and searching no longer works.
Haven't used WhatsApp but presumably it indexes client-side. On Discord people want to search large servers including messages since before they joined, so this approach wouldn't really work.
