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]
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
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
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.
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.
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.
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.
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.
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.
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.
Introducing better compression of images and animations would be another small step fighting climate change. Less data, less transfer, less energy consumption!