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.
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
Regardless, it's Wikipedia, that definition ought to be fixed to say "identity" rather than "name".
> Anonymous User is any user who accesses network resources without providing a username or password.
Se anonymous is correct in this context
A more descriptive term would be "account-free".
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 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 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.
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.
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.
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 
I would very much appreciate your help on the project to eliminate those concerns.
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.
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:..."
It behaves quite hilariously when you switch to e2e encryption after a normal connection - the other party gets random noise for a little while.
Hopefully this will be implemented in other browsers as well soon.
Have you also seen apprtc ? Could you point out if there are any differences you see there to Briefing?
> 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.
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.
The website that provides the web app and mediates the communication stores as (few -> little) data as possible
With Squawk 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).
Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
0 - https://github.com/cretz/webrtc-ipfs-signaling
The only missing piece it seems is the STUN/TURN server. Would you have a plan to also release it?
Using firefox 79, the usual prompts to allow permissions were not issued.