7 ms·

Show HN: Briefing – Anonymous, secure, open source WebRTC group video chat

203 points by holtwick 6y ago

totetsu 6y ago
Looks useful thank you for sharing. The website that provides the web app and mediates the communication stores as (few -> little) data as possible
schoen 6y ago
How does the encryption work here? The home page says "end-to-end encrypted"; is there a key management concept and a key verification feature of some kind?
- ec109685 6y ago
  He means peers directly connect to each other, so there are no data packets that the server could man in the middle.
  - Beldin 6y ago
    Lack of a central server does not imply end-to-end security. In just about any useful situating, when A connects to B, the following will at least be in between: A's modem, A's ISP (typically multiple routing devices), B's ISP (ditto), B's modem. Since all of these are literally in between, they could act as men-in-the-middle... barring countermeasures. End-to-end implies some crypto scheme whereby all intermediate points can only act all-or-nothing: either they forward packages or not. The contents of the packages should be inscrutable to them. (ideally, you'd want the meta data to be similarly indecipherable, but that requires a Tor-like infrastructure.) So, either there is some cryptography, which requires exchanging keys somehow, or it's not end-to-end in a meaningful way.
    - enneff 6y ago
      WebRTC is encrypted.
      - perenzo 6y ago
        Correct. Scroll up the page to learn about the details: https://brie.fi/ng#help https://brie.fi/ng#help Also see https://webrtc-security.github.io/ https://webrtc-security.github.io/ WebRTC is end-to-end encrypted by default. There is a signaling server that helps establishing the connections between users in a room, but after that the communication is encrypted. Also those TURN and STUN servers are only required for technical reasons to get peer-to-peer working. So no content is ever passed unencrypted. That's the difference to other services like Zoom and Jitsi, where a server in the middle is receiving the video streams unencrypted and then redistributes. Although Jitsi is adding encryption support for that as well soon.
        clawoo 6y ago
        I think you are very much misinformed on the subject. You're not sending unencrypted streams to Jitsi, as it uses hop-by-hop encryption, meaning you send an encrypted stream to the server where it gets decrypted and re-encrypted for the rest of the participants. At no point you are sending "plaintext" data. What you might have heard is that Jitsi will be introducing end-to-end encryption, but it doesn't mean it doesn't have encryption at the moment.[1] I think it's a misnomer to say WebRTC end to end encrypted by default. If you cannot guarantee end to end encryption during the negotiation phase, you cannot trust that the party you're encrypting for/receiving encrypted content from is the actual party you are expecting to communicate with, hence the need to independently verify over a trusted channel whether the fingerprint in the SDP offer/answer matches. After the negotiation is complete, the streams will indeed be encrypted, but if the offer/answer SDP has been tampered with by the signaling server, which is under the control of a rogue/compelled provider, and another DTLS certificate has been inserted, the encryption is useless as far as complete communication security is concerned. [1] https://jitsi.org/blog/e2ee/ https://jitsi.org/blog/e2ee/
        perenzo 6y ago
        I did not want to say Jitsi is bad. It is one of the best solutions around. But you still have to trust the server if e2ee is not turned on and more than 2 participants are using it [1]: "This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge" I believe it is correct to say, that WebRTC is end-to-end encrypted. What you are referring to is, if you can trust to have a direct connection to the other participant and that you can make sure she is the person she pretends to be. This layer is indeed missing and will be added [2] I would very much appreciate your help on the project to eliminate those concerns. [1] https://jitsi.org/security/ https://jitsi.org/security/ [2] https://github.com/holtwick/briefing/issues/1 https://github.com/holtwick/briefing/issues/1
tpetry 6y ago
How do you do the background? Are you using the bodypix tensorflow library? Because in my tests it had been horrible slow and very inaccurate depending on lighting,
- perenzo 6y ago
  That's correct, I use https://github.com/tensorflow/tfjs-models/tree/master/body-pix#bodypixdrawbokeheffect https://github.com/tensorflow/tfjs-models/tree/master/body-p... It is indeed slow. The video signal first is drawn to a canvas and then from there streamed as a video again. Some browsers perform better than others. Probably due to WASM support, but I did not dig deeper here. The "pro" though is it all happens on the client in the browser.
cryo 6y ago
I don't understand the anonymous claim. Since in WebRTC peers connect directly to each other they'll see the IP of the other peer and can determine their locations. Further there is the signalling server which may also see these connection details if it isn't end to end encrypted (I haven't checked the code). IMHO private might be a better word than anonymous here.
- perenzo 6y ago
  By using the term "anonymous" I wanted to say, that no user account is required. To hide one self's identity and network location I would expect the users to make use of browsers like Tor or using VPN. I don't know of any way to provide anonymity on web application level. If somebody knows more, please let me know.
  - walterbell 6y ago
    How about the term "unauthenticated", which is well understood for HTTP requests?
    - perenzo 6y ago
      Well, IMO the definition of the word "anonymous" still fits how personal information is handled in Briefing: "Anonymity describes situations where the acting person's name is unknown" [1] And this is true regarding the Briefing service. [1] https://en.wikipedia.org/wiki/Anonymity https://en.wikipedia.org/wiki/Anonymity
      - inanutshellus 6y ago
        Heh, well you cherry-picked there. It goes on to say ". The important idea here is that a person be non-identifiable, unreachable, or untrackable." Regardless, it's Wikipedia, that definition ought to be fixed to say "identity" rather than "name".
      - walterbell 6y ago
        For online transactions, "name" has been generalized to PII (Personally Identifiable Information) from which name can often be derived. https://en.wikipedia.org/wiki/Personal_data https://en.wikipedia.org/wiki/Personal_data
