
Show HN: Briefing – Anonymous, secure, open source WebRTC group video chat - holtwick
https://brie.fi/ng?ref=hn
======
cryo
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
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
How about the term "unauthenticated", which is well understood for HTTP
requests?

~~~
perenzo
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
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".

------
Andrew_nenakhov
_> 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
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_nenakhov
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.

------
schoen
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
He means peers directly connect to each other, so there are no data packets
that the server could man in the middle.

~~~
Beldin
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
WebRTC is encrypted.

~~~
perenzo
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
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
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)

~~~
clawoo
> 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.

~~~
perenzo
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.

~~~
a1a1a1a1a1a1
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:..."

------
seesawtron
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
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...](https://github.com/holtwick/briefing/blob/master/app/src/components/app-
welcome.vue#L266)

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

~~~
seesawtron
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
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
Cool. Also there is screen share option which is cool. I will pitch it to my
peers and see if they catch on ;)

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

------
tpetry
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
That's correct, I use [https://github.com/tensorflow/tfjs-
models/tree/master/body-p...](https://github.com/tensorflow/tfjs-
models/tree/master/body-pix#bodypixdrawbokeheffect)

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.

------
totetsu
Looks useful thank you for sharing.

The website that provides the web app and mediates the communication stores as
( _few_ -> _little_ ) data as possible

------
sci_prog
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.

------
waynenilsen
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
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
> 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
If you can figure out how to share that hash, you may as well just share the
offer.

~~~
waynenilsen
Yes, serialization is the issue. URL length is technically unlimited but in
practice very long urls don't work out so well

------
nannal
"No camera or microphone has been found!"

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

~~~
perenzo
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)

