Show HN: We made metadata-secure video conferencing that's easy to use | Hacker News Reader

Show HN: We made metadata-secure video conferencing that's easy to use

booth.video

41 pointsbarathr17 comments

Looks interesting, but it'snot clear on how they protect metadata from the STUN/TURN part of webrtc. Potentially its use of the Multi-Party Relay that insulates peers from those services knowing anything about the peer. Some interesting points were from the article:

- Booth leverages the same INVISV Multi-Party Relay (MPR) architecture that we also use to provide Internet privacy for Relay users. Using an MPR, users’ network identities (IP addresses) are masked from the cloud server that they connect to. https://invisv.com/articles/relay

- Booth is designed to use meeting “booths”, where the booth link is randomized for each meeting. Likewise, Booth users don’t need to reveal their names to the server. ... (Note that Booth relies on browser support for Insertable Streams/Encoded Transform, which is limited to Chrome-based browsers at this time.) In addition to this end-to-end encryption, Booth also employs additional outer layers of encryption as described in the MPR architecture.

STUN/TURN took a bit of work to deal with -- we have a bit more on it here, at the end of the blog post:

https://invisv.com/articles/booth

One key part is that the video conferencing server thinks its IP is the first hop of the MPR, and the client also doesn't give ICE candidates that include its IP (we filter the candidate list).

How do you send data to the client without their IP address?

The data goes through the Multi-Party Relay. (Similar to Apple's iCloud Private Relay, if you're familiar with that.)

Looks great! If they want to compete with zoom, the should make the free tier a bit better for individual use.

Maybe add a 240 minutes for up to 3 people option? That covers the “get a beer on zoom” use case, which is good for word of mouth.

We actually haven't yet limited the free tier :) -- we figure until our servers are overloaded there's no need to actually impose limits. So yes, feel free to use for now, and probably for a while until server load becomes an issue.

>Default End-to-end Encryption

So, the first question to ask here is:

How can a user be sure they are actually talking to who they think they are talking to? How can they be sure that they are not instead connected to a server somewhere that is simply forwarding the data between users while recording it? Who do you have to trust?

An example of the sort of thing I mean:

Signal Messenger verifies your phone number through the phone system for default identity verification. So you trust:

* The people that run the Signal servers

* Twilio (the ones that provide the SMS verification)

* The phone company

Signal also has the option to do direct verification by comparing key fingerprints (they call them Safety Numbers). Then you are truly end to end and only have to trust your correspondent (and yourself I suppose).

The good news with this is that we've built our implementation on top of LiveKit, and you can look at the source, so you can see the E2EE in the browser. The encryption key for video/audio is only known to the client, so it's only known to whomever you share it with (the other participants). You can also look at your browser's WebRTC internals to see who it's talking with. Eventually our plan is to support TEE-based attestation of the Multi-Party Relay hops as well.

Why not implement the tried and true fingerprint verification? Quite easy to do when you're having synchronous, lively video/audio conversations.

That's what we'll be doing for a well-defined group of users -- that is, with stable, long-term cryptographic identities. It's not as useful for conversations where participants join with a link.

Doesnt seem to support Safari on iOS, does WebKit not support WebRTC on mobile properly?

Unfortunately, that's the case: Safari and Firefox haven't yet implemented WebRTC Insertable Streams, which we use for end-to-end encryption. And on iOS even Chrome is not really based on chromium (due to Apple's restrictions). We know support for the latest WebRTC standards is on the roadmap for Firefox (not sure about Safari).

So for the time being we support chromium based browsers (Chrome, Vivaldi, Brave, Edge, etc.).

I think you need to work on iOS support, or this will not take off.

P.S. Beautiful project for a problem that definitely needs solving.

Thanks! We're thinking through the right architecture; it's a question of whether WebKit will get Insertable Streams soon enough, or if we'll need to create a custom client. Our preference is for users to not need a custom client, because that's one more piece of software they need to keep up to date.

> Browser not supported. Please use a chromium based browser instead.

I see this in Firefox.

That's right -- unfortunately Firefox doesn't support WebRTC Insertable Streams, which we use for end-to-end encryption. It's on their roadmap but not there yet. (And I am primarily a Firefox user, so this is a disappointment for me as well.) Any chromium-based browser, such as Chrome, Vivaldi, Brave, Edge, etc. will work.

Thanks for the clarification!

Reply on news.ycombinator.com