41–50 of 151 posts
Love Jitsi but dont try to run this on AWS EC2 -- the network charges quickly add up. I had set Jitsi videobridge for my kid's friends and their friends -- the network charges quickly added up before I shut it down.
Jitsi has been doing great recently, and it's pretty amazing how many of my now-at-home-friends now reach for Jitsi by default (as opposed to Zoom, which used to be the case) after having been introduced to it just recently. I've never managed to "convert" so many people to something so easily :) However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the compan…
Jitsi has been doing great recently, and it's pretty amazing how many of my now-at-home-friends now reach for Jitsi by default (as opposed to Zoom, which used to be the case) after having been introduced to it just recently. I've never managed to "convert" so many people to something so easily :) However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the compan…
https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instance...
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
Jitsi is on a roll! By the way, Does anyone know the challenging part of e2e in video chats? Thinking out of intuition, it would be keys are exchanged during handshake and binary data is decoded on the clients? I'm just wondering how could Zoom miss it?
However, over time people who built WebRTC systems (like jitsi or zoom) realized that end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. Think about tens or thousands of users.
So the way they used WebRTC was changed. The mandatory end to end encryption was circumvented by connecting to a central server. This entity then could forward streams to as many people as you want. Also, most times people don't need a HD video of someone. A small thumbnail is enough, think of a screen filled with 10 thumbnails of your users. The downsampling of the video stream can happen on that central box. The downsampling was enabled with simulcast mode, but even then it still requires more bandwidth, while insertable streams will enable WebRTC applications to put a second layer of encryption over the encryption provided by the user angent. That second layer can then reach to the actual other end of the communication, as key management is exposed to the entities.
The sad twist in this story is that the desire to make the encryption very inflexible so that it's surely not circumvented made it impossible for people to amend it so that SFUs work... leading to people disabling it altogether.
I see a lot of blocky patterns in the encrypted video streams... isn't that indicative of encryption weaknesses?
We’ve kept the entire packet header unencrypted so the effect is more visible. The final implementation will just leave the minimum required bytes (1 or 2) of the header unencrypted.
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
If they hook into Matrix's E2EE key management stuff, then they'll benefit from the huge amount of work we've put into letting individual users transparently self-manage their keys - c.f. https://youtu.be/APVp-20ATLk?t=6355 for a demo from last Wednesday. This stuff is due to ship in Matrix/Riot in the coming week. That said, agreed that it's a massive and (up to now?) unsolved problem for how to get mainstream users…
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
At its most basic, encryption should be a thing that just happens, out of sight and mind of the user. Yes, that leaves vulnerability, but people generally don’t want to have to deal with it. Most of us are more interested in getting work done, rather than fiddling with the tools.
It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
You're downvoted but I agree. I'm a software dev and can't be assed about this. Even 2FA is a pain because I switch devices pretty regularly throughout the day. Managing my keys, no I have better things to do. Imagine a normie doing this? No chance.