waynenilsen 6y ago
How can we further decentralize this such that the entire app runs "without any servers"? Sadly it is so close but the realities of ipv4 and local subnets definitely makes this more difficult. I always thought that this is part of what webrtc was trying to solve
- perenzo 6y ago
  Well technically it is possible to avoid the signaling server, but you'll need some other channel to exchange the peers connection data. This is pretty inconvenient though. But a signal server is a rather light thing and easy to install on a location you trust: https://github.com/holtwick/briefing/tree/master/signal https://github.com/holtwick/briefing/tree/master/signal
  - waynenilsen 6y ago
    > you'll need some other channel to exchange the peers connection data Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
    - saurik 6y ago
      If you can figure out how to share that hash, you may as well just share the offer.
      - waynenilsen 6y ago
        Yes, serialization is the issue. URL length is technically unlimited but in practice very long urls don't work out so well
    - perenzo 6y ago
      That's a good idea. I don't know the internals of IPFS, but the related https://libp2p.io/ https://libp2p.io/ looks promising. Follow up https://github.com/holtwick/briefing/issues/52 https://github.com/holtwick/briefing/issues/52
    - 6y ago
nannal 6y ago
"No camera or microphone has been found!" Using firefox 79, the usual prompts to allow permissions were not issued.
- perenzo 6y ago
  This is a Firefox Nightly release, correct? Current stable release is 77.0.1 Do you experience those issues with the stable release as well? If so I would like to ask you to file a bug here and add the OS version. Thanks for letting me know! https://github.com/holtwick/briefing/issues/new https://github.com/holtwick/briefing/issues/new
Angostura 6y ago
I just wanted to say that this looks very nice indeed.
seesawtron 6y ago
Looks really cool. One key element is that anyone can spy on your call if they guess the random name that you generate to create the link. I am curious what randomizations you have used to generate those? (perhaps you don't want to share to avoid exactly the spying, I can understand if you feel that way). Thanks for your insights. Cheers
- perenzo 6y ago
  Indeed, it is a rather simple algorithm [1] But you can set any name you like, either in the input field or directly in the URL. Protected rooms, where the participants need to know a common secret, are planned to be added to the project, see [2] [1] https://github.com/holtwick/briefing/blob/master/app/src/components/app-welcome.vue#L266 https://github.com/holtwick/briefing/blob/master/app/src/com... [2] https://github.com/holtwick/briefing/issues/1 https://github.com/holtwick/briefing/issues/1
  - seesawtron 6y ago
    Yes password protection would definitely make this more usable. Have you also seen apprtc [0]? Could you point out if there are any differences you see there to Briefing? [0] https://appr.tc/ https://appr.tc/
    - perenzo 6y ago
      It is basically the same. Briefing is a bit more modern and has a few more features. As I mentioned in the help text on https://brie.fi/ng#help https://brie.fi/ng#help I started the project as a spin off of a virtual classroom project https://peer.school/ https://peer.school/ Sources https://github.com/holtwick/peer2school https://github.com/holtwick/peer2school
      - seesawtron 6y ago
        Cool. Also there is screen share option which is cool. I will pitch it to my peers and see if they catch on ;)
