Clickwrap privacy isn’t the answer

Two sets of mobile app privacy stories have broken into the mainstream press this month. The first half of the month was dominated by “addressbook-gate”, where Path (and then, it turns out, many other iOS applications) were found to be uploading and storing users’ phone contact lists to their servers.

In the firestorm that followed, many people — including some US Representatives — called on Apple raise the walls of their garden and address the issue by limiting app access to the address book and notifying users when the application requests access. Apple agreed, and will be introducing those changes in a future version of iOS.

So case closed. Until this last weekend, when the (London) Sunday Times reported that many popular mobile apps, including Facebook for Android, were “reading” user text messages. (Incidentally, the Sunday Times article is behind a paywall, and I haven’t seen a copy of the original article.) Extrapolating from other articles covering the Times “scoop”, it looks like the story is likely about the permissions apps typically request during the installation process.

Apps that overreach in their requested permissions are a bad thing, but they’re not new, and they’re not a smoking gun: developers may have legitimate and non-obvious reasons for requesting certain permissions, and they may require them for reasons that aren’t immediately clear to the end user. Facebook, for its part, denied “reading of user text messages” and explained that the app requires SMS read/write to test an as-yet-unreleased feature.

These two stories follow different arcs, but the second one certainly seems to complicate the first. The clickwrap privacy policy that Apple agreed to require is exactly the sort of permission screen that has been ignored so consistently that a major newspaper decided to publish it as a scoop.

Raising the garden walls is too easy an answer to a hard question. The response to these two privacy stories makes clear that people want their privacy to be respected, which requires effort and resources on the part of the developer. How do we convince developers that those expenses are worth the cost before a PR fiasco about their privacy practices? I don’t know what the solution is, but it’s not expanding clickwrap privacy policies.


  1. Posted 1 March, 2012 at 06:27 | Permalink

    Well said… and I think there’s been an unfortunate amount of call for “this is why we need even more heavily locked down DRM’ified systems to protect users.” But I think the same type of thing can be done without DRM: for example, on a completely DRM-free Debian environment, one could imagine a list of packages that are keysigned by some “safety screening” third party, and an installer that helps users only select those packages. The user wouldn’t be *forbidden* to install anything else, but there could be indications that “these things are certified as safe”.

    I think that’s possibly a safer solution.

  2. Parker Higgins
    Posted 5 March, 2012 at 00:58 | Permalink

    Hey Chris,

    Absolutely. The first time I saw the Mac App Store, my first reaction was: “What took them so long?” I think the software repository model on Debian and elsewhere is an obviously good thing.

    What the Mac App Store needs, though, is the ability to add alternative repositories. A guy can dream, right?

    (Incidentally, the new Mac OS X installation process is close to what you describe. They’ve ominously named it Gatekeeper [right?!] and it provides a bit of that hybrid component:

  3. Posted 5 March, 2012 at 05:59 | Permalink

    Yes, Gatekeeper has the optional “you can turn it off” feature right now. Unfortunately, I think it’s really there to boil frogs more than anything else… my suspicion is that it won’t be long until you have no choice but to only install software from apple’s app store, even on your desktop. :\

    In the meanwhile, gatekeeper looks kind of like something I described, but a lot more “enforceful” of it. Unfortunately I think instead of being a system that helps educate users to what’s known to be safe and not, it’s on the path to something a lot more dystopian.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>