Two contradictory thoughts about Apple and Path
Apple doesn’t get a full pass on this. While I frequently find myself agreeing with the colorful and not very shy John Welch, I only mostly agree with his take on last week’s Path flap. He responds to a post from Dustin Curtis who argues that (in Welch’s words) “it’s up to Apple to make sure developers who have an ethics problem can’t do this”:
It is not Apple’s job to design iOS to prevent a bunch of shady dipshits from being shady, it’s the fault of the shady dipshits who should stop being shady. The fact you have the moral code of a pit viper is not Apple’s fault.
Absolutely. And I’d agree that’s true for anything shady that developers put in their code. Malware, sending any kind of tracking information without user consent, reading data from other applications by breaking the “sandbox,” stuff that’s generally illegal. You know, a lot of stuff that Apple explicitly polices the App store for and in a couple cases explicitly does design iOS to make difficult.
Which is, of course, the catch. Apple has explicitly made the case that a platform advantage of iOS is that Apple does verify that developers aren’t being shady dipshits. Isn’t that supposed to be at least part of why the iOS App Store is better than the Android Marketplace? Once you’re pitching that as an essential platform differentiator—and I think it’d be hard to argue Apple doesn’t make that pitch—then “is it Apple’s job to keep developers from being shady dipshits” is not the right question. “Why do apps only have to inform of you of some potential privacy issues, not all” is the right question.
This wouldn’t have helped in the case of Path. This is a point that I haven’t seen made often enough in the discussion. If iOS was, in fact, designed to pop up a dialog box saying “SomeApp is trying to access your address book. Allow or Deny?” like it does for the GPS, that might be a minor improvement—but it doesn’t tell you what the application in question is doing with the address book data. If Path had been asking for address book access without sharing the little detail that it was about to send it all merrily off to its company’s servers, we’d have gone through the exact same brouhaha.
In a sense this brings us back to Welch’s colorfully-phrased argument: Path would need to have explained what they were doing so the user could make an informed decision, and it’s unlikely Apple could easily audit every program to make sure it isn’t doing something unduly surprising. No matter how much Apple does to help, ultimately the last line of defense really is developers who aren’t being dipshits. In a comment, John refers to the idea of the “allow access to the address book?” dialog box option as “security theater,” and it is—to the same degree the one for location services is. In both cases, it’s telling you something you probably should have known already (“what do you mean the Yelp app needs location services to figure out what businesses are around me?”), and none of us have any blessed idea what data any of those apps are sending back to their servers even with those dialog boxes.
Yet the widespread framing that Path could only have done this if they’re horrible people who would sell off your grandma if you left them alone in the room with her for five minutes seems a little histrionic. “Never attribute to malice what can be adequately explained by stupidity” is closer, if you replace stupidity with blind spot. As an engineer, you look at a problem and think of the easiest way to solve it, and even if the privacy implications occur to you—or they’re pointed out to you—you object that your code isn’t actually doing anything bad with the data because, well, you’re not a shady dipshit, and the feature you’re coding gets a significant performance gain this way. I’ve had variants of this discussion with coworkers before. The problem is that “am I a shady dipshit” is not the right question. “How would this look to a customer who has no reason to trust me” is the right question.