Andrew_nenakhov 6y ago
> Anonymous end-to-end encrypted End to end encryption implies that you have established an encrypted connection with a known participant and secured it by verifying your keys either off-band or via some CA provider to prevent MitM attack. If your chat partner is anonymous, and your only connection is via offered service, there is no way to determine if you are being spoofed. So anonymous end-to-end encryption is an oxymoron. I wish people would drop this e2ee fetish, insisting it everywhere, and would learn how it works, so they would be using the real thing where it makes sense, instead of opting for readily supplied snake oil.
- deleted 6y ago
  [deleted]
- nybble41 6y ago
  In this case authentication is provided through a shared secret (the room name). An arbitrary MitM wouldn't know the room name since the connection to the server is also encrypted. Unfortunately this isn't much of a secret, since the server also knows the room name, but it's a start. There is an open issue to add password-protected rooms which would fix that problem.
  - pizzazzaro 6y ago
    From an user-centric standpoint, would not both secrets - roomname and password - be shared concurrently, potentially in the clear? This drastically limits the utility. Communication channels are only as secure as the least secure participant! Especially in shared-secret implementations. Every so often, Grandma wants to be cool too. And invite her friends.
  - Andrew_nenakhov 6y ago
    In most e2ee threat models the biggest source of threat is the server that mediates the data exchange. Other threats are sufficiently thwarted with TLS, so ... ... these Briefing guys should better bring on these password protected rooms if they want to put this end to end encryption claim on their website.
sci_prog 6y ago
Do you maybe have instructions on how to set this up on my own server/domain? I've looked at the code but I'm not familiar with Vue. I have an online webgl multiplayer game where I create random room names to connect players. It would be amazing if I could use my domain and the same random room to enable video chat among the players.

203 points by holtwick 6y ago

Looks useful thank you for sharing. The website that provides the web app and mediates the communication stores as (few -> little) data as possible

schoen 6y ago

How does the encryption work here? The home page says "end-to-end encrypted"; is there a key management concept and a key verification feature of some kind?

