At the end of the post is a list of updates about new client-side betrayals I’ve noticed since this was first written in mid-2013.
I published a slightly less technical version of this article in Slate Magazine as part of the New America Foundation’s “Future Tense” series in January 2014.
Some apps are making an impossible promise, one that these days might really matter to people. The promise is this:
“You can control the copies of data you send to other people.”
You can’t. It’s not even possible in principle. If an app promises that you can send people email messages, photos, audio recordings, or videos that will “self-destruct” or “can only be viewed for a limited time controlled by you” or “can only be viewed by people you approve”, just smile and back away slowly.
These promises all depend on client-side betrayal. That is, they depend on a device obeying commands from someone other than its owner. For example, a smartphone that does what the phone manufacturer — or mobile carrier — wants it to do, instead of what its owner asks.
Now, it’s true that some devices actually do practice client-side betrayal. This is one of the reasons I don’t own a Kindle.
But when you send someone a message or a photo, how can you be sure they’re using a device that will betray them? You can’t. You can’t count on their device serving your goals instead of theirs.
You might think apps only make such promises for platforms where they can count on the recipient’s device being of the betraying sort. But app designers can never know for sure that the necessary betrayal will occur as required. To start with, many apps run on Android devices, after all. The Android operating system is open source (admittedly on a very long release cycle, with various manufacturer-specific proprietary divergences along the way, but still, in the long run it is open source). A sufficiently motivated user could modify their Android device such that every frame written to the screen or every sound written to the speakers is recorded to the SD storage card. That video may have self-destructed as advertised, but that doesn’t really matter if there’s a perfectly good copy still sitting in permanent storage. Heck, while we’re at it, why even believe the deletion happened at all? An Android user could modify the OS-level delete system call to not actually delete, but rather move the file over to an easily-accessible holding area from which recent items can be rescued if the user decides they’re interesting enough. (This is not so different from how most OS delete calls work already. Feeling safer yet?)
Everything I said about Android above applies to any open source operating system: GNU/Linux, Firefox Mobile OS, all of them.
If the user controls her operating system, then she controls her data, period. And open source means users do control their operating systems. They don’t necessarily have to know how to program, they just have to know how to hire people who can program — just as they don’t have to know how internal combustion engines work to hire a mechanic to fix their car.
Open source means no client-side betrayal, at least for people who care enough to avoid it.
Anyway, even without open source operating systems, the recipient can still save it old school: just point another camera-enabled device at the screen and take a picture.
Who’s depending on client-side betrayal?
Full disclaimer: I first started noticing this trend through my work with OpenITP, but the opinions here are entirely my own. The users and developers OpenITP works with are people who need to be able to take privacy promises seriously; as a result, I’ve become more sensitive to those promises than I used to be. When someone makes a promise that conflicts with my technical understanding of how the digital world works, I start asking questions.
Here is a partial list of apps that have caused me to ask questions lately (emphases added):
“You can delete your message from the receivers phone.”
“Be confident sending private information and pictures. You have control over your messages, when you delete a sent message it will be removed from the receivers phone and images are not sharable unless you make them so.”
“Privly makes it possible for you to control your data after posting it across the internet. You can post to Facebook without allowing Facebook access to your communications, you can even unsend emails…”
[Update: Priv.ly improved their language after this post was originally published; the claims on their web site seem to be much more accurate now.]
Snapchat (from their blog):
“Deleting Snaps From the Recipient’s Device”
“After a snap has been opened, the temporary copy of it is deleted from the device’s storage. We try to make this happen immediately, sometimes it might take a minute or two. The files are deleted by sending a ‘delete’ instruction to the phone’s file system. This is the normal way that things are usually deleted on computers and phones — we don’t do anything special (like ‘wiping’).
Extra Details
While an unopened snap is being stored on the device, it’s not impossible to circumvent the Snapchat app and access the files directly. This isn’t something we support or encourage and in most cases it would involve jailbreaking or ‘rooting’ the phone and voiding its warranty. If you’re trying to save a snap, it would be easier (and safer) to just take a screenshot or take a picture with another camera.
Also, if you’ve ever tried to recover lost data after accidentally deleting a drive or maybe watched an episode of CSI, you might know that with the right forensic tools, it’s sometimes possible to retrieve data after it has been deleted. So… you know… keep that in mind before putting any state secrets in your selfies :)”
“sender-based control over who can read messages, where and for how long”
“[Wickr can] send text messages, videos, documents that self-destruct — all encrypted, and it exceeds NSA top-level encryption on the device before it goes out on network with a key that only you have.” (Founder Nico Sell quoted in Silicon Beat.)
“Secure, self-destructing email.”
(I don’t know anything more about this one; there’s no further explanation on the page, beyond the above.)
“Self-Destruct any message, file, photo, video or voice recording with our timed Burn Notice.”
[Note: I added this one on 2013-09-04, long after this post originally appeared, because I ran across this article.]
The Confide app turned out to be a kind of Greatest Hits of impossible privacy promises:
“Messages disappear after they’re read, ensuring all of your communication remains private, confidential and always off the record.”
“…we alert you if a screenshot is attempted.”
“Get alerted when your message is read.”
“…allows you to speak freely, without a risk of what you say being forwarded on or permanently stored…”
“We alert you (and the recipient) if the recipient attempts to take a screen shot.”
And my personal favorite: “Notify me about Confide for Android.”
[Note: added this one on 2014-01-09, after this post originally appeared, thanks to this article.]
Google Spreadsheets and presumably Google Docs in general offer the document owner an “Export options disabled” mode. Someone with whom the document has been shared will see this message if they try to download a copy of the document they’re viewing in their browser: “The owner has disabled options to download, print, or copy for commenters and viewers on this file. Learn more.“ Google is assuming a certain amount of cooperation from the user’s web browser. That assumption cannot be relied on in general; although presently most user’s browsers are by default cooperating with Google in this regard, they may not always do so (a sufficiently motivated user could change the situation right now, in fact — no new technological developments are necessary, just a little work under the hood of the browser).
Confusing the Threat Models
What these promises have in common is that they confuse two very different threat models. One is the scenario where you’re communicating with an ally — someone who, as far as you know, has no intent to do you harm, though they could do so by accidentally re-sharing something. The other is the scenario where you’re communicating with a stranger or with someone who might actively intend you harm.
The “Extra Details” section in the Snapchat marketing quote above is a particularly good example of this confusion. Somewhere between the first and second sentences, they subtly switch whom they’re addressing. This first sentence is clearly to the sender:
“While an unopened snap is being stored on the device, it’s not impossible to circumvent the Snapchat app and access the files directly.”
Then suddenly they switch to talk to the recipient…
“This isn’t something we support or encourage and in most cases it would involve jailbreaking or ‘rooting’ the phone and voiding its warranty. If you’re trying to save a snap, it would be easier (and safer) to just take a screenshot or take a picture with another camera.”
…then just as suddenly they switch back, still without any explicit acknowledgement that they’re talking to two different parties with possibly different interests:
Also, if you’ve ever tried to recover lost data after accidentally deleting a drive or maybe watched an episode of CSI, you might know that with the right forensic tools, it’s sometimes possible to retrieve data after it has been deleted. So… you know… keep that in mind before putting any state secrets in your selfies :)”
That middle portion, where they talk to the recipient, could be translated to “For our sake, please don’t interfere with the process of your device betraying you.” Recipients in the first threat model will cooperate; those in the second threat model won’t.
Ultimately, these apps aren’t really about security and privacy. They’re about convenience in situations where dependable privacy isn’t a requirement. An app that deletes a photo after showing it to your friend for six seconds is just a convenience for everyone involved. It makes things easier for both parties: Hah hah, look at this picture of me stuffing a hundred dollar bill into his sock while he pours a margarita down my throat! Wasn’t it a great vacation? Wish you were there. No need to worry about deleting this photo; it’ll take care of itself. See you Tuesday at the office.
That’s fine, if that’s all you wanted. But the vast majority of people who read the marketing around these apps will take them at their word. Wow, I can send an email that self destructs immediately after the recipient is done reading it? That’s great! It’s like attorney-client privilege without the expensive law degree. Where do I sign up?
People don’t think about threat models. They think about features and promises. If the app says it does X, they believe it does X.
The trouble is, problem recipients are not evenly distributed across all the pictures and emails and videos one sends. The problem recipients are concentrated in the sensitive items, because the temptation to be a problem recipient is highest exactly for the things a sender would most want deleted. Or as the great saying has it (attributed to both George Orwell and Paul Fussell): “What someone doesn’t want you to publish is journalism; all else is publicity.”
Most people who come to my front door are honest, but the lock on the door is not for them. Promises of client-side cooperation are pointless, from the sender’s point of view, if they are most likely to be circumvented by those most tempted to harm the sender in the first place.
One more example, just to drive the point home.
Some mass email services — “mass email” is not a euphemism for spam, by the way; these services are tremendously useful, helping legitimate organizations run their announcement email lists, etc — promise to tell you how many recipients have opened the email you sent.
“Whuh-huuuh-whaaat??” I thought to myself, when I first heard about this. How on earth can anyone else know whether I’ve opened up an email, let alone whether I’ve read it? My mailreading software does not send signals to third parties when I open messages. That would be an incredible betrayal of my trust.
And yet there are these services, promising exactly that. Here’s Mailchimp (the quotes below are from their Features page and their Reports Overview page):
MailChimp’s free reports tell you who’s opening, clicking, and coming back for more…
Our interactive graphs show you how many emails were delivered, how many people opened your email…
Opens by Location: See where in the world your subscribers are located and track engagement by country.
A/B Split Testing People who A/B test their email campaigns get 11% better open rates and 17% more clicks…
It turns out — surprise! — that they’re depending on client-side betrayal, of course.
These days, most people are reading mail in their browser, using one of the online services like Hotmail, etc, or in some other network-enabled email client. And when those email clients get an email that includes an image, they will (in some cases) display images by default — even if the image content isn’t embedded inside the email, but rather is merely linked to from the mail and has to be fetched (at the time the message is opened) from somewhere out on the Internet.
So what these services do is include a tiny image, just one pixel large and, if possible, the same color as the message’s background color. But they don’t include that pixel directly in the mail. Instead, they keep it on their own servers, at a URL unique to that particular message. When the recipient opens the message, their mailreader fetches all the images, even the tiny & invisible ones, and it is by receiving the request for the image at that unique URL that the upstream service knows the mail has been opened.
Some browser-based mailreading services have image display turned off by default, which avoids this betrayal. Google’s Gmail was one of them, until recently, but they have started transitioning to showing images by default, and their notice about the changeover explicitly warns users that this will allow some senders to know whether a mail has been opened. I’m not sure about the other services (if anyone knows, please leave a note in the comments).
Possibly Mailchimp talks about that somewhere, though I didn’t see it if so. The part that I saw just tells senders that Mailchimp can determine the “open rate” for the emails they send out. If Mailchimp has statistics on what percentage of email users set images to display by default — thus making themselves vulnerable to at least one kind of client-side betrayal — that would be very interesting; I don’t know if they do.
It turns out there’s a history here.
I showed an early draft of this post to my friend Jeff Ubois, and he instantly thought of who had covered this ground already. There’s a 2009 book by Viktor Mayer-Schönberger called Delete: The Virtue of Forgetting in the Digital Age; I haven’t read it, but the discussion with Jeff made me wish I had. There’s also an article by US Federal District Judge James Rosenbaum called In Defense of the delete Key”, published in the law journal The Green Bag, about how the Delete key doesn’t actually delete (as I touched on earlier).
Client-side betrayal can have consequences both social and legal. Phrases Jeff tossed out include “inadvertent waiver rule” and “spoliation of evidence”. The sender’s request to delete may still be considered an expression of intent, and that can be legally useful under certain circumstances. Pity about that photo appearing on the front page of the New York Times, but at least it won’t be admissible in court because you tried to ensure the recipients would delete it. That’s some comfort, anyway.
So here’s my promise to you:
If you send me something in digital form, you cannot count on me — or my devices — deleting all my copies of it unless I explicitly tell you they’re gone. The copies I receive from you will continue to exist as long as I want them to, and whether I share them with others is entirely a matter of social conventions and of honor, not of technical enforcement from your side. You also can’t be certain that I have not read an email you sent; you can be certain I have read it if I say I have, or if I reply to it.
But really, these are just the same promises the rest of the Internet makes. If someone thinks otherwise, it means they’re depending on client-side betrayal by your devices — but it’s up to you, not them, whether that betrayal happens.
Or as my friend Jim Blandy puts it: “It’s my computer, damn it!”
Updates since original post, in reverse chronological order:
2021-05-31 Hey, I don’t want to make a federal case of it or anything — okay, sorry, couldn’t resist — but Snapchat’s inability to actually control other people’s copies of images has now led all the way to the U.S. Supreme Court, in Mahanoy Area School District v. B.L.: “The case arose after Brandi Levy … a student at Mahanoy Area High School in Mahanoy City, Pennsylvania, posted an angry, profane Snapchat message from an off-campus location upon learning near the end of the 2016–17 school year that she had not earned a place on the school’s varsity cheerleading squad for the next season. A screenshot of the self-deleting message was saved [by another student] and seen by school officials, who suspended the student from cheerleading for the next year, on the grounds that she had signed and was subject to a school district policy prohibiting such speech on social media.”
2020-09-29 Philippe at Missive writes about how they decided to abandon read-tracking (a classic use of client-side betrayal) for their email-sending service, though he still seems to have a very limited view of what constitutes “abuse” of that misfeature.
2019-11-04 Thanks to the EFF for pointing out this creative proposal for client-side betrayal: client-side scanning for forbidden content. I can’t even… I just can’t even. This idea is so bad in so many different ways that I’m going to give up trying to describe it and say that if you’re suffering from a shortage of bemused outrage today, you should go read their post about it.
2019-08-13: A pretty extreme example: it turns out that getting deplatformed from Apple’s online services breaks all your Apple-controlled devices. Who could ever have seen this coming?
2019-07-30: Some web publishers rely on client-side betrayal to support their N-free-articles-before-paywall model, and will have to change now that browser makers have (finally) started favoring user control and privacy. The linked article does a decent job of explaining the issue.
2019-03-20: The newly-announced Gmail Confidential Mode relies completely on client-side betrayal. Their announcement ignores the question of how they can make these kinds of confidentiality promises for email (hint: they can’t). Email is one of the least-centralized services on the Internet. Senders know nothing about the software receivers use. Either Google can’t keep the promises they’re making, or this isn’t actually email and they should stop calling it that. It’s striking how they frame the situation of users who don’t use Google-controlled products to read email — note especially the second sentence below:
“Note: Although confidential mode helps prevent the recipients from accidentally sharing your email, it doesn’t prevent recipients from taking screenshots or photos of your messages or attachments. Recipients who have malicious programs on their computer may still be able to copy or download your messages or attachments.”
Do they mean “malicious programs” like… any non-Google-controlled mailreading software? E.g., Mozilla Thunderbird, or Emacs Gnus, or any of the other non-Google mailreading software listed here?
Finally, see also this Tutanota blog post about Gmail’s so-called confidential mode.
2016-10-12: Kudos to Open Whisper Systems for honesty in advertising. They’ve implemented a new “disappearing messages” feature in their Signal app, but their announcment of the feature is completely up front about what situations it’s good for. The second paragraph spells it out:
“Disappearing messages are a way for you and your friends to keep your message history tidy. They are a collaborative feature for conversations where all participants want to automate minimalist data hygiene, not for situations where your contact is your adversary — after all, if someone who receives a disappearing message really wants a record of it, they can always use another camera to take a photo of the screen before the message disappears.”
2015-09-13: An almost too-good-to-be-true laundry list of client-side betrayals may be found in this post about the service & free software at canarytokens.org.
2014-10-11: So that thing I predicted in this post — the thing where people hack their client-side software to defeat Snapchat’s so-called protections — has now happened. See also this story, which is also really about client-side betrayal even though it at first looks like it’s about a server-side security issue.
2014-05-08: It’s nice to see that the New York Times — and the U.S. Federal Trade Commission! — have caught up with this problem: Off the Record In a Chat App? Don’t Be Sure: Case Against Snapchat Tells Users to Beware. (Compare it with this rather less skeptical earlier story in the Times from February 2013.)
For a more general examination of the importance of people having control over the hardware and software they use, see Neha Narula’s excellent piece Who Really Owns Your Phone? from January 2013.