<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Fri, Jun 5, 2020 at 2:54 PM Lea Kissner <<a href="mailto:chialea@gmail.com">chialea@gmail.com</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"><div dir="ltr">I know I'm not active here, but hi. We're aware that binary transparency exists, it's just not on the first few priorities, which should help protect against risk of targeted backdoors. That's quite a lot of why web clients are specifically excluded.</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I was considering the issue more as a research challenge problem for the general case.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">End to end is important but Zoom is not my first concern. There is relatively little I can learn from video quickly unless people are livestreaming activities that would render them vulnerable to coercion. I stated that in the first video I made on Zoom crypto.</div></div><div><br></div><div><div class="gmail_default" style="font-size:small">What worries me most are shared documents. An attacker can download them and use regex searches to find the good stuff in megabytes of material. So Google Docs, Dropbox, Slack etc worry me more. Github is also a concern.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Next concern after that is asynchronous messaging such as email. It should be clear at this point that S/MIME and OpenPGP don't meet the user requirements to become ubiquitous and never will.</div><div class="gmail_default" style="font-size:small"></div><br></div><div><div class="gmail_default" style="font-size:small">On the code transparency/validation front, I think we are going to have to start seeing 'designed for validation' as part of the spec. For example, anything that can read/write arbitrary files on disk is going to be really hard to verify. That risk can be minimized by funneling all file handling system calls through a single point that limits access to the limited directory locations an app is allowed to access. Essentially the principle of Hoare's monitors brought into the application layer. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Assume for the sake of argument that we are using a managed code language such as C# and that we do not allow code obfuscation or some of the more aggressive features (e.g. ability to generate and compile code on the fly). Further assume that it provides the .NET style 'strong assembly' capability.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Using those capabilities it would be possible to determine by static analysis of the executable that it was using a particular support library that prevents the code exceeding its intended privileges. Essentially providing a 'trusted computing base in software'</div><br></div><div><div class="gmail_default" style="font-size:small">Instead of validating the entire program, it would be sufficient to check that it only used managed code libraries with no native code and that the support library had the appropriate checking.</div><br></div></div></div>