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

https://brie.fi/ng?ref=hn

by holtwick • 6 years ago

203 51 6 years ago

brie.fi

totetsu• 6 years 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• 6 years 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• 6 years ago

He means peers directly connect to each other, so there are no data packets that the server could man in the middle.

Beldin• 6 years 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.

tpetry• 6 years 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,

perenzo14• 6 years ago

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.

cryo2• 6 years 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.

perenzo14• 6 years 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.

walterbell2• 6 years ago

How about the term "unauthenticated", which is well understood for HTTP requests?

seesawtron4• 6 years ago

You can create a user account with a random name almost every chat/video application.

A more descriptive term would be "account-free".

marci• 6 years ago

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/

cryo2• 6 years ago

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

DavidPP• 6 years ago

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.

nannal• 6 years ago

"No camera or microphone has been found!"

Using firefox 79, the usual prompts to allow permissions were not issued.

perenzo14• 6 years 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

waynenilsen3• 6 years 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

perenzo14• 6 years 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

waynenilsen3• 6 years 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?

lioeters2• 6 years ago

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?

zumachase• 6 years ago

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

Angostura• 6 years ago

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

seesawtron4• 6 years 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

perenzo14• 6 years 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/com...

[2] https://github.com/holtwick/briefing/issues/1

seesawtron4• 6 years 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/

yencabulator• 6 years ago

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.

Andrew_nenakhov2• 6 years 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.

nybble41• 6 years 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.

Andrew_nenakhov2• 6 years 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• 6 years 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.

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

Related Stories