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.
[0] https://tor.stackexchange.com/questions/876/does-tor-work-wi...
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
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.
[1] https://github.com/holtwick/briefing/blob/master/app/src/com...
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://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.
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[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).
Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
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.
