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.
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).
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.).
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.
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.
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.
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.
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.
17 comments
[ 5.1 ms ] story [ 44.0 ms ] thread- 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.
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).
So for the time being we support chromium based browsers (Chrome, Vivaldi, Brave, Edge, etc.).
P.S. Beautiful project for a problem that definitely needs solving.
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.
I see this in Firefox.
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).