I don't want to weigh into the personal side of the WhatsApp vs Facebook fight, as there are people I respect on both sides, but I do want to use this as an opportunity to talk about the future of end-to-end encryption. (1/13)
This might make me a radical in 2018, but I believe that people deserve to be able to communicate with one another without a corporation or government reading or censoring that communication. (2/13)
If we want that right to be extended to people around the world, that means that E2E encryption needs to be deployed inside of multi-billion user platforms. That requires two things to happen: (3/13)
The entire discussion around Facebook’s disclosures of what happened in 2016 is very frustrating. No exec stopped any investigations, but there were a lot of heated discussions about what to publish and when. https://t.co/dSOpKy767l
In the spring and summer of 2016, as reported by the Times, activity we traced to GRU was reported to the FBI. This was the standard model of interaction companies used for nation-state attacks against likely US targeted.
In the Spring of 2017, after a deep dive into the Fake News phenomena, the security team wanted to publish an update that covered what we had learned. At this point, we didn’t have any advertising content or the big IRA cluster, but we did know about the GRU model.
This isn't a good response from Facebook to the NY Times story, because it makes the same mistake of blending all kinds of different integrations and models into a bunch of prose and it is very hard to match up the responses to the Times' claims.https://t.co/rrnWylOBMp
What they really need is a table that gets updated over the next several days that lists the company, the kind of integration, what data was accessible, what steps a user took to activate the integration, and when/whether it was shut down.
There very well could be serious privacy problems in the Times' story, but it is hard to tell what is really problematic because they intentionally blur the lines between FB allowing 3rd party clients/OS integrations (like Apple) with data actually going to other companies.
These two reports are really important and I hope people read the original sources and not just the headlines.
I've decided to save most of my reactions for some long-form writing, like a real academic. I do want to bring up one way to frame how we want to move forward... https://t.co/4R75afMrND
We now know a great deal about the GRU and troll infowar campaigns and the direct attacks against election infrastructure 2016. It's Dec 2018.
The question to answer: "How can we have equivalent insight into foreign interference in early 2020 when we can still react?"
I think this should be the focus of the SSCI report. We missed a huge opportunity after 2016 to have a 9/11 Commission style investigation into intelligence failures inside .gov, the tech companies, and between them. SSCI is best positioned to fill that gap.
I have no special insight into the latest FB API issue, but I will use this opportunity to discuss the difference between a "traditional breach" and an information leak from an API, and what that means for disclosure. https://t.co/mpC54GA6zM
In a traditional breach, your response and investigation time is used to:
1) Find the bad guys in your network
2) Figure out how they got in
3) Kick them off
4) Add up what they accessed
5) Disclose #4
6) Fix #2 and other issues
With a web app/API privacy bug:
1) Find a bug or have it reported
2) Fix it and deploy
3) Look at access logs for entire exposure period for possible abuse
5) Address root causes that allowed the bug to be created and not get caught earlier