Apple v. The FBI: Let’s debate
Both sides of the conflict over iPhone security
Apple Inc. has rejected a court order to build a new version of the iPhone operating system, which would allow the FBI to access a phone used by one of the San Bernardino shooters.
Unlike previous cases Apple has cooperated with, the company is not being asked to break the phone’s encryption. Instead, U.S. Magistrate Judge Sheri Pym ordered Apple to disable the feature that wipes data from the phone after 10 mistaken attempts at the passcode. The FBI could then use brute force, i.e. millions of passcode options, to open the device.
The phone in question is an iPhone 5C used by Syed Rizwan Farook, who with his wife killed 14 people at a holiday party in December. While the FBI (with Apple’s compliance) has been able to access all information uploaded to the iCloud, the last update occurred two months before the attack, meaning the phone itself hosts information the Bureau has not yet seen.
Why is it important?
This debate is not about the privacy of one dead suspected terrorist. Both sides see this as part of a much larger set of trends: the scope of federal compliance orders, the challenges law enforcement faces with the rise of new privacy protections on consumer devices, and the deepening controversy around general government surveillance.
Should Apple build software to allow FBI access to an iPhone?
Apple should assist the FBI in accessing this suspected terrorist’s device. There is ample precedent for doing so and the company will likely lose the inevitable legal battle if they do not.
Though Tim Cook brings up legitimate long-term concerns, this is a compelling instance in which Apple should (or should be made to) comply. The company is not being asked to provide a “back door” into its devices or proactively weaken its security.
Rather, this case involves one phone from one suspected terrorist and information that could protect against attacks like San Bernardino in the future.
Apple should be held to the same legal standards as other communications companies have in the past. In the Supreme Court’s 1977 case United States v. New York Telephone Co., the court compelled the telephone company to provide “all information, facilities and technical assistance.” Similarly, in this case, Apple is being required to give “reasonable technical assistance” to the Bureau — and it should do so as a matter of security and the prevention of violence against American citizens.
Apple cannot build this new software for three important reasons: system security, legal precedent, and public perception.
The first concern is making sure Apple devices maintain security. In CEO Tim Cook’s words, the software would be “the equivalent of a master key.” It would allow anyone with physical access to any phone to brute force their way into it (depending on the type of password and iPhone). The company has a responsibility not to expose its customers to greater risk of attack in this way.
The second issue is precedent. Complying with this request would create a new interpretation of an old law, the All Writs Act of 1789. Cook notes that under this new interpretation, the government could compel Apple to “intercept your messages, access your health records or financial data, track your location, or even access your phone’s microphone or camera without your knowledge.” This power could spread also to countries like China and Russia.
The third and final problem is public perception of Apple’s response. Apple’s best strategy is to fight for their users’ privacy tooth-and-nail, even if eventually the company is forced to create a key.
- Apple CEO Tim Cook’s letter to Apple customers
- FBI Director James Comey on the “Going Dark” encryption problem
- The Daily Dot’s backgrounder on the All Writs Act of 1789
- The Daily Beast on Apple’s precedent with the FBI
- Salon’s take on law enforcement surveillance strategies
Put another way: the Short Version will set you up for a fun debate, no matter which side you’re on.
If you found this article useful and interesting, please recommend!