Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Reverse Engineer Discord

medium.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Let's Reverse Engineer Discord

#51

Post by tpetry »

jeltz wrote: post #47
gfodor wrote: post #7

This is common and necessary for WebRTC SFUs, which perhaps is why Discord does it to support the least common denominator of their web browser based clients. Edit: Yep, I thought I remembered reading this. Their voice servers are WebRTC SFUs. So this is basically state-of-the-art when it comes to voice over WebRTC. End to end encryption in WebRTC is not possible if you are using a SFU. https://blog.discordapp.com/ho…

Why don't SFUs support end-to-end encryption? Is it just a missing feature in the WebRTC protocol or am I missing some fundamental reason?

Yes its simply missing in the WebRTC spec. webRTC defines end-to-end encryption between two peers. But if you want to transmit data to many peers you need a server which is doing the fanout so the encryption is client1server and serverclient2.

This is true for all WebRTC implementations/services. They all state having end-to-end encryption but dont tell you that it means something different in WebRTC contexts.

PERC will solve this one day, but its sadly just a draft: https://webrtcglossary.com/perc/

Re: Let's Reverse Engineer Discord

#52

Post by gzer0 »

gfodor wrote: post #7

This is common and necessary for WebRTC SFUs, which perhaps is why Discord does it to support the least common denominator of their web browser based clients. Edit: Yep, I thought I remembered reading this. Their voice servers are WebRTC SFUs. So this is basically state-of-the-art when it comes to voice over WebRTC. End to end encryption in WebRTC is not possible if you are using a SFU. https://blog.discordapp.com/ho…

End to end encryption in WebRTC is indeed possible even if you are using an SFU, this is achieved via Privacy Enhanced RTP Conferencing (PERC).

[1]. https://www.callstats.io/blog/2018/06/01/examining-srtp-doub...

Re: Let's Reverse Engineer Discord

#53

Post by swish_bob »

saagarjha wrote: post #44
ip26 wrote: post #16

Earlier quoted context omitted.

If we're going to wander off into metaphor, this seems more analogous to a doorman refusing to allow you to bring your 800lb gorilla (sneakily dressed as your child) onto the elevator.

I think a better one would be the postman unsealing and re-sealing your mail.

It's (mostly) a broadcast service. Them metaphor in this case, it's the radio station boosting your signal ...

Re: Let's Reverse Engineer Discord

#54

Post by jokoon »

Wasn't skype originally P2P? I wish there was a simple windows voip client that was doing p2p voip.

I often experience cuts with skype and discord, I think their servers can have a hard time handling low latency properly.

Re: Let's Reverse Engineer Discord

#55

Post by sequence7 »

ghjnut wrote: post #29
gfodor wrote: post #7

This is common and necessary for WebRTC SFUs, which perhaps is why Discord does it to support the least common denominator of their web browser based clients. Edit: Yep, I thought I remembered reading this. Their voice servers are WebRTC SFUs. So this is basically state-of-the-art when it comes to voice over WebRTC. End to end encryption in WebRTC is not possible if you are using a SFU. https://blog.discordapp.com/ho…

Didn't know what an SFU was. https://webrtcglossary.com/sfu/

For convenience:

> SFU stands for Selective Forwarding Unit.

> At times, the term is used to describe a type of video routing device, while at other times it will be used to indicate the support of routing technology and not a specific device.

> An SFU is capable of receiving multiple media streams and then decide which of these media streams should be sent to which participants.

Re: Let's Reverse Engineer Discord

#56

Post by F3nd0 »

jokoon wrote: post #54

Wasn't skype originally P2P? I wish there was a simple windows voip client that was doing p2p voip. I often experience cuts with skype and discord, I think their servers can have a hard time handling low latency properly.

You could try Jami. It’s fully distributed and improves over Skype and Discord by respecting its users’ freedom. Calls should work fine with it, but text messaging outside of them can be unreliable.

https://jami.net/

Re: Let's Reverse Engineer Discord

#57

Post by uncle_j »

moooo99 wrote: post #50
throwaway8879 wrote: post #13

Earlier quoted context omitted.

This is actually a good indicator for understanding the issue of privacy/surveillance. There are enough hackers and engineers who care little about being spied, despite understanding some of the inner workings of how the spying is done - as long as the benefits of a free service outweigh the slight privacy-violating annoyances. Now try to understand why the average person cares even less.

I don't think this is a reliable indicator. When you take a look at the target market of discord, it becomes pretty clear why no one really cares about the data being decrypted. The main audiences for discord are gamers and massive open communities. The first group is unlikely to discuss any sensitive topic via discord and it's not unlikely that a lot of discord users even stream their sessions publicly. The majority…

There is a massive political community on discord, there are other groups on there such as dooxers, trolls and irl shitposters and other odd groups that are doing naughty things.

Re: Let's Reverse Engineer Discord

#58

Post by jtl999 »

sandGorgon wrote: post #10
sl1ck731 wrote: post #9

Earlier quoted context omitted.

I'm not sure why they haven't tried the business communications angle with an alternate branded Slack competitor. As a remote worker on an almost entirely remote team, we would benefit from a sort of voice channel huddle on-demand or even just watercooler chatting. There is something more casual about jumping into a premade voice channel where people may already be chatting than starting a Webex or initiating a Slack…

They are vehemently against this. There is still no way to turn ON email notifications once you "unsubscribe".

I'm not sympathetic to Discord,but talk about (probably) shooting yourself in the foot.

Re: Let's Reverse Engineer Discord

#59

Post by de_watcher »

tpetry wrote: post #51
jeltz wrote: post #47

Earlier quoted context omitted.

Why don't SFUs support end-to-end encryption? Is it just a missing feature in the WebRTC protocol or am I missing some fundamental reason?

Yes its simply missing in the WebRTC spec. webRTC defines end-to-end encryption between two peers. But if you want to transmit data to many peers you need a server which is doing the fanout so the encryption is client1 server and server client2. This is true for all WebRTC implementations/services. They all state having end-to-end encryption but dont tell you that it means something different in WebRTC contexts. PERC…

As I understand, Discord server doesn't need to do audio processing, all mixing is done on the clients. So it would benefit from the "one-to-many" encryption, because currently it has to decrypt from one p2p connection and to encrypt to several p2p connections when someone talks (which breaks the end-to-end).

Re: Let's Reverse Engineer Discord

#60

Post by jeltz »

de_watcher wrote: post #59
tpetry wrote: post #51

Earlier quoted context omitted.

Yes its simply missing in the WebRTC spec. webRTC defines end-to-end encryption between two peers. But if you want to transmit data to many peers you need a server which is doing the fanout so the encryption is client1 server and server client2. This is true for all WebRTC implementations/services. They all state having end-to-end encryption but dont tell you that it means something different in WebRTC contexts. PERC…

As I understand, Discord server doesn't need to do audio processing, all mixing is done on the clients. So it would benefit from the "one-to-many" encryption, because currently it has to decrypt from one p2p connection and to encrypt to several p2p connections when someone talks (which breaks the end-to-end).

Yes, that is what SFU is except there is apparently not support for one-to-many end-to-end encryption yet in the WebRTC protocol.
Post reply on HN