Show HN: Briefing – Anonymous, secure, open source WebRTC group video chat(brie.fi)
brie.fi
Show HN: Briefing – Anonymous, secure, open source WebRTC group video chat
https://brie.fi/ng?ref=hn
53 comments
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.
Side note: WebRTC is disable on TorBrowser[0], but you can use a browser with WebRTC enabled (Vanilla Firefox and others) on the Tor network inside Tails OS[1].
[0] https://tor.stackexchange.com/questions/876/does-tor-work-wi...
[1] https://tails.boum.org/
[0] https://tor.stackexchange.com/questions/876/does-tor-work-wi...
[1] https://tails.boum.org/
Thanks for the clarification, imo and as you already see in this discussion different people understand different meanings into the word.
Maybe it's safer to use a clear description rather than "anonymous". The "no user account is required" is a good statement which can be hardly misunderstood.
There are many people out there (including me) which think anonymous means nobody can trace or identify me. Anonymity even with Tor is very hard to achieve on the Internet, I would even say it's impossible.
On my software I'm using the word "private" instead of anonymous to describe such communication; which was inspired by Tor tech talks. I've written about it here https://cryonet.io/technology.html
Maybe it's safer to use a clear description rather than "anonymous". The "no user account is required" is a good statement which can be hardly misunderstood.
There are many people out there (including me) which think anonymous means nobody can trace or identify me. Anonymity even with Tor is very hard to achieve on the Internet, I would even say it's impossible.
On my software I'm using the word "private" instead of anonymous to describe such communication; which was inspired by Tor tech talks. I've written about it here https://cryonet.io/technology.html
Ok, I get the point. I opened a ticket to use a clearer wording: https://github.com/holtwick/briefing/issues/51 Thanks clarifying the ambiguity.
How about the term "unauthenticated", which is well understood for HTTP requests?
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
[1] https://en.wikipedia.org/wiki/Anonymity
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".
Regardless, it's Wikipedia, that definition ought to be fixed to say "identity" rather than "name".
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
An anonymous user is precisely the one who hasn't provided authentication credentials
> Anonymous User is any user who accesses network resources without providing a username or password.
Se anonymous is correct in this context
> Anonymous User is any user who accesses network resources without providing a username or password.
Se anonymous is correct in this context
You can create a user account with a random name almost every chat/video application.
A more descriptive term would be "account-free".
A more descriptive term would be "account-free".
I think OP meant Anonymous as it was used when FTP was still a thing where it simply meant "without being authenticated as a named" user.
> 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.
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]
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.
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.
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?
He means peers directly connect to each other, so there are no data packets that the server could man in the middle.
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.
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.
WebRTC is encrypted.
Correct. Scroll up the page to learn about the details: https://brie.fi/ng#help Also see 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.
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.
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/
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/
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/
[2] https://github.com/holtwick/briefing/issues/1
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/
[2] https://github.com/holtwick/briefing/issues/1
> This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge
What this means is that the packets are encrypted between you and the video bridge and the packets travel unencrypted within the videobridge infrastructure, but at no point does the outside world see the unencrypted stream. Talking to the Jitsi video bridge is just a regular WebRTC session as far as clients are concerned (so any DTLS encryption WebRTC has, the Jitsi call has), I know this because before they had a decent SDK I had to manually wedge my WebRTC calls into it.
If you're looking to add e2ee to your project, you're pretty much left to choose between Olm and Signal Protocol, which are quite similar, but libsignal is GPLv3 while libolm is Apache 2.0.
I've used Olm more intensively over the last two years. While it works, it's great, when it randomly wedges a session for no apparent reason you feel like throwing it out the window.
What this means is that the packets are encrypted between you and the video bridge and the packets travel unencrypted within the videobridge infrastructure, but at no point does the outside world see the unencrypted stream. Talking to the Jitsi video bridge is just a regular WebRTC session as far as clients are concerned (so any DTLS encryption WebRTC has, the Jitsi call has), I know this because before they had a decent SDK I had to manually wedge my WebRTC calls into it.
If you're looking to add e2ee to your project, you're pretty much left to choose between Olm and Signal Protocol, which are quite similar, but libsignal is GPLv3 while libolm is Apache 2.0.
I've used Olm more intensively over the last two years. While it works, it's great, when it randomly wedges a session for no apparent reason you feel like throwing it out the window.
Thanks for the feedback, I'll take Olm/Matrix and Signal into consideration, although I believe for the described purpose of Briefing the current implementation is sufficient and secure.
Not sure if this is possible with the current WebRTC api, but if you could expose the dtls public keys for the current and remote sessions somewhere, that would help to reduce the risk of MITM attacks. Users would at least have the option of manually verifying keys through another channel.
edit: it looks like you can find info in the RTCSessionDescription.sdp property. The remoteDescription and localDescription should each have key fingerprints in lines with "a=fingerprint:..."
edit: it looks like you can find info in the RTCSessionDescription.sdp property. The remoteDescription and localDescription should each have key fingerprints in lines with "a=fingerprint:..."
Jitsi has end-to-end encryption now (used it a few days ago).
It behaves quite hilariously when you switch to e2e encryption after a normal connection - the other party gets random noise for a little while.
It behaves quite hilariously when you switch to e2e encryption after a normal connection - the other party gets random noise for a little while.
But it only works with Blink/Chrome right now because it depends on Insertable Streams:
https://jitsi.org/blog/e2ee/
https://www.chromestatus.com/feature/6321945865879552
Hopefully this will be implemented in other browsers as well soon.
https://jitsi.org/blog/e2ee/
https://www.chromestatus.com/feature/6321945865879552
Hopefully this will be implemented in other browsers as well soon.
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
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/com...
[2] https://github.com/holtwick/briefing/issues/1
[1] https://github.com/holtwick/briefing/blob/master/app/src/com...
[2] https://github.com/holtwick/briefing/issues/1
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/
Have you also seen apprtc [0]? Could you point out if there are any differences you see there to Briefing?
[0] https://appr.tc/
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 I started the project as a spin off of a virtual classroom project https://peer.school/ Sources https://github.com/holtwick/peer2school
Cool. Also there is screen share option which is cool. I will pitch it to my peers and see if they catch on ;)
So it's just javascript Math.random.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.
Also, even if you had a CSPRNG there, your URL format seems to encode only about 27 bits of data.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.
Also, even if you had a CSPRNG there, your URL format seems to encode only about 27 bits of data.
I just wanted to say that this looks very nice indeed.
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,
That's correct, I use 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.
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.
Looks useful thank you for sharing.
The website that provides the web app and mediates the communication stores as (few -> little) data as possible
The website that provides the web app and mediates the communication stores as (few -> little) data as possible
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.
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
Bootstrapping a distributed swarm is always a tricky proposition. Bittorrent clients use a few endpoints to bootstrap their dht, and then upgrade to p2p after that. I think that's a good compromise, especially if you can have a number of highly-available options to cycle through.
With Squawk[1] we do the initial signaling through our own servers via websocket, and a key registry for authing peers to each other, but after that, all the fun stuff happens p2p. The protocol level data (who's speaking, which group they're speaking to, whether they are muted, etc) flows entirely p2p over data channels, and since we're audio only we made the decision not to use SFUs but rather do a full mesh architecture (massive PITA but it does scale well to 20-30 peers) with geo-optimized TURN servers when people need to punch through NAT (but TURN does not terminate ssl).
[1] https://www.squawk.to
With Squawk[1] we do the initial signaling through our own servers via websocket, and a key registry for authing peers to each other, but after that, all the fun stuff happens p2p. The protocol level data (who's speaking, which group they're speaking to, whether they are muted, etc) flows entirely p2p over data channels, and since we're audio only we made the decision not to use SFUs but rather do a full mesh architecture (massive PITA but it does scale well to 20-30 peers) with geo-optimized TURN servers when people need to punch through NAT (but TURN does not terminate ssl).
[1] https://www.squawk.to
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
> 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?
Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
I did a POC of this over a year ago [0]. Now, with better libp2p-js library, it is surely much easier/better nowadays.
0 - https://github.com/cretz/webrtc-ipfs-signaling
0 - https://github.com/cretz/webrtc-ipfs-signaling
If you can figure out how to share that hash, you may as well just share the offer.
Yes, serialization is the issue. URL length is technically unlimited but in practice very long urls don't work out so well
That's a good idea. I don't know the internals of IPFS, but the related https://libp2p.io/ looks promising. Follow up https://github.com/holtwick/briefing/issues/52
Thank you for making both the client and server sides of this video chat application open source.
The only missing piece it seems is the STUN/TURN server. Would you have a plan to also release it?
The only missing piece it seems is the STUN/TURN server. Would you have a plan to also release it?
I use coturn. Find installation details here https://github.com/holtwick/briefing/blob/master/app/INSTALL...
Oh, I didn't see that. Thanks so much for sharing!
"No camera or microphone has been found!"
Using firefox 79, the usual prompts to allow permissions were not issued.
Using firefox 79, the usual prompts to allow permissions were not issued.
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
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.