ec109685 6y ago
He means peers directly connect to each other, so there are no data packets that the server could man in the middle.
- Beldin 6y ago
  Lack of a central server does not imply end-to-end security. In just about any useful situating, when A connects to B, the following will at least be in between: A's modem, A's ISP (typically multiple routing devices), B's ISP (ditto), B's modem. Since all of these are literally in between, they could act as men-in-the-middle... barring countermeasures. End-to-end implies some crypto scheme whereby all intermediate points can only act all-or-nothing: either they forward packages or not. The contents of the packages should be inscrutable to them. (ideally, you'd want the meta data to be similarly indecipherable, but that requires a Tor-like infrastructure.) So, either there is some cryptography, which requires exchanging keys somehow, or it's not end-to-end in a meaningful way.
  - enneff 6y ago
    WebRTC is encrypted.
    - perenzo 6y ago
      Correct. Scroll up the page to learn about the details: https://brie.fi/ng#help https://brie.fi/ng#help Also see https://webrtc-security.github.io/ https://webrtc-security.github.io/ WebRTC is end-to-end encrypted by default. There is a signaling server that helps establishing the connections between users in a room, but after that the communication is encrypted. Also those TURN and STUN servers are only required for technical reasons to get peer-to-peer working. So no content is ever passed unencrypted. That's the difference to other services like Zoom and Jitsi, where a server in the middle is receiving the video streams unencrypted and then redistributes. Although Jitsi is adding encryption support for that as well soon.
      - clawoo 6y ago
        I think you are very much misinformed on the subject. You're not sending unencrypted streams to Jitsi, as it uses hop-by-hop encryption, meaning you send an encrypted stream to the server where it gets decrypted and re-encrypted for the rest of the participants. At no point you are sending "plaintext" data. What you might have heard is that Jitsi will be introducing end-to-end encryption, but it doesn't mean it doesn't have encryption at the moment.[1] I think it's a misnomer to say WebRTC end to end encrypted by default. If you cannot guarantee end to end encryption during the negotiation phase, you cannot trust that the party you're encrypting for/receiving encrypted content from is the actual party you are expecting to communicate with, hence the need to independently verify over a trusted channel whether the fingerprint in the SDP offer/answer matches. After the negotiation is complete, the streams will indeed be encrypted, but if the offer/answer SDP has been tampered with by the signaling server, which is under the control of a rogue/compelled provider, and another DTLS certificate has been inserted, the encryption is useless as far as complete communication security is concerned. [1] https://jitsi.org/blog/e2ee/ https://jitsi.org/blog/e2ee/
        perenzo 6y ago
        I did not want to say Jitsi is bad. It is one of the best solutions around. But you still have to trust the server if e2ee is not turned on and more than 2 participants are using it [1]: "This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge" I believe it is correct to say, that WebRTC is end-to-end encrypted. What you are referring to is, if you can trust to have a direct connection to the other participant and that you can make sure she is the person she pretends to be. This layer is indeed missing and will be added [2] I would very much appreciate your help on the project to eliminate those concerns. [1] https://jitsi.org/security/ https://jitsi.org/security/ [2] https://github.com/holtwick/briefing/issues/1 https://github.com/holtwick/briefing/issues/1

tpetry 6y ago

How do you do the background? Are you using the bodypix tensorflow library? Because in my tests it had been horrible slow and very inaccurate depending on lighting,

perenzo 6y ago
That's correct, I use https://github.com/tensorflow/tfjs-models/tree/master/body-pix#bodypixdrawbokeheffect https://github.com/tensorflow/tfjs-models/tree/master/body-p... It is indeed slow. The video signal first is drawn to a canvas and then from there streamed as a video again. Some browsers perform better than others. Probably due to WASM support, but I did not dig deeper here. The "pro" though is it all happens on the client in the browser.

cryo 6y ago

I don't understand the anonymous claim. Since in WebRTC peers connect directly to each other they'll see the IP of the other peer and can determine their locations. Further there is the signalling server which may also see these connection details if it isn't end to end encrypted (I haven't checked the code). IMHO private might be a better word than anonymous here.

perenzo 6y ago
By using the term "anonymous" I wanted to say, that no user account is required. To hide one self's identity and network location I would expect the users to make use of browsers like Tor or using VPN. I don't know of any way to provide anonymity on web application level. If somebody knows more, please let me know.
- walterbell 6y ago
  How about the term "unauthenticated", which is well understood for HTTP requests?
  - perenzo 6y ago
    Well, IMO the definition of the word "anonymous" still fits how personal information is handled in Briefing: "Anonymity describes situations where the acting person's name is unknown" [1] And this is true regarding the Briefing service. [1] https://en.wikipedia.org/wiki/Anonymity https://en.wikipedia.org/wiki/Anonymity
    - inanutshellus 6y ago
      Heh, well you cherry-picked there. It goes on to say ". The important idea here is that a person be non-identifiable, unreachable, or untrackable." Regardless, it's Wikipedia, that definition ought to be fixed to say "identity" rather than "name".
    - walterbell 6y ago
      For online transactions, "name" has been generalized to PII (Personally Identifiable Information) from which name can often be derived. https://en.wikipedia.org/wiki/Personal_data https://en.wikipedia.org/wiki/Personal_data

waynenilsen 6y ago

How can we further decentralize this such that the entire app runs "without any servers"? Sadly it is so close but the realities of ipv4 and local subnets definitely makes this more difficult. I always thought that this is part of what webrtc was trying to solve

