Resultados 1 a 3 de 3
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,033

    [EN] Privacy Promises and Client-Side Betrayal

    Software can't be simultaneously open source on the client side and make promises about how the client side will behave. Actually, one can't really make that commitment even when the client side is closed-source (for example, if a closed-source app runs on an open source OS, then when the app tries to delete the message, the OS can retain a copy).


    Karl Fogel
    June 9th, 2013

    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 they do control their operating system. 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):

    surespot:

    “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.”

    Priv.ly:

    “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

    Wickr:

    “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.)

    Hush Box:

    “Secure, self-destructing email.”

    (I don’t know anything more about this one; there’s no further explanation on the page, beyond the above.)

    Silent Text:

    “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.]

    Confide:

    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.]


    (continua)
    Última edição por 5ms; 21-02-2016 às 12:05.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,033
    (continuação)

    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.


    (continua)

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,033
    (continuação)


    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!”

    http://www.rants.org/2013/06/09/priv...side-betrayal/


    Update 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.

    Update 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.

    Update 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.)

    Update 2014-01-29: A shorter and less technical version of this post is now published on Slate / New America Foundation “Future Tense”: Privacy Apps Like Snapchat Make a Promise They Can’t Keep.

    Note: 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.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •