
The facts around Zoom and encryption for meetings/webinars - arvindch
https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/
======
gregmac
Zoom! What are you doing?!

> To be clear, in a meeting where all of the participants are using Zoom
> clients, and the meeting is not being recorded, we encrypt all video, audio,
> screen sharing, and chat content at the sending client, and do not decrypt
> it at any point before it reaches the receiving clients.

That is _still_ not what "end-to-end encryption" means. From wikipedia[1]:

> End-to-end encryption (E2EE) is a system of communication where only the
> communicating users can read the messages. In principle, it prevents
> potential eavesdroppers – including telecom providers, Internet providers,
> and even the provider of the communication service – from being able to
> access the cryptographic keys needed to decrypt the conversation.

The fact that it's _possible_ to decrypt is what makes this not "end-to-end
encryption".

Personally, I am totally fine with their implementation, I just wish they'd
stop misusing the term. For the vast majority of users, everything being
encrypted over-the-wire coupled with a reasonable policy (eg, employees cannot
listen in on random meetings) should be totally acceptable.

If there are people that that _actually_ needed true end-to-end encryption and
choose Zoom based on their marketing saying they had it, without doing
validation, that's on them (though they're probably right to be upset with
Zoom, too, for being misleading). Frankly, that set of people shouldn't be
choosing anything they don't control and trust completely (code, hosting,
updates, etc) which pretty much rules out any SaaS, so I suspect this set
doesn't actually exist in the first place.

Bottom line: Don't call it "end-to-end encryption" if you have access to the
keys and _can_ decrypt, even if you choose not to. Market that you encrypt
everything in transit, and that employees aren't allowed to access streams. Be
realistic in the potential weak points (someone hijacking or able to modify
the Zoom infrastructure, PSTN interconnects, non-Zoom clients, etc) and what
you do to mitigate those risks.

