@alexstamos has a better list of Twitter handles (and thanks to all of the other folks who were involved, including the external counsel who suggested we use the phrase "as contemplated herein" multiple times and I almost did it)https://twitter.com/alexstamos/status/1263896949712814080 …
-
Show this thread
-
Replying to @LeaKissner @alexstamos
Coming in hot with my q's about the web client
https://github.com/zoom/zoom-e2e-whitepaper/issues/2 …2 replies 0 retweets 10 likes -
3 replies 0 retweets 9 likes
-
What’s the new hotness in protecting JS from being changed for one user?
6 replies 0 retweets 5 likes -
Replying to @alexstamos @sleevi_ and
I'm not sure its a problem worth solving, you have to trust the provider, because bugdoors are perfect and plausibly deniable. If you distribute a targeted backdoor to one user, you might get caught, but w/bugdoor, just say "oops, please be responsible" if someone catches you.
2 replies 0 retweets 7 likes -
Replying to @taviso @alexstamos and
Tavis, do you mean distributing the "targeted bugdoor" to all users but then only exercising it against the one target user? Or distributing it to just the targeted user?
1 reply 0 retweets 0 likes -
Replying to @zooko @alexstamos and
Right, why not just distribute it to all users, and then exercise it against the target user? There is zero penalty if you're caught, you can just try again.
1 reply 0 retweets 2 likes -
Replying to @taviso @alexstamos and
hm. Interesting argument. So basically you have to always maintain at least one bugdoor in your release version.
1 reply 0 retweets 0 likes -
Replying to @zooko @alexstamos and
You can also add a new one in a feature update or patch if you decide to become malicious later, or if your old one gets found. I don't really know of any way to defend against bugdoors, you have to trust your provider.
1 reply 0 retweets 3 likes -
Replying to @taviso @alexstamos and
This argument also means there's no difference with regard to this between a local app and a web app, right?
2 replies 0 retweets 0 likes
In terms of whether the crypto can be trusted? I don't think so. Ryan disagrees though, IIUC, he points out that if a compromised (but not malicious) vendor has separate code signing infrastructure, the attacker might not be able to get a modified build signed.
-
-
If the vendor *is* trying to insert a backdoor, then there's no difference because of bugdoors.
1 reply 0 retweets 2 likes -
Replying to @taviso @alexstamos and
FWIW, I think it matters, the difference between a vendor being forced to commit to a permanent, public record versus not having to do so.
1 reply 0 retweets 0 likes - 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.