The Weekly Ink #4
THE WEEKLY INK
The Weekly Ink is the weekly newsletter brought to you by Duo Labs, the security research team at Duo Security, with curated links of interest in the security world to inform the community on security happenings and culture.
You've likely heard of the recent Supreme Court decision in Riley vs. California that established that police (generally) can't search your smartphone without a warrant. Although the decision allowed for some exceptions, and - as Chief Justice Roberts suggested - getting a warrant may be less of a hurdle than it once was ("police officers can e-mail warrant requests to judges’ iPads [and] judges have signed such warrants and e-mailed them back to officers in less than 15 minutes"), this was a significant win for privacy advocates.
Actually, it turns out this decision might have some implications in yet another of the thorniest digital privacy issues of our time: the government's ability to access personal data stored in "the cloud." As Andy Greenberg writes, almost all such data is currently subject to the court's previously-established third-party doctrine, "...the notion that [almost] any data kept by a third party such as Verizon, AT&T, Google or Microsoft is fair game for a warrantless search." As we increasingly use online services to store and manage all of our data, the third-party doctrine is turning out to be problematic in many of the same ways as warrantless smartphone searches.
Of course, a Supreme Court case isn't the only avenue by which we could fix these problems; Congress could also act by reforming the Electronic Communications Privacy Act (ECPA). The ECPA already provides perhaps the only notable exception to the third-party doctrine as it applies to the cloud, but it's extremely narrow; the ECPA was written nearly 3 decades ago, when the notion of cloud-based storage basically hadn't come up in anyone's wildest dreams...
Last week, Microsoft (through some sneaky legal and technical maneuvers) seized control of over two dozen domains belonging to no-ip.com, a dynamic DNS provider. This move was intended to take down tens of thousands of hostnames that were acting as backend infrastructure for two common families of "Remote Access Trojans," but in the process black-holed as many as 4 million non-malicious hostnames. Microsoft has since admitted that this was a "technical error" (i.e. they totally didn't mean to disrupt services for so many unsuspecting users), and the situation appears to be headed toward resolution.
This is not the first time Microsoft has taken an action like this - in fact, according to Microsoft's blog post, it is the tenth "malware disruption" they've undertaken - but it is perhaps one of the most dramatic, and seemed to involve quite a bit more collateral damage than their previous actions. Generally, Microsoft's malware disruptions have probably been a good thing for Internet security at large, but many observers are a bit unsettled that they've essentially taken a role of an extra-governmental enforcement body, in this case seizing resources owned by a legitimate company.
Recently, thanks to a FOIA request from a concerned citizen, a complete dump of NYC's taxi trip and fare logs was made public. However, while the city made an attempt to anonymize certain data in the logs, it was not a very good one.
In general, it turns out that it's really hard to properly anonymize large datasets (as Netflix learned the hard way); in fact, according to Ross Anderson in his excellent Security Engineering text, much of the security research community has written off this problem as simply being "too hard."
However, the sorts of attacks that might lead researchers to this conclusion are way more complicated and subtle than what Vijay Pandurangan describes in this post: NYC made a rookie-level mistake, and could easily have done much better.
As I suggested back then, End-to-End might face a fairly skeptical reception from many in the security community, not least because many "crypto/security nerds have a knee-jerk 'considered harmful' reaction to anything involving JS Crypto."