[liberationtech] Zoom admitted, then denied, then admitted again that it censored an activist

[Aymeric Vitte]

You don't need to go very far to see that WebRTC is by design insecure
and does not protect privacy, see this thread
https://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html

Unless things have evolved, but I don't think, for some experts that
will understand it, this is a misdesign of the web, beside WebRTC
weaknesses what I am refering too is the unability to use ws with https
when wss can't be used

So probably all services (including Jitsi) are not difficult to
mitm/monitor and they all include a weak central point for peer introduction

A better approach is http://www.peersm.com/Convergence-2020.pdf "A
universal and generic architecture to anonymize any application or
protocol and turn it into an independent decentralized p2p network
inside browsers and servers, with browsers acting as servers", ie plug
onion routing with WebRTC here to make it short, see also
https://github.com/Ayms/node-Tor


Le 14/06/2020 à 04:39, Seth David Schoen a écrit :
> Aaron van Meerten writes:
>
>> I admit this part isn’t my focus, but my understanding is that the
>> technology is called “Insertable Streams”. The basic idea is a
>> hook within the WebRTC engine that allows media to be transformed
>> after capture, but still delivers certain identifiers such as which
>> packet contains a keyframe, or what volume levels to expect, while
>> keep the media itself from being parseable by the server, only the end
>> clients who have the key.
> I hope someone (other than surveillance vendors) has thought through
> whether any of the unencrypted metadata can leak something interesting.
> E.g. profiling the compression patterns in order to get some kind of
> statistics about the plaintext.
>
> https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/schuster
> https://ieeexplore.ieee.org/abstract/document/4531143
> https://ieeexplore.ieee.org/abstract/document/5958018
> https://dl.acm.org/doi/abs/10.1145/3029806.3029821
>
> Real-time video and audio compression with variable-rate codecs is
> (like other uses of compression together with encryption) already pretty
> risky.  Adding more metadata about the streams might make it worse.
>
> It might be good to ask the researchers on some of these and similar
> papers whether the cleartext information that is still provided in this
> WebRTC model is an eavesdropping risk.
>
>> However, future iterations would definitely use something more
>> sophisticated around confirming identity and possibly using algorithms
>> similar to Signal for generating the keys.
> I'm excited that you're working on that!