Live data from Hacker News

Proof of concept: end-to-end encryption in Jitsi Meet

jitsi.org

21–30 of 151 posts

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#21

Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping e…

Thanks for the feedback. So the reason for these choices of primitives when we wrote libolm was to keep close to libsignalprotocol (or libaxolotl as it was then), to try to keep the door open to interop with Signal at some level. The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-.…

I appreciate the context. It's probably wise to abandon Signal interop.

My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval.

> What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ?

Confusion between ciphertext on line 85 and output on line 89 made me have to reread the function twice to figure out what was going on.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#22

Earlier quoted context omitted.

Thanks for the feedback. So the reason for these choices of primitives when we wrote libolm was to keep close to libsignalprotocol (or libaxolotl as it was then), to try to keep the door open to interop with Signal at some level. The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-.…

Are you planning to support IETF MLS, https://datatracker.ietf.org/wg/mls/about/ ?

potentially; we're experimenting with a decentralised MLS impl currently.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#23

Earlier quoted context omitted.

Are you planning to support IETF MLS, https://datatracker.ietf.org/wg/mls/about/ ?

potentially; we're experimenting with a decentralised MLS impl currently.

That's very cool to hear!

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#24

Earlier quoted context omitted.

Thanks for the feedback. So the reason for these choices of primitives when we wrote libolm was to keep close to libsignalprotocol (or libaxolotl as it was then), to try to keep the door open to interop with Signal at some level. The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-.…

I appreciate the context. It's probably wise to abandon Signal interop. My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval. > What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ? Confusion between ciphertext on line 85 and ou…

> Moxie isn't ever going to acquiesce on the points he's stubborn about

Yup, indeed. https://signal.org/blog/the-ecosystem-is-moving/ was written after I mailed him to ask if they'd consider interop. (https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom was our overdue response)

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#25
post #8

Jitsi was the one Jabber client I used a few years back that I liked. I didn't find as many people on Jabber back then as I've seen elsewhere however. I believe you could use OTR alongside it, so you don't even need to trust them, just their implementation / version of OTR (a few more layers to consider I suppose).

I don’t think this is anything to do with the legacy jitsi xmpp/sip client, but the “jitsi meet” video conferencing app.

Oh it's been too long if that one's irrelevant.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#27
post #11

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…

[deleted]

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#28

Earlier quoted context omitted.

I appreciate the context. It's probably wise to abandon Signal interop. My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval. > What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ? Confusion between ciphertext on line 85 and ou…

> Moxie isn't ever going to acquiesce on the points he's stubborn about Yup, indeed. https://signal.org/blog/the-ecosystem-is-moving/ was written after I mailed him to ask if they'd consider interop. ( https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom was our overdue response)

If you're open to changing the protocol, might I also recommend XChaCha20-Poly1305? :)

https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03

It's fast and constant-time even on mobile devices (where AES is often variable-time or slow due to a lack of AES-NI).

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#29
I just learned Jitsi is supported in part by 8x8. That gives me concern and I'll have to research the ties there before switiching ti Jitsi. I'm making this a top level comment given its length, but I wrote this after seeing Vinnl's question on 8x8.

I was an 8x8 customer for about 10 years as a small/medium business. I would never buy from them again. I now use Zoom, but am considering switching given the recent privacy revelations.

Here was my 8x8 customer journey. Stick around - at the end I highlight their shifty auto-renewal contracting practices and dark patterns to force you to stay.

     2011-2015: 
Startup phase. Was great to get a VOIP phone at this time! Still needed desktop phones from Polycom for the system to work well. Zero online meetings as far as I knew. Acceptable product, was happy enough.

     Around 2015 or so through about 2019: 
