
Proof of concept: end-to-end encryption in Jitsi Meet - jrepinc
https://jitsi.org/news/e2ee/
======
shadowgovt
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 MITM on encryption?
Especially since if you have their keys you already could.

Still, very cool technical demo, even if the odds of it displacing something
like Zoom are near nil.

~~~
Arathorn
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](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 to manage their keys sensibly. Keybase could have
gone there, but ended up being poweruser-only. It'll be interesting to see if
we've solved it in Riot.

~~~
jadbox
Can you explain a bit about "Matrix's E2EE key management stuff" and how it
"letting individual users transparently self-manage their keys"? Is there docs
on it?

~~~
Arathorn
So E2EE key management has been a (very) long time coming in Matrix. Firstly:
E2EE is pretty useless if you don't verify the identity of keys, as you could
be just talking to a MITM (e.g. a malicious server admin could add a 'ghost'
device onto your account in order to sniff the messages people are sending
you).

Originally (in 2016) we let users verify the devices they're talking to by
checking their Curve25519 public keys out of band - e.g. "s5jZ K5a/ 4iAN If7K
L0PL XNNG h/4G 901H +dB6 YMB9 1H4". This is obviously completely unusable, and
precisely the sort of terrible UX which made the great-grand-parent say
"individual users don't want to be arsed to self-manage their encryption keys;
You can't solve the UX on that".

Then, we improved things a bit (in Feb 2019) by adding the ability to verify
devices by comparing a list of 7 emojis out of band - you calculate a shared
secret via ECDH between the devices. This is specced in
[https://github.com/matrix-org/matrix-
doc/issues/1267](https://github.com/matrix-org/matrix-doc/issues/1267) and
analysed in
[https://www.uhoreg.ca/blog/20190514-1146](https://www.uhoreg.ca/blog/20190514-1146).
This solved the problem of comparing ugly public keys and made verification
actually fun (imagine people yelling 7 emoji at each other across a room, or
over VoIP etc, to verify identity), but meant you still had to verify each new
device manually, which gets very tedious very quickly.

We have finally fixed this over the last N months, which is what I was talking
referring to in the previous post.

Firstly, when you sign into a new device, as part of login you have to verify
that device's identity with an existing one (or enter a recovery
code/passphrase) - a bit like 2FA. Then, _every user who has verified you in
the past will automatically trust this new device_ \- you have effectively
vouched for its veracity yourself. We call this cross-signing, and it's
specced at [https://github.com/matrix-org/matrix-
doc/pull/1756](https://github.com/matrix-org/matrix-doc/pull/1756).

Secondarily, we've added QR-code scan based verification
([https://github.com/matrix-org/matrix-
doc/pull/1544](https://github.com/matrix-org/matrix-doc/pull/1544)) - so the
actual login process here ends up feeling similar to WhatsApp Web: the user
just scans a QR code on their new device, and hey presto: all other users who
have ever verified your identity in the past will magically trust your new
device.

We're hoping that between QR/emoji-based verification and cross-signing we've
ended up with a UX which will let non-technical users transparently manage
their keys without really realising it (as it will boil down to "scan this
code to log in" and "scan this code to check you're not being intercepted").

The expectation is to turn this on by default in Riot and launch it this
Thursday (fingers crossed). And in future, Jitsi could use the same
identity/key-management model to ensure that you're actually talking to the
people you think you're talking to in their shiny new E2EE conferences.

~~~
xiphias2
,, E2EE is pretty useless if you don't verify the identity of keys, as you
could be just talking to a MITM (e.g. a malicious server admin could add a
'ghost' device onto your account in order to sniff the messages people are
sending you).''

This is just not true. The amount of passive listening is so much more than
the amount of MITM, as most middle men don't want people to know that they are
listening. It's just too easy to catch them if they do it on a massive scale,
as long as just 0.1% of users verify the E2E keys. This way the remaining
99.9% gets a part of the security benefit as well.

~~~
upofadown
Perhaps it would be more illuminating to say that E2EE is mostly _pointless_
if you don't verify keys. Then all you have to do is encrypt on the network
links to get the same level of security for a lot of these things that claim
E2EE as they have the power to do trivial MITM.

~~~
xiphias2
The point is that instead of requiring end users to verify public keys, it's
better UX to give them the ability if they want, but not require. I remember
an email standard that sent public keys inside the emails, and the replies are
encrypted with that public key.

Sure, MITM is possible, but it's easy to detect, at the same time the UX is
easy to scale to billions of people.

~~~
upofadown
That's autocrypt. It is awesome and should be default on all email clients. As
part of the autocrypt standard MITM is not detectable as that would just
provide users with information they could do nothing about. Autocrypt is fine
just as long as the users are made to understand that the privacy protection
is a lot less than the protection they would get from a PGP key they actually
got from someone directly. No UX in the world can overcome that
incontrovertible fact.

------
PureParadigm
There's a lot of discussion here about key exchange, and how you need to trust
whatever service is managing the keys. From the demo, it looks like the key is
basically a password. If you can share the password out-of-band through
another secure channel (perhaps post it in a Signal chat or something), then
your meeting should be secure. It can even be included as part of the link.

But then doesn't the Jitsi web server have to access password when you enter
it on their website/have it in the link? Nope! It looks like they're putting
the password in an anchor fragment in the URL, which is not sent to the web
server [1]. So all encryption/decryption is being done client side (and is
therefore real end-to-end encryption).

Yes, it's possible the web server is sending you evil JavaScript that is
extracting your password anyway, but at least that's something you can in
principle check. For all end-to-end encryption to work, you have to know your
client is not compromised.

[1] [https://stackoverflow.com/a/3081862](https://stackoverflow.com/a/3081862)

~~~
dcposch
This goes straight to one of the biggest holes in the web platform: there is
no mechanism for code signing or release tracking.

The web already has the world's most widely used public key infrastructure.
When I go to amazon.com, I can be confident that my browser is talking to a
service operated by Amazon, with nobody spying on or modifying messages in
flight.

However, I have zero guarantees regarding the HTML/CSS/JS that service
returns. It can return code modified for me specifically, different from what
any other user of that app is running. For traditional server side rendered
web apps, this is normal and expected. SPAs often return identical app
resources for every user, and all user specific data is later transmitted via
API calls... but nothing in the web enforces this.

For decentralized or end-to-end encrypted apps, this is very bad. Most
Ethereum apps today, for example, are used primarily via Metamask browser
extension. Nothing stops an operator of such an app from just serving a
different, malicious version to one specific user, based eg on IP. Such a
compromise would be very hard to prove.

Similarly, Jitsi might like to give users confidence that they are running the
same code as everyone else, and that the code is logged, versioned, and open
to security analysis.

In principle, an approach similar to Certificate Transparency could provide
this kind of assurance.

For this to really work well, they would also have to practice good dependency
hygiene and ship unminified bundles.

\--

This is an important web primitive that's currently missing. Do any browsers
have a solution somewhere in the pipeline?

~~~
PureParadigm
For code signing to work you need to trust whoever is signing the code. As you
mentioned, with HTTPS, all the contents are already signed by the web server.
If Jitsi published a native app and signed it, would that even help you? You
still have to trust them because they could have signed anything.

Maybe you mean to compare it to a copy that has already been audited by
someone else? Then you might as well use the auditor's web server to get the
client (and you can do this because Jitsi can be self-hosted). So I think it
just comes down to connecting to web servers run by people you trust, since
HTTPS already takes care of integrity checking.

~~~
michaelt
If you are running a project like Tor Browser, that needs the highest security
going, you would want:

1\. Signing with an offline key, so an attacker can't make a release just by
hacking the web server, and the key doesn't end up on however many hundred CDN
web servers around the world.

2\. Clear boundaries between releases, and a slow enough release schedule that
third-party auditors can keep up.

3\. Non-repudiation, so users know everyone else saw the same version they
saw.

4\. Reproducible builds from code in a public repo, so third-party auditors
know what was released is what they reviewed.

5\. An update process that verifies 1-3 before applying an update.

These requirements are fundamentally incompatible with webapps - where a no-
questions-asked software update is only a press of F5 away, by design.

~~~
dane-pgp
> These requirements are fundamentally incompatible with webapps - where a no-
> questions-asked software update is only a press of F5 away, by design.

If by "webapps" you mean "applications that run inside a web browser" then I
disagree, since it is possible to pin a specific (presumably third-party
audited) version of a webapp by using a static local bookmarklet or saved
file. See my other comment [1].

You're right, though, that this is not the typical user experience for a web
app, and you might reasonably believe that all webapps should be visibly
associated with a domain on the internet.

Personally I think it is acceptable if a high security webapp requires a
slightly less convenient UX compared to normal webapps. Nevertheless, it
should still be quicker and safer to "install" a bookmarklet than install a
native application like the Tor Browser.

[1]
[https://news.ycombinator.com/item?id=22862376](https://news.ycombinator.com/item?id=22862376)

------
Arathorn
This is insanely cool - insertable webrtc streams only just landed in canary
([https://www.chromestatus.com/feature/6321945865879552](https://www.chromestatus.com/feature/6321945865879552)).
Also very cool they’re looking to use Matrix’s libolm Double Ratchet
implementation for key exchange, which hopefully will make it easier to
integrate Matrix’s e2ee with Jitsi’s in future :)

------
Vinnl
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 company behind it [2]? They supposedly
support Jitsi primarily to 1) get contributions that also make their product
better and 2) to advertise their product. I'm somewhat worried about whether 2
is working, and hence whether Jitsi will continue to receive their support.

(I'm not affiliated or anything btw, just a happy Jitsi user.)

[1] [https://www.8x8.com/](https://www.8x8.com/)

[2] [https://jitsi.org/user-faq/#heading8](https://jitsi.org/user-
faq/#heading8)

~~~
shravj
Although I'm not technically a 8x8 customer, I do use 8x8 Video Meetings which
is powered by Jitsi Meet. 8x8 Video Meetings seems to be a completely free and
separate product from the rest of 8x8's conferencing solutions and does not
require any sort of existing or new 8x8 subscription to use. From what I can
tell, it just seems to be a Jitsi Meet instance running on 8x8 infrastructure
with 8x8 branding tied in. See here: [https://www.8x8.com/products/video-
conferencing](https://www.8x8.com/products/video-conferencing)

------
christefano
Sad to see this is dependent on an extension to WebRTC that’s (currently)
Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this
will be supported by any other browsers.

~~~
elric
Seems like Jitsi relies on Chrom(e|ium) for a lot of things. Desktop sharing?
Chrome plugin. Desktop client? Chromium/Electron. I tried setting up an
instance for my company to replace zoom, but I can't go around demand that
people install any particular browser.

~~~
saghul
That is not really true.

Yes, our Firefox support has not been great, but we are working on making it
better: [https://github.com/jitsi/jitsi-
meet/issues/4758](https://github.com/jitsi/jitsi-meet/issues/4758)

> Desktop sharing? Chrome plugin.

This was a browser limiation, which is no longer needed since about 2 years
ago.

> Desktop client? Chromium/Electron.

You need to ue it! Use the browser, or the mobile apps.

~~~
elric
Jitsi Meet even shows a popup saying Firefox is not supported, and the only
fully supported browsers are Chrome and Chromium.

You're right that screen sharing does seem to work in Firefox! Thanks for
pointing that out. It looks like FF on my Linux box is blocking it, but I
guess that's a permission issue I need to fix locally.

------
mbochenek
I love the fact that it's open source, and well documented. I am currently
hosting my own instance at
[https://jitsi.mastodo.ch/](https://jitsi.mastodo.ch/) and I plan to offer it
as a free alternative to zoom, citrix, etc.

------
manishsharan
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.

~~~
capableweb
Try a host that doesn't charge for bandwidth. Dedicated servers at Hetzner
and/or OVH doesn't charge this imaginary fee so you can sleep well and just
pay a static sum each month.

~~~
sigwinch28
Precisely. Hetzner can provide a dedicated server with an Intel Core i7-2600,
16 GB RAM, and 2x3TB spinning disks for 29,00 €/month before tax with
unlimited traffic via their server auction site for orphaned servers [0].

Other Hetzner and many OVH offerings have traffic caps, but these are in the
region of ~10TB/month.

[0]: [https://www.hetzner.com/sb/](https://www.hetzner.com/sb/)

------
crazygringo
I'm actually really curious as to whether _verifiable_ E2EE is possible in
normal business videoconferencing -- if someone here can enlighten me I'd
really appreciate it.

It seems clear that there has to be a single key, rather than separate keys
for each pair of participants, since in a large meeting we need all video
streams running through a server and everyone receiving the same streams, for
manageable upload bandwidth. Also, many participants often cannot peer
directly due to NAT etc.

But therefore... as long as you're trusting the server with key
distribution/management in the first place... don't you necessarily have to
simply _trust_ that the server isn't peeking? That by necessity, since anyone
else can join the call and get the decryption key from any of the peers...
that the server can too, whether by MITM attack, a "fake participant" that
joins for a millisecond but doesn't appear in UX, etc.?

That unless you actually have the capability of auditing the server and the
code it's running, E2EE doesn't actually give you any concrete guarantees
whatsoever? You've just got to trust? Which at the end of the day, is no
different from trusting them not to peek at transport encryption?

Of course you can run your own Jitsi server. But if you've already got control
over your servers then you might as well just be using transport encryption
anyways, since you trust yourself -- right?

(Obviously if you come up with your own keys and send them to participants via
a separate channel of communication then it's fine -- but obviously that's not
something regular users are ever going to do.)

Would love to know if I'm misunderstanding something here -- if the newfound
significance of E2EE in videoconferencing is just due to Zoom falsely
advertising it, or if it's actually a realistic goal.

~~~
tpolzer
Key distribution is a problem, yes (as discussed in other comments here).

Upload bandwidth isn't so much of a problem with the number of participants,
as you of course wouldn't encrypt the whole data stream separately for each
peer. Instead, you would encrypt it with a rotating symmetrical key that you
can then safely exchange with all peers (at negligible bandwidth cost). You
would still depend on the server to replicate your encrypted stream (and do
NAT traversal etc), but it wouldn't be able to peek inside.

A separate problem is that you usually want your server to actually create
reencoded video of your stream for participants with bad internet. There's
potentially some ways to do that without server involvement with some clever
video encoding (so that instead of reencoding you can just throw away some
chunks), but afaik there's nothing production ready for video codecs here.

------
sigwinch28
This is huge for decoupling zoom clients from zoom backend servers.

In theory, using a fixed/trusted set of client assets (javascript+html, e.g.
an electron wrapper) allows groups of users to choose a Jitsi "backend"
provider that they don't even trust if the encryption key is never sent to the
server (and _can 't_ be, i.e. it is never in the URL hash).

Since the video is e2e-encrypted and in theory the server never has to be
given the key, this would allow people to purchase hosting services from
untrusted providers or spin up a VM in a public cloud with the confidence that
the _content_ of their conversations is not available to the provider.

Yes, we could just argue that this is XMPP servers and Pidgin all over again
(in fact, Jitsi uses an XMPP server internally), but the modern UI and the
timing w.r.t. COVID-19 lockdowns and Zoom privacy issues is fantastic.

------
kodablah
I have a naive question as I'm toying w/ a similar WebRTC project myself.
Since all browsers support h264/opus, can I just reasonably ask each client to
send 720p to my WebRTC peer which is really a server before I relay it? Then,
can't we just use naive e2e encryption with any extra encoding/decoding?
Meaning, in my TransformStream, can I just window.subtle.encrypt on the way
out and window.subtle.decrypt on the way in? Is it due to the fact that the
insertable streams have to remain in their video format? Pardon my ignorance.
This naive approach does assume everyone can at least handle the download
speeds of the group's video and the upload speed of their own.

------
pal_9000
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?

~~~
georgyo
I cannot think how you could possibly do the key exchange securely and
automatically, if you want to give a link to someone and have it "just work".

If all you have is the URL, then the server sees the encryption key.

Video conferencing also rarely has users register. So there isn't a way to
validate users either. And even if they did register and users didn't care
about the extra friction, multiple devices means either the server stores your
private key, or you have many keys which is much harder to verify.

E2EE is much easier on phones, which is why Signal is so good. The identity is
your phone number, and you can only have one key associate with your number.
That key never leaves your device. Conceptually easy.

Video conferencing has none of those advantages, and I don't know how you
would make it conceptually easy for users without reducing the security.

~~~
crznp
You could still make the phone a primary device and allow it to perform the
key agreement and pass control off with a QR code, but that is complicated and
leaves open the question of who is allowed in this conference.

So perhaps you just give up on persistent identity: just have an unencrypted
waiting room, the organizer and their delegates can approve people in the
waiting room to enter the encrypted conference.

~~~
GordonS
Do you mean kind of like how authentication is sometimes handled on input/UI
constrained devices (e.g. TVs), where a message could be played to callers,
asking them to enter a one-time code at a particular website?

On the face of it, this could work quite well for _most_ people.

------
CiPHPerCoder
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 entire
classes of attack (i.e. padding oracles), CTR would allow better performance:
You can parallelize both encryption and decryption with CTR mode. With CBC
mode, you can only parallelize decryption (but not encryption) since the IV
for all but the first block is the previous block of ciphertext, which means
you'll know the correct IV when decrypting but not when encrypting (since you
have to calculate it sequentially).

Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't
inspire confidence in its correctness.

Furthermore, they truncate the HMAC to 8 byes and attempt to justify the
truncation by appending an Ed25519 signature, but that sort of configuration
is just begging for a confused deputy scenario, like an old iMessage
vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely,
this still uses a MAC, so it's not exploitable), but it's something that
probably would make anyone working in cryptography (and any adjacent fields)
give a confused puppy head tilt when they read it.

Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back
into itself at each ratchet step, I'd feel way more comfortable if the
protocol did HMAC-SHA512 and used one half of the output to derive
encryption/authentication keys and the other half the ratcheting-forward key
(instead of one HMAC-SHA256 for both purposes).

Using two distinct 256-bit secrets (even if they're generated from the same
input at i=0) instead of reusing a secret strengthens the forward secrecy of
the entire protocol.

HMAC-SHA256: One ring to rule them all (at any given ratchet step).

HMAC-SHA512-split: If you (against all odds) guess one of the keys, that
doesn't give you the ratchet-forward key too, since they're two distinct keys
(albeit generated deterministically from the same input).

Nothing I said above is exploitable, otherwise I'd be emailing their security
team instead of posting on HN. :)

That being said, if the Libolm devs want to shore up the security of their
protocol in a future revision, the following changes would go a long way:

1\. Use HMAC-SHA-512 and split it in half for the ratcheting step of
Olm/Megolm

2\. Use AES-CTR instead of AES-CBC

3\. Stop truncating MACs

[1]: [https://gitlab.matrix.org/matrix-
org/olm/blob/master/docs/me...](https://gitlab.matrix.org/matrix-
org/olm/blob/master/docs/megolm.md#message-encryption)

[2]: [https://gitlab.matrix.org/matrix-
org/olm/-/blob/930c4677547e...](https://gitlab.matrix.org/matrix-
org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96)

[3]:
[https://blog.cryptographyengineering.com/2016/03/21/attack-o...](https://blog.cryptographyengineering.com/2016/03/21/attack-
of-week-apple-imessage/)

[4]: [https://gitlab.matrix.org/matrix-
org/olm/blob/master/docs/me...](https://gitlab.matrix.org/matrix-
org/olm/blob/master/docs/megolm.md#the-megolm-ratchet-algorithm)

~~~
Arathorn
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-...](https://matrix.org/docs/spec/client_server/r0.6.0#messaging-
algorithms) \- so I'm not convinced this is a "massive legacy support and
backwards compatibility trap" that we've set for ourselves.

What don't you like about the variable names at
[https://gitlab.matrix.org/matrix-
org/olm/-/blob/930c4677547e...](https://gitlab.matrix.org/matrix-
org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96)
?

~~~
CiPHPerCoder
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...](https://gitlab.matrix.org/matrix-
> org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96)
> ?

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.

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

Yup, indeed. [https://signal.org/blog/the-ecosystem-is-
moving/](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](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom) was our
overdue response)

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

[https://tools.ietf.org/html/draft-irtf-cfrg-
xchacha-03](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).

------
exabrial
As long as I can disable this, good. I need performance over E2EE, much like
many others. We face far more threats from poor communication being distant
than we do from an threat where someone gets past our VPN, Firewall, breaks
TLS encryption, gets into our VPS and private server, and silently
participates in our meetings.

------
cdolan
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.

~~~
saghul
I can't speak to any of that, but you don't need 8x8 in order to run Jitsi.

Jitsi is the same project it was when it was run by an independdent company.
It's the same project it was when Atlassian acquired it, and continues to be
the same project now at 8x8.

It's Apache 2 licensed, and you are more than welcome to use it without
dealing with 8x8 at all.

Disclaimer: I'm a Fellow Jitster at 8x8.

------
giancarlostoro
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).

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

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

------
shawnz
I see a lot of blocky patterns in the encrypted video streams... isn't that
indicative of encryption weaknesses?

~~~
saghul
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.

~~~
shawnz
Interesting, thanks for the information. And also thank you for working on
this important technology.

------
coinward
A bit random, but I'd really like to manage video calls through a browser
extension. Am I alone in this? Seems unnecessary to move in between apps,
couldnt we be hopping in and out of rooms without leaving the browser?

------
tinus_hn
Does this only work in Chrome? Or why are they using the Chrome logo in the
graphs?

~~~
saghul
The "insertable streams" API is currenly only available in Chrome.

------
yeuking
better than Zoom

------
CrankyBear
Oh please. It's a demo. Moving on.

------
emilfihlman
>GET parameter

Yes, it's convenient.

But to tout that as what a well designed encryption scheme should look like?
Nah.

~~~
CrazyStat
From the link:

> _In order to enable quick demos of the feature we allowed for e2ee keys to
> be passed to Jitsi Meet via a URL parameter._

> _IMPORTANT NOTE: This is a demo of an e2e encrypted call and the feature is
> NOT YET intended for general availability, so play with it all you want,
> but, for now, in matters where security is paramount we still recommend
> deploying your own Jitsi Meet instance._

> _As we already pointed out, passing keys as URL parameters is a demo thing
> only. Aside from being impractical it also carries risks given that URL
> params are stored in browser history._

> _Our next step is therefore to work out exactly how key management and
> exchange would work. We expect we will be using The Double Ratchet Algorithm
> through libolm but the details are still to be ironed out._

They're not touting passing the keys in a URL parameter as a "well designed
encryption scheme." They're presenting it as a proof of concept, and planning
for the future work that they acknowledge is necessary.

Your comment is ill-informed and misleading.

------
jcims
Tech support question haha. I run Jitsi Meet (the service at meet.jit.si) on
an iPad that I bought last year.

After about an hour the audio completely fails. No audio in. No audio out. I
can't really tell if it's something with the app or if it's my terrible little
dsl router/nat box dropping the audio stream. I don't have this problem on the
desktop or laptop clients, just the iPad, so I'm guessing it's the app...but
it could be that it works differently on the network.

Anyone see similar?

~~~
jcims
welp...