[1] [https://en.wikipedia.org/wiki/End-to-
end_encryption](https://en.wikipedia.org/wiki/End-to-end_encryption)

~~~
lern_too_spel
> The fact that it's possible to decrypt is what makes this not "end-to-end
> encryption".

By that definition, iMessage is also not end-to-end encrypted because Apple
can decrypt the messages due to controlling the key servers and the relay
servers, but few people bat an eye when Apple claims iMessage is end-to-end
encrypted on its privacy marketing page.

[https://blog.cryptographyengineering.com/2013/06/26/can-
appl...](https://blog.cryptographyengineering.com/2013/06/26/can-apple-read-
your-imessages/)

[https://www.apple.com/privacy/features/](https://www.apple.com/privacy/features/)

~~~
saagarjha
Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts the
stream so that it’s compatible with non-Zoom clients and then advertises it as
end-to-end, a fault in the protocol itself, while you’re comparing it to
(outdated, FYI) information where Apple could possibly decrypt messages if
they sent out fake keys.

~~~
lern_too_spel
> Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts
> the stream so that it’s compatible with non-Zoom clients and then advertises
> it as end-to-end

I took issue with a specific definition that precludes both products. I _didn
't_ say that both products use the same protocol.

> you’re comparing it to (outdated, FYI) information

Has the implementation changed in any way that makes it meet the definition?
No? Then the information is not outdated for our purposes.

~~~
saagarjha
> I took issue with a specific definition that precludes both products.

This isn’t the first time you’ve tried to compare Zoom and iMessage; it’s just
that I chose this one to respond to.

~~~
lern_too_spel
Have I made a false comparison anywhere else, or was the comparison valid as
in this case?

~~~
saagarjha
You keep drawing parallels between Zoom's end-to-end encryption and
iMessage's, when there really is little to compare. iMessage is end-to-end
encrypted because intermediaries do not have access to decryption keys; your
"attack" relies on a malicious actor tampering with key distribution using a
technique that requires even more setup than is described in the old article
you've linked. On the other hand, Zoom has been actually decrypting traffic
_as a key part of their service_ and yet called it end-to-end.

~~~
lern_too_spel
> You keep drawing parallels between Zoom's end-to-end encryption and
> iMessage's, when there really is little to compare

Once again, in none of my comparisons have I said they are doing the same
thing. Please point to a specific comment I have made that you think is
misleading.

------
tptacek
If this pisses you off, it's worth noting that Telegram group chats have the
same property, and that Telegram argues forcefully (and falsely) that what
they're doing _does_ meet the definition of "end-to-end encryption".

~~~
geofft
Wait, I thought Telegram was worse than that - Zoom does (what appears to be)
end-to-end encryption if you have four native Zoom clients in a meeting.
Telegram doesn't do end-to-end if you have four Telegram clients in a group
chat, right?

(I might be missing something about either Zoom or Telegram)

~~~
tptacek
I think you're right! I'm more interested in the double standard (and the
dynamics of a pile-on) than the details.

~~~
geofft
Yeah, I'm honestly a bit surprised because I personally would agree with Zoom
that what they're doing is "end-to-end encryption." (Maybe it'd be nice if
they had a "mandatory e2e" checkbox that you had to uncheck to get a dial-in
phone number, but, obviously when I call a number by phone I know there's no
e2e going on.)

I think the pile-on is mostly because finding security problems with Zoom is
the cool new thing to do. There's been no shortage of genuine security
problems with Zoom (and an apparent lack of security culture) but I think
we've now gotten to e.g. "you can use Zoom to trigger a Windows design flaw
that's been around for years" or "when you set up a meeting anyone can join,
anyone can join the meeting" or whatever, and the media is happy to pick that
up.

~~~
sweeneyrod
If what Zoom is doing in the first diagram is end-to-end encryption, what
would non-e2e encryption for that set up look like?

~~~
geofft
Data decrypted when it reaches Zoom's servers, e.g., sending video directly
over TLS to a webserver that then sends it to someone else over TLS.

This is what Slack, Skype, Google Hangouts, etc. do.

------
CivBase
> While we never intended to deceive any of our customers, we recognize that
> there is a discrepancy between the commonly accepted definition of end-to-
> end encryption and how we were using it.

So you knew that your users would misinterpret the term "end-to-end
encryption" but chose to use it anyways. And you somehow expect us to believe
you "never intended to deceive any of [your] customers"?

> The goal of our encryption design is to provide the maximum amount of
> privacy possible while supporting the diverse needs of our client base.

This statement is at odds with the statement that immediately follows.

> To be clear, in a meeting where all of the participants are using Zoom
> clients, and the meeting is not being recorded, we encrypt all video, audio,
> screen sharing, and chat content at the sending client, and do not decrypt
> it at any point before it reaches the receiving clients.

If you do not decrypt it at any point, then you are admitting you have no
legitimate need to decrypt it. If you have no legitimate need to decrypt it,
but are retaining the ability to decrypt it anyways, then you are not
providing the "maximum amount of privacy possible". If you are communicating
between two Zoom clients, then there does not seem to be a reason not to use
true end-to-end encryption.

I'm 100% fine with Zoom offering solutions without true end-to-end encryption.
The way they have described their "Zoom Connector" solution, I think they've
already gone above and beyond most of their competitors. _However_ , that
absolutely does not excuse how they have deliberately mislead their users.

~~~
paul_f
I don't agree there is a common definition of end-to-end encryption. Ask a
random, non-technical co-worker what they think it means and you might get an
answer that matches Zoom's marketing claims.

~~~
CivBase
I feel like "end-to-end encryption" is a mostly self-explanatory term. All
data passed from one end to the other is encrypted.

The point of encryption is to ensure that third parties cannot read your data.
If a third party has the power to decrypt and read the data, then it's already
misleading to advertise it as "encrypted". That would be like advertising a
pair of boots as "waterproof" when they only actually prevent water from
entering via the soles.

If the data is encrypted by one end, decrypted by a third party, and received
at the other end unencrypted, then the encryption is not "end-to-end". I'm not
sure how you could possibly interpret that part any other way.

~~~
rjmunro
But that's not the question here. That's only talking about when there is a
connector involved. For a zoom-zoom only chat, if my encryption works by:

* I generate a key * I give it to you and another party * You and the other party then chat through my service * I pass the messages between you but don't bother to decrypt them

Does that count as end-to-end encryption? At any time, I could decide to
decrypt the message (even months later if it is logged).

------
fierarul
How could they guarantee end-to-end if not all gadgets support encryption?!

Let's demand end-to-end encryption for people connecting via FAX machines to
read only the comments.

Of course connecting via unreliable machines / protocols means Zoom must have
some bridge on their side somewhere.

In light of this post it looks like for the _majority_ of users it is end-to-
end encrypted.

I don't even use Zoom, but really, these attacks are starting to be annoying.
From what I've seen all Zoom's reply is bang-on and they will come out of this
even stronger.

~~~
gregmac
> How could they guarantee end-to-end if not all gadgets support encryption?!

They can't. So they shouldn't.

> In light of this post it looks like for the majority of users it is end-to-
> end encrypted.

It absolutely is not. What they can say is for the vast majority of users, the
streams are encrypted between all clients, and due to policy, Zoom won't view
them as they pass through.

The problem is Zoom _could_ intercept and decrypt streams, if they wanted to,
which is why you can't call this "end-to-end encryption" [1].

[1] [https://en.wikipedia.org/wiki/End-to-
end_encryption](https://en.wikipedia.org/wiki/End-to-end_encryption)

~~~
close04
> The problem is Zoom could intercept and decrypt streams, if they wanted to

And we have the spirit of encryption to guarantee they, or a third party who
infiltrated/hacked them, won't.

>> and in that spirit, we used the term end-to-end encryption

~~~
lukevp
The spirit of encryption? What does that mean? End to end encrypted means from
one client through all networks and servers to the other client, no one can
decrypt the traffic. Anything besides that is not end to end.

~~~
close04
It means nothing but this is what Zoom tells us we have. Encryption given "in
the spirit" of their intentions.

> Zoom has always strived to use encryption to protect content in as many
> scenarios as possible, and in that spirit, we used the term end-to-end
> encryption.

~~~
lukevp
Oh, I missed your sarcasm originally. I agree that it’s meaningless.

------
JumpCrisscross
Zoom marketed end-to-end encryption. They didn't have end-to-end encryption.
Parroting the "we used the term differently" line is counterproductive. They
need to acknowledge the problem, appoint the CEO as the spokesperson and over
correct [1].

If Zoom's CEO publicly apologized for the lies, fixed their marketing copy and
offered refunds to anyone who felt misled, this problem would go away.

[1] [https://www.youtube.com/watch?v=PB-
AyvgE8Ns](https://www.youtube.com/watch?v=PB-AyvgE8Ns)

~~~
geofft
> _Zoom marketed end-to-end encryption. They didn 't have end-to-end
> encryption._

My understanding is that they do in fact have end-to-end-encryption between
Zoom clients, it's just that when you join via a dial-in phone number, the
connection is (of course) not encrypted between your phone and the system
you're dialing into. People who wanted end-to-end encryption could just choose
to not dial in by phone, and they'd get it. (People who want end-to-end
encryption between phone calls from unmodified phones want something self-
contradictory.)

I'm not sure I'd call that "They didn't have end-to-end encryption." Would you
say that my IRC OTR session with my friend isn't end-to-end encrypted because
I connect to irssi running in a screen session on a remote host and the e2e
doesn't go all the way to my laptop?

~~~
luckylion
> My understanding is that they do in fact have end-to-end-encryption between
> Zoom clients, it's just that when you join via a dial-in phone number, the
> connection is (of course) not encrypted between your phone and the system
> you're dialing into.

Which means, there is no end-to-end-encryption. Zoom _knows_ the key but does
not decrypt the data unless they need to to let a member join via phone. You
need to trust Zoom that they keep their promise not to decrypt your
communication, there is no technical hurdle.

~~~
geofft
How is that meaningfully different from a system like Signal or iMessage where
you need to trust Zoom that when they say "this is Bob's fingerprint" they're
actually giving you Bob's fingerprint and not their MITM key? They still need
to keep their promise, there still is no technical hurdle.

(Signal gives you the option to verify fingerprints out-of-band but their UI
discourages using it; iMessage doesn't even do that. I mean, maybe the answer
is we collectively decide to stop calling iMessage end-to-end-encrypted....)

------
softwaredoug
Is there any evidence that other teleconferencing solutions meet or exceed
what's described in this blog article?

I just find the Zoom hate weird. We have no reason to think Teams, Hangouts,
or anything else does anything close to or better than this. Lots of reason to
suspect they probably don't.

Don't get me wrong, I think the scrutiny is good, and will lead to positive
outcomes. But we probably need to scrutinize all these vendors

~~~
tommoor
The video must be decrypted to do the scaling, transcoding, and dynamic
bitrate adjustment for different platforms and network speeds – there's no way
around this.

All of the group video providers will be decoding video on the server to
achieve the reliability everyone wants.

~~~
angry_octet
The clients can dynamically adjust their sending rate and resolution. It is
pretty easy to downgrade your video when not talking. Its also possible to
number and label the encrypted frames (I frames or B frames), allowing
decimation for low bandwidth clients without recoding, which is expensive and
slow.

There are also ways to send additive resolution streams -- a base stream and
additional detail layers (multiresolution like JPEG2000).

~~~
tommoor
Clients already do this yes, but to achieve the reliability that zoom is
renowned for you also need to dynamically adjust what is sent _TO_ individual
clients

~~~
angry_octet
Can the clients not advise the server what bandwidth and packet loss rate they
are seeing, so the server can adjust their traffic rate? There is no reason
not to allow a signalling channel separate to the E2E encrypted data channels.

~~~
xeromal
The server would then have to tell the streamer / talker to reduce their
quality for that one client while degrading all other clients that have a fine
connection right?

~~~
angry_octet
If you absolutely must have high frame rate for everybody then you might make
that choice. But generally you could just drop B frames from the stream for
the slow client, so they get a slower frame rate.

If you wanted to be fancy you could do distributed processing, whereby another
node downscales and re-publishes the feed.

------
bubblethink
>The Facts Around Zoom and Encryption for Meetings/Webinars

Is everyone doing alternative facts now ? This was a relatively simple thing
to clear up, if they wanted to clear it up. They _can_ decrypt whatever they
want. So it's not end to end. Claiming otherwise was disingenuous, but putting
out some PR spin on top of that is doubly so.

------
stonewareslord
Does anyone know how this could technically be possible? For a meeting with
all Zoom clients they say they use E2E. When a new participant joins, they are
immediately added to the meeting.

Is a new pubkey key generated and passed to existing participants? Is there
one shared symmetric key that is sent to the new participant? What stops zoom
from "adding a participant" and allowing themselves to decrypt the meeting? Is
there no server-side transcoding done at all?

It's obvious phone enabled calls can’t be E2E

------
gfodor
If Zoom literally doesn't decrypt the packets in flight to re-encrypt them, it
means they don't have peerwise keys for each client. So (as a non-expert)
they're either now lying about something else (and in fact, the data is
decrypted on the server temporarily in memory, and re-encrypted for each peer
using a distinct key, akin to a WebRTC SFU) or there's a shared secret key
between all clients, which is a major security deficiency.

~~~
detaro
The article specifically states that they coordinate the key through their
servers.

~~~
gfodor
So which of the two is it? A shared secret key among all clients, or
individual keys per client. If its the latter, which would be smart, this line
is a lie:

"...and do not decrypt it at any point before it reaches the receiving
clients"

~~~
detaro
It doesn't make sense to encrypt the traffic differently for the individual
users, since you would need to send multiple copies of the stream if the
server can't do it (which is also a big downside of all the P2P solutions).
It's not smart design for large-scale video chat.

A shared key or different keys per sender (which I don't think adds anything,
but I might be missing something) both do not require the server to
decrypt/reencrypt, and thus fairly sure that's what they are doing if this is
anywhere close to accurate.

~~~
gfodor
WebRTC SFUs encrypt traffic differently to the individual users. Each outgoing
packet needs to be encrypted with the receiver's negotiated keys, is my
understanding. If it was a shared key, then presumably that key could be
negotiated among the peers using public key exchange, unbeknownst to the
server, and then all traffic be e2e encrypted, which it isn't. I have minimal
understanding of what protocols Zoom uses out of the box, but if they don't
support e2e encryption, it seems to me they need the keys on the servers for a
reason, and the only legit reason would be to trans-crypt the packets.

~~~
detaro
It's a lot easier to implement central key management than a fully e2e system,
especially if they do need the key for many meetings anyway on some of their
systems.

------
hedora
In fairness, it sounds like it’s end to end encrypted until a legacy device
connects.

Am I misunderstanding something? This doesn’t seem like it should be
controversial.

~~~
cracker_jacks
Is the end to end encryption removed for all clients when a legacy device
connects?

I don't understand how some devices could be end to end encrypted in a meeting
while some legacy devices in the same meeting are not. How could the legacy
devices send and receive to the encrypted clients?

~~~
angry_octet
It is possible if you think about it beforehand -- genrally you use a tone
and/or a visual indicator to show that a transmission is in the clear
(unencrypted). Other clients can then have a mechanism to allow speaking in
the clear (sometimes requiring PTT -- press to talk). When encrypted
transmission is ongoing, the gateway to the encrypted net may output a 'talk
tone' that indicates the channel is busy. In this way a low grade client can
join the conference, but they hear nothing but beeps (for a pure voice
circuit) or see a busy indicator (for IP circuits) until someone wants to talk
to them. When they talk, it is unencrypted till it reaches a gateway, after
which it is either encrypted with the gateway key or passed unencrypted. (For
radio broadcasts you just hear crackle or nothing.)

Obviously for un-trained users you often have the problem where someone
transmits encrypted when they meant to talk in the clear, and vice versa. This
is the reason for the 'plaintext' or 'ciphertext' side tones. If someone
starts talking in the clear when they should not, another participant may
choose to transmit over them, known as stepping on their transmission.

None of this requires there be a group key known by a central server.

------
innagadadavida
Don’t all these products need to do this if one of the participants is using a
regular phone? It’s just impossible to support phone dial in otherwise. They
claim to do end to end encryption if there are no phones on the call.

~~~
liuliu
it is unclear how key exchanges can be handled securely in these cases. The
post seems to suggest Zoom cannot insert itself as middleman ("without showing
on the participant list"). But that contradicts directly to how these
"connectors" work.

~~~
jcrawfordor
The connectors appear in the participant list - this is a pretty common
architecture for all kinds of communications bridging solutions. When someone
joins a meeting by phone, Zoom spins up a service that 'assumes the identity'
of that phone user to join the meeting (incl. negotiating keys). So, the Zoom
service is now a participant in the meeting, but you do know that since a user
appears in the participant list.

I have no special insight into how Zoom implements it, that's just how this is
normally implemented in a number of other situations (e.g. h.323 bridges).

~~~
liuliu
Thanks, that makes sense. I am not familiar with Zoom the product to know the
connectors show up in participant list.

I think even if proper e2e channel established, without authentication (Zoom
just allows you to join any meeting with a token, like every other Hangout
product), the key exchanges with other participants will be very automated.
There seems to be very limited security guarantee if anyone can send you a
public key in exchange for the current session key to participate in a meeting
to begin with.

~~~
jcrawfordor
Right, and this is kind of the key problem that Zoom is having to solve right
now. The only material you (used to) need to know to join a meeting was a
9-ish digit meeting ID, and since that meeting ID entitles you to negotiate
keys, it more or less nullifies encryption guarantees (except the post-hoc
guarantee of the meeting host being able to see if something was up).

I would point out that this is in no way unique to Zoom, though. In fact,
after the changes Zoom made in response to all of these issues, Zoom probably
has the highest by-default level of meeting security of just about any product
out there.

------
president
So essentially any time a Zoom Connector is involved, Zoom has access to the
meeting contents since they own the keys. It would be interesting then to know
what percentage of all Zoom calls involve a Connector.

~~~
angry_octet
Who says there is not an invisible Connector? They have the keys.

You have to assume every Zoom call is recorded by Zoom.

------
pureagave
I've gone from a big fan of Zoom to now a skeptic. I'm wondering if Zoom might
turn out to be the CPP's version of Crypto AG.

------
herf
Does anyone know if using the "browser client" breaks encryption? I have been
trying to use it to avoid issues with the native app, but if it turns on
server-side decryption, that's kind of a big tradeoff.

Glad to hear they have the on-premise option anyway.

------
dmitrygr
"Zoom has never built a mechanism to decrypt live meetings for lawful
intercept purposes"

Is this a lie or have they not heard of CALEA?

~~~
detaro
Are they classified as something falling under CALEA?

~~~
dmitrygr
yes:
[https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pd...](https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pdf)

------
prophesi
"Zoom has always strived to use encryption to protect content in as many
scenarios as possible, and in that spirit, we used the term end-to-end
encryption. While we never intended to deceive any of our customers, we
recognize that there is a discrepancy between the commonly accepted definition
of end-to-end encryption and how we were using it."

In other words, "We deceived our customers with false advertising but we're
never going to admit that."

~~~
robbyt
"We never intended to deceive any customers when we invented a new definition
of e2e encryption"

~~~
Spivak
"The business and marketing teams, who have never heard of the term e2e
before, looked for a term to describe the feature of having every part of leg
of the call encrypted, came up with e2e, and used it in the copy."

------
gumby
I love that the address one issue and ignore all the other security holes.
They have a structural problem with taking security seriously.

~~~
dangoor
They had a separate post about privacy/security in general:
[https://blog.zoom.us/wordpress/2020/04/01/a-message-to-
our-u...](https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/)

------
wheelerwj
wow!! zoom you were better off not having written that blog. you guys are some
shady assholes.

Everything from the text to the graphics are intended to mislead and obscure.
I don’t think i’ve seen a company act in such bad faith since theranos was a
thing.

~~~
Thorrez
In my opinion they seem better off from this blog post. For example yesterday
I read this comment[1] and it seemed to say Zoom always decrypts the content
on the servers, in which case it's very bad to say it's "end-to-end
encrypted". But this blog post explains that if you don't have any external
connector attached, it in fact is end-to-end encrypted, no false advertising.
When you have an external connector attached it seems to me very difficult if
not impossible to make it end-to-end encrypted, so it's reasonable that it's
not. The problem is that they continued to say it was end-to-end encrypted
even in that case when it's not and not possible to do so.

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

~~~
wheelerwj
> if you don't have any external connector attached, it in fact is end-to-end
> encrypted,

It doesn't say that all.

~~~
Thorrez
> we encrypt all video, audio, screen sharing, and chat content at the sending
> client, and do not decrypt it at any point before it reaches the receiving
> clients.

This seems to say it, but I guess as luckylion points out, e2e doesn't mean
not decrypted in the middle, it means no one besides the ends has the key. So
you're right, the design they say isn't really e2e encrypted.

~~~
Spivak
Devil's advocate: if I take any e2e chat system and escrow the keys from the
clients to my server is it still e2e?

~~~
Thorrez
I'm not sure what escrow means in this context. But if the server has the
keys, I would say no, it's not e2e.

This aligns with the definition on Wikipedia too

> it prevents potential eavesdroppers – including telecom providers, Internet
> providers, and even the provider of the communication service – from being
> able to access the cryptographic keys needed to decrypt the conversation.

------
f38zf5vdt
> For those who want additional control of their keys, an on-premise solution
> exists today for the entire meeting infrastructure, and a solution will be
> available later this year to allow organizations to leverage Zoom’s cloud
> infrastructure but host the key management system within their environment.
> Additionally, enterprise customers have the option to run certain versions
> of our connectors within their own data centers if they would like to manage
> the decryption and translation process themselves.

So... privacy is a premium feature requiring you to self-host? Why not just
run jitsi for free?

~~~
swixmix
Doesn't Jitsi have the same problem? The solution is the same: Run your own
server. End to end encrypted videoconferencing does not scale easily without a
server.

> Is Jitsi Meet end-to-end encrypted? #409

> ... "yes, [https://meet.jit.si/](https://meet.jit.si/) encrypts the
> communication, only the two clients and our server has access to them". ...
> [1]

[1]: [https://github.com/jitsi/jitsi-
meet/issues/409](https://github.com/jitsi/jitsi-meet/issues/409)

~~~
f38zf5vdt
Yes... but in one case the software is entirely FOSS and readily deployable
via a docker image. The Zoom server is not FOSS, or even accessible through
their GitHub.

[https://github.com/jitsi/docker-jitsi-meet](https://github.com/jitsi/docker-
jitsi-meet)

~~~
swixmix
Right. Let's assume I refuse to take on the responsibility of a
videoconferencing server. What are my options to get Jitsi Meet? Can I pay a
company to set up and maintain it? Or do I have to hunt for a
videoconferencing engineer?

~~~
f38zf5vdt
It's free if you use their servers
([https://meet.jit.si/](https://meet.jit.si/)), but then you're back to square
one in that you don't own the encryption keys.

Scaleway shows how easy it is to configure and deploy on a cloud host:

[https://www.scaleway.com/en/docs/deploy-jitsi-meet-with-
dock...](https://www.scaleway.com/en/docs/deploy-jitsi-meet-with-docker/)

Whether or not your cloud hosting is secure is a separate issue altogether. :)

I'm not saying that it's E2EE on Jitsi either, but at least the implementation
is transparent.