Newer versions of iOS, that allowed for better phone integration, began to pop up. 8x8 was viable as a mobile-only VOIP provider, but lacked quality features for a growing business: - The ability to retrieve recorded calls from a Mac required you log in with a certain version of Safari that had Flash Enabled. Then, you could only download X MB of calls at a time. All of this had to be done manually. There was no API for reporting, jus CSV exports. This made calculating total customer service costs for our business a massive pain. - If you edited your extensions online, ALL OF YOUR CALL RECORDINGS SINCE THE OPENING OF YOUR ACCOUNT ARE DELETED. We found this out the hard way, and there was no warning that adjusting extensions would have this impact.

     2019 Q1 thru Q3 
I wanted to switch to Zoom, because the 8x8 apps had poor usability from our experience, specifically as a remote-only setup. I did not trust that a video product from 8x8 would be acceptable, and I enjoyed using Zoom with other organizations I am involved with.

Porting phone numbers to Zoom was really easy. It requires about 1-2 weeks of paperwork and processing time (no matter who you are porting numbers with I think this is the default). However - 8x8 tried to block the transfer for about 20% of our numbers, saying that the information we provided was incorrect. After days of back and forth, all the while our numbers were unavailable for use and causing operational problems, the case was escalated and resolved, simply because a new person read the original forms we submitted and processed it correctly.

     On the 8x8 contract & account management dark patterns: 
8x8 did not have a copy of the PDF of our agreement. I did have a copy. The contract was for 3 years with 12 month auto-renewal clauses.

Multiple times in 2018 I requested my account manager offer new pricing, as our rates had doubled from $25/number to $50/number in just 1 year. The cost was out of control. They never did offer pricing, but continually played the Car Salesman move of "Let me see what I can get my finance department to approve", come back with a meager 5% discount, rinse, repeat... The account manager would passively threaten that they will take my account to month to month, "but the pricing controls will no longer be in place and your rates could rise". Big deal, I thought, my rates are already skyrocketing!

Multiple times in 2016-2018 I wrote to them asking if I had an auto-renewal. They would not answer this question over email, but instead forced me to call in.

When I called in ("...to a recorded line, for quality assurance purposes..."), they would tell me I did have an auto renewal in August each year for 12 months. I would tell them over the phone to mark that I wish to cancel my auto renewal and continue on a month to month basis. I would follow up with my 8x8 Account Manager that I was told over the phone by the 8x8 Billing Representative that my company did not have an auto renewal. My account manager never acknowledge these messages.

    2019 Q3: 
I submitted a cancellation notice to 8x8. They wanted to charge me an Early Termination penalty of more than half the year, claiming I was in a 1 year auto renewal. It took me over a dozen phone calls for more than an hour each to get this resolved.

I've come to expect garbage contract patterns from legacy companies. However... THE WORST PART ABOUT THIS in my opinion was that calls 1 through 11 to 8x8 customer support and billing to resolve this were not successful, in my opinion, because I was being very nice and understanding to the support person on the other line. ONLY when I started threatening legal action, "I do not care what the script is telling you to say, I must talk to a manager", etc, did I get someone to waive these cancellation fees and allow me to transfer my numbers.

I have done customer service oriented work, I understand the drain it can have on people. I try to be overly nice to anyone I have to call into because so many people are abusive to the support agents trying to assist them. But at the end of the day, wether its Apple or 8x8, the only success I've had at getting what I need in situations where the company is clearly playing hide-the-ball, is to be threatening to the minimum wage worker on the other end of the line.

And that is my take away - you can tell a lot about a company from how they arm (or bind & toss overboard) their front-line support agents to deal with a terminating customer contract.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#30
post #14

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…

I'm not sure if that's such an unsolvable problem. For example, Firefox Send [1] also provides E2E encryption, but that's practically transparent to the user. The key is added as a hash to the URL, which the browser never sends to the server. The user just has to copy the sharing URL (which they do anyway) do obtain and share the key. Jitsi might have an additional challenge in that their URLs are often human-readabl…

Yeah, it shouldn't be unsolvable; my key thought is that it's actually the hard part of the story now (encryption client-side is pretty well-understood) and is under-solved. Even still, having more options in the world is better than having fewer, so I'm excited about this demo.
Post reply on HN