<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Thu, Apr 2, 2020 at 9:21 PM Peter Fairbrother <<a href="mailto:peter@tsto.co.uk">peter@tsto.co.uk</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">actually end-to-end at all. Good thing the PM isn't using it for Cabinet <br>
calls. Oh, for f..."<br>
<br>
<a href="https://www.theregister.co.uk/2020/04/01/zoom_spotlight/" rel="noreferrer" target="_blank">https://www.theregister.co.uk/2020/04/01/zoom_spotlight/</a><br>
<br>
tldr:<br>
<br>
not end-to-end despite explicit claim<br>
mines all your data<br>
tracker-friendly<br>
sends data to facebook<br>
big login hole<br>
host can detect if watchers present<br>
all your base are belong to us<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It is all fixable. Question is whether they will have the nouse to fix it or not.</div><br></div><div><div class="gmail_default" style="font-size:small">We should have an open standard for end-to-end secure video conferencing that uses a client that doesn't have HTML, Javascript and all that stuff included in it. Which leaves out WebRTC as well.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Having been thinking on these lines, the pushback I have got from the people in the field are that the reflector has to be able to see the plaintext of the fields because that is the only place they can think of to change the resolutions.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think the obvious answer is to do resolution changes at the device that is originating that image. So there are three basic possibilities. My camera is off, My camera is on and I am sending a thumbnail image and My camera is on and I am sending separate thumbnail and large images.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Of course 'thumbnail' probably means dropping the bit rate as well. So we want to expose enough information to the reflector to allow it to know which encrypted frames are the keyframes, which are the deltas and so on. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the hard part is in the encoding stuff. And you have to really have a handle on that because all the major platforms have very different API models so that they can make use of the hardware assistance for the CODECs .</div><div class="gmail_default" style="font-size:small"></div><br></div><div><div class="gmail_default" style="font-size:small">I remain profoundly unmoved by the obsession certain folk have with 'off the record' capability. The MLS tree is just too complex to be viable in my opinion. I want end-to-end secure communications of course. And sometimes I want forward secrecy. But in an enterprise setting I want to record a lot of calls and store them on disk forever because this is about getting work done, not playing Mission Impossible. I never did understand why the recording announcing a mission self destructed when it came with a big fat dossier that was far more sensitive.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the approach I am taking is to make use of threshold cryptography to provide end-to-end security. There is an encryption key for the group and a separate threshold split of the private key for each member the administrator adds.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In the case that we want a portion of a conference to be off the record (i.e. with forward secrecy enforced), each participant's device posts an ephemeral key that is used to establish a second shared secret with either the key management service or an administrator. If you have 100 people in the channel and you rekey once an hour, having that performed by administrator's machine is not a problem. If you have more than 100 people in the conference your cryptography is nowhere close to being your weakest link.</div><br></div><div><br></div></div></div>