perenzo 6y ago
Well technically it is possible to avoid the signaling server, but you'll need some other channel to exchange the peers connection data. This is pretty inconvenient though. But a signal server is a rather light thing and easy to install on a location you trust: https://github.com/holtwick/briefing/tree/master/signal https://github.com/holtwick/briefing/tree/master/signal
- waynenilsen 6y ago
  > you'll need some other channel to exchange the peers connection data Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
  - saurik 6y ago
    If you can figure out how to share that hash, you may as well just share the offer.
    - waynenilsen 6y ago
      Yes, serialization is the issue. URL length is technically unlimited but in practice very long urls don't work out so well
  - perenzo 6y ago
    That's a good idea. I don't know the internals of IPFS, but the related https://libp2p.io/ https://libp2p.io/ looks promising. Follow up https://github.com/holtwick/briefing/issues/52 https://github.com/holtwick/briefing/issues/52
  - 6y ago

nannal 6y ago

"No camera or microphone has been found!" Using firefox 79, the usual prompts to allow permissions were not issued.

perenzo 6y ago
This is a Firefox Nightly release, correct? Current stable release is 77.0.1 Do you experience those issues with the stable release as well? If so I would like to ask you to file a bug here and add the OS version. Thanks for letting me know! https://github.com/holtwick/briefing/issues/new https://github.com/holtwick/briefing/issues/new

Angostura 6y ago

I just wanted to say that this looks very nice indeed.

seesawtron 6y ago

Looks really cool. One key element is that anyone can spy on your call if they guess the random name that you generate to create the link. I am curious what randomizations you have used to generate those? (perhaps you don't want to share to avoid exactly the spying, I can understand if you feel that way). Thanks for your insights. Cheers

perenzo 6y ago
Indeed, it is a rather simple algorithm [1] But you can set any name you like, either in the input field or directly in the URL. Protected rooms, where the participants need to know a common secret, are planned to be added to the project, see [2] [1] https://github.com/holtwick/briefing/blob/master/app/src/components/app-welcome.vue#L266 https://github.com/holtwick/briefing/blob/master/app/src/com... [2] https://github.com/holtwick/briefing/issues/1 https://github.com/holtwick/briefing/issues/1
- seesawtron 6y ago
  Yes password protection would definitely make this more usable. Have you also seen apprtc [0]? Could you point out if there are any differences you see there to Briefing? [0] https://appr.tc/ https://appr.tc/
  - perenzo 6y ago
    It is basically the same. Briefing is a bit more modern and has a few more features. As I mentioned in the help text on https://brie.fi/ng#help https://brie.fi/ng#help I started the project as a spin off of a virtual classroom project https://peer.school/ https://peer.school/ Sources https://github.com/holtwick/peer2school https://github.com/holtwick/peer2school
    - seesawtron 6y ago
      Cool. Also there is screen share option which is cool. I will pitch it to my peers and see if they catch on ;)

Andrew_nenakhov 6y ago

> Anonymous end-to-end encrypted End to end encryption implies that you have established an encrypted connection with a known participant and secured it by verifying your keys either off-band or via some CA provider to prevent MitM attack. If your chat partner is anonymous, and your only connection is via offered service, there is no way to determine if you are being spoofed. So anonymous end-to-end encryption is an oxymoron. I wish people would drop this e2ee fetish, insisting it everywhere, and would learn how it works, so they would be using the real thing where it makes sense, instead of opting for readily supplied snake oil.

deleted 6y ago
[deleted]
nybble41 6y ago
In this case authentication is provided through a shared secret (the room name). An arbitrary MitM wouldn't know the room name since the connection to the server is also encrypted. Unfortunately this isn't much of a secret, since the server also knows the room name, but it's a start. There is an open issue to add password-protected rooms which would fix that problem.
- pizzazzaro 6y ago
  From an user-centric standpoint, would not both secrets - roomname and password - be shared concurrently, potentially in the clear? This drastically limits the utility. Communication channels are only as secure as the least secure participant! Especially in shared-secret implementations. Every so often, Grandma wants to be cool too. And invite her friends.
- Andrew_nenakhov 6y ago
  In most e2ee threat models the biggest source of threat is the server that mediates the data exchange. Other threats are sufficiently thwarted with TLS, so ... ... these Briefing guys should better bring on these password protected rooms if they want to put this end to end encryption claim on their website.

sci_prog 6y ago

Do you maybe have instructions on how to set this up on my own server/domain? I've looked at the code but I'm not familiar with Vue. I have an online webgl multiplayer game where I create random room names to connect players. It would be amazing if I could use my domain and the same random room to enable video chat among the players.