- E2E/OTR encryption is something some of us are interested in, but due to the nature of our platform probably isn't going to happen anytime soon (we'd want to do it right, which requires time and effort).

- Some libraries support connecting through user accounts, and there are various third-party tools for "linking" chat rooms, incl. some client plugins for irssi and such. We don't officially support it, but it's definitely possible.

- Search is currently live on our alpha-testing client, and should be rolling out globally soon. It's also possible to save or log channels through the API fairly easily.

So technically that mean that sysadmins at discord can freely browse the billions of message that are stored on your DB?

And if you are ever hacked all this chat database can be sucked up for free due to lack of encryption?

I must be wrong seriously what did I miss this can't be?

There's a difference between end-to-end/client-side encryption and secure/encrypted backend storage.

I don't think anyone's commented on the backend security situation (I'd hope they'd have messages encrypted at rest, but it doesn't seem that encryption has been a priority), just that they don't do E2E.

The point of our service is that chat is persistent. You can scroll back through time and read all the messages you sent. Users are free to delete whatever they sent whenever if they wish, but for almost everyone persistent chat history is a huge feature. Also important to note that as of the numbers we released last July we receive around 40 million messages a day. The public stats released about iMessage suggest that 2 billion messages are sent per day.

Can users at least opt-out of persistent chat history? Or define a timeframe after which message are deleted?

You are basically confirming that your company is storing a lot of personal data without user specific encryption. This is pretty scary and I hope you have some improvement about this situation on your roadmap. If not your are a "leak" away from a big problem.

Cool features are neats, but in 2016 privacy should not be seen as a secondary feature...

thanks for the informative response. I will look into how difficult it is to connect to a server using a user account from an IRC client, as that would make the experience much nicer for users like me.

I'm curious about the logging API permissions - it seems kind of weird that I could potentially join someone's Discord server and then download logs of their conversations for the past year instantly after joining, but I suppose this is already possible by viewing history in the client?

EDIT: looking at the API on https://discordpy.readthedocs.io/en/latest/api.html, it seems you need permission for the channel logs, but that can't prevent someone from writing code to collect them manually, regardless of permissions?

Discord has a pretty indepth permission system that allows per-channel/per-user setup.

If a server allows a user to view the message history (which basically mean, when you enter the channel, you can see previous messages and scroll up), then yes, that user can write a bot to save all the messages. I don't really see what the issue is here.

That to me really is one of the main reasons I prefer Discord to IRC. It's the fact that you can join a channel from any device and see past conversation. But of course, if for security reasons you don't want that, you can very easily disable message history and have it act like IRC does.

The channel log permission only applies to logs before you joined. You can always scroll up to the point you joined the server.

It's pretty easy to setup the discord-irc bridge, assuming you're referring to bitlbee. I already use it to have an IRC interface for facebook, google hangouts, etc, so discord was just adding a plugin and configuring the account, which took about 10 minutes total.

I don't think this is a "security" issue as much as it's a usability or privacy issue, and I don't think it's an example of Discord being evil.

For a start, it's not quite "on install", but after joining your first voice channel. The issue comes from the interaction of a series of reasonable steps that on the whole result in an unfortunate experience for some people. The problematic series:

* By default, Discord uses voice detection to determine when you're speaking, as opposed to push-to-talk. This feature makes perfect sense.

* By default, Discord configures itself to start up on login. This feature makes sense. (I personally immediately turn that option off, but I don't resent its inclusion.)

* When started, Discord rejoins any voice channel you were in when Discord was last exited. This feature also makes perfect sense. [Edit: Apparently this is no longer true, and Discord will only rejoin the channel if you were active within the past 5 minutes.]

Essentially the result of these design decisions in series is [edit: was] that if you install & use Discord, and fail to manually disconnect from your voice channel, next time you start your computer Discord will automatically join your last channel and broadcast any loud enough audio in the same room as your computer to the voice channel.

There are a few mitigating factors, too: Discord is pretty obviously open and on the screen when this happens, and it does show your active voice channel, and it does show an activity indicator when you're broadcasting.

> Essentially the result of these design decisions in series is that if you install & use Discord, and fail to manually disconnect from your voice channel, next time you start your computer Discord will automatically join your last channel and broadcast any loud enough audio in the same room as your computer to the voice channel.

It's worth noting that Discord no longer does this if you've been away from the voice channel for more than 5 minutes. The feature was intended to autoreconnect you when the app was restarted due to updates and such, not to cause people to accidentally broadcast themselves on system start.

Ah, excellent. I wasn't aware they'd added a timer to the channel reconnection. That's an elegant way of solving the problem without compromising the important part of the features.

What? No it doesn't?

The very first time, you need to very clearly UNMUTE yourself manually by pressing a button, even after you join a voice channel.

After that first time, joining a voice channel will enable your mic, and by default it also makes a clear sound. There is a feature that reconnects you if you were connected to a voice channel before you left (though it seems to be limited to 5m now).

But again, unless you 1. connect to a voice channel and 2. press the unmute button that first time, there is no listening happening...

You can verify all this on Chrome, since there, they have to specifically ask for your permission before accessing your microphone, so you know exactly when they do it. Open Discord on Chrome and play around, join a voice channel, unmute, and only then it will ask for access.

I would consider this more of a privacy issue than a security issue - but something that should nonetheless be communicated clearly to user. Maybe these terms don't seem worth differentiating, but I see privacy as "what info do they collect" and security as "how safe do they keep my info, after they collect it".

Voice activation is the default of all popular VOIP products. You have to specifically join a voice channel, and it will display that on the bottom left if you're in one. Mumble, TS, Skype especially, all of those use voice activation in setup first. Its the norm, and people expect it, and moreso, want it. I hate voice activation, personally, but with how Discord is used as a group chat in replacement of Skype, it makes sense to default it.

> Any app that has voice turned on whenever it detects sound by default, without prompting the user on installation, doesn't take security seriously.

That's an an opinion.