Hacker News new | comments | show | ask | jobs | submit login
[dupe] Snapchat images that have "disappeared forever" stay right on your phone... (sophos.com)
62 points by jmngomes on Nov 11, 2013 | hide | past | web | favorite | 50 comments

All the crypto stuff he suggests is absolutely stupid.

The fundamental concept of snapchat is impossible. It's the same problem as DRM. You can't control how somebody views some content because as long as they can see it, they can copy it (even if they magically fixed all screenshot and 3rd party app issues, you could always take a picture of the phone screen)

Doing all that crypto stuff is the equivalent of using 6 locks on your bikes wheel. No matter how good the locks are, it's still going to get stolen by removing the wheel.

Them not removing the images client side is a bit bad, yes, but 99% of people who could recover images like that could recover them 101 other ways

It's not impossible or stupid. His crypto proposal is to protect you from (or at least limit) the impact of any malicious action by Snapchat or anyone they may turn images over to (the police for example). I'm sure that isn't the biggest concern for Snapchat users, but it's still a worthwhile precaution.

Of course, for a company valued at billions (hah!), implementing anything that can get them in to hot water with the authorities, or breaks the user experience, isn't going to happen just before or after an IPO or buyout.

Not really, his crypto propsal doesn't protect you from any malicious action by Snapchat, and thus they is pretty much useless. You either trust Snapchat or don't. Having Snapchat create for you private keys and thinking that now your data is more private is naive

Right, but everything clientside can be audited. Especially on Android where decompiling apps practically gives you source code.

> is crypto proposal is to protect you from (or at least limit) the impact of any malicious action by Snapchat

but...his proposal involves trusting snapchat... so it's completely useless.

Even if they did implement all of it, at any point they could update a backdoor into it and you would have no way of knowing.

It's essentially the same problem as javascript crypto[1]

  [1] http://www.matasano.com/articles/javascript-cryptography/

I don't agree with this argument. To me, it sounds a lot like the one that was used for a long time to justify Chrome showing stored passwords in plaintext without prompting for a password: "the only strong permission boundary for your password storage is the OS user account".

While in theory yes, a system is only as secure as its weakest component, this completely misses the point that what we're trying to prevent here is casual spying and that the person receiving the content is not always the one you want to guard against. True, if you don't trust the one you're sending pictures to there is nothing you can do, but that's not a reason to make all other types of spying effortlessly easy.

Because users believe (whether they're right to do so is beside the point; fact is, they do) their messages disappear from the target device, they might be compelled to send photos that are a bit more private in nature than those they'd usually send through other channels. Most often, what you want to prevent is curious third parties ("friends", jealous boyfriends or girlfriends, the police) who somehow got access of your phone from easily accessing all the pictures you've ever received after the fact, and properly deleting images after reception (which I believe they now do, as this issue has been known for a long time now) would actually achieve just that.

Not removing the client side images is not the bad bit. It's the marketing blurb that claimed they did exactly that.

A startup misrepresenting their capabilities and not really caring about user privacy or security?


Exactly. My brother in law RE Snapchat to save all images it reads to his SD card. It took all of 10 minutes.

Even if they could lock down the phone and successfully implement a DRM I could just take a dang picture of the picture....

Removing the image client side is the whole point of this application. It's not just "a bit bad", in my opinion it's entirely dishonest.

Good God. If true, this is deplorable. As a mobile dev, client-side image caching is one of the easiest things you can do. When an image expires, nuke it off the filesystem.

There are a million and one ways to compromise a local image cache that's intended to be private. You can potentially recover it from the NAND flash if you're sophisticated enough, you can decrypt the data while it's still alive, but deleting the image when you said you would is, well, a pretty basic feature that would prevent the easiest of easy attacks.

I'd expect this sort of thing from an app where people are sending private images, against the initial intent/design. But Snapchat?

What about snapchat makes you think it is some kind of uber-secure private picture messaging app? If they represent it as that, then it's very misleading, but do they?

The analog hole makes this app a fun game at best, it's certainly not secure in any way, so I don't see why this is a big deal. By sending a photo to someone, you are leaking info, and if they can see it, they can copy it trivially with a cameraphone (far more trivially than by trying to get it off a locked down file system on something like ios).

As a mobile dev, how would you stop users from taking a screenshot? My girlfriend uses snapchat with her friends a lot and if she is quick enough she can grab a screenshot of the snap, I assume other people are doing this often.

The short answer is there really isn't a way to prevent screenshots. Snapchat has attempted to do so, but without much success. On iOS, it detects if either of the two buttons required to take a screenshot are pressed, and hides the image right away - preventing a screenshot unless the two are pressed truly simultaneously. In my experience, this works much better than on Android, where phones have a variety of ways to screenshot, and no great method exists to stop people from taking one.

You can't. You stop the attack vectors you can and inform people about the attack vectors you can't do anything about.

In this case, making sure the file isn't on the device longer than it should be.

Keep in mind, when it comes to extracting images, you can't stop a sufficiently informed or sufficiently determined end user, because all of your code runs on a device that's wholly in control by the end user. All you can do is basic due diligence.

There is the side problem where the attacker isn't the end user (e.g., malware attempting to extract private images from a phone). At the end of the day though, there is squat all you can do against code that has root.

I am not a dev but is there a way to know when one of the two screen buttons is being pressed? If so, and it'd have to be almost immediate, but you could fuzz the image or make it go black so the screenshot is black. Is this possible?

On iOS at least, both of these pieces of information are not available to developers, because both buttons perform OS-specific tasks which apps are not allowed to interfere with.

Contrary to some other platforms (to my knowledge, most notably Android), iOS apps are very sandboxed.

They're somehow available to Snapchat since they'll send you a notification if someone takes a screenshot of a snap.

Edit: I have personally confirmed this on iOS. According to a commenter below, this is also true on Android.

You can't really, and that's fine. Just after a snap has reached it's time limit - literally delete it. That's all you have to do to prevent snaps from staying on the system.

That requires the Snapchat application, or an associated service, to remain running in order to delete the cached image. A quick user could kill -9 the app and leave the image on the filesystem.

You get a notification if someone on android took a screenshot of your snap.

>I'd expect this sort of thing from an app where people are sending private images, against the initial intent/design. But Snapchat?

The thing about Snapchat is that it's basically held together with sticky tape and string. It's not totally dissimilar to where Facebook was a year or so from launch (2006 or so): code that was pretty much thrown together, and hasn't had much time for improvement.

I haven't seen the codebase itself, but I'm coming to this conclusion based upon pulling apart both the client apps and the god-awful API that's used. Perhaps in the last few months it has improved somewhat, but it was still pretty dodgy back in May or so.

Good God. If true, this is deplorable.

Their startup game isn't about engineering quality, it's about rapid growth at all costs. In this game, you aren't even a product—you're just something to be walked all over.

When you think Snapchat, go back to their origin stories: http://valleywag.gawker.com/snapchat-had-the-frattiest-creat... and http://valleywag.gawker.com/snapchats-creator-another-spoile...

So hilariously sad.

The issue is six months old. I think snapchat fixed the bug.

This is exactly what has happened.

as someone who's just read the article and installed snap-chat on both phones, colour me disappointed.

Worrying about this is like worrying that it's possible for your Scrabble Mobile opponent to secretly use a dictionary.

This is exactly why Telegram rocks.

From http://telegram.org/privacy:

Secret chats use end-to-end encryption. We do not store your secret chats on our servers. We also do not keep any logs for messages in secret chats. What this all means, is that there is no way for us to know who or when you message via secret chats — as soon as the messages are delivered, they're gone. And there is no way for anybody, including us, to learn what was in those messages, photos or videos. For the same reasons secret chats are not available in the cloud — you can only access those messages from the device they were sent to or from.

And from [the FAQ](http://telegram.org/faq#q-whats-this-encryption-key-39-thing):

When a secret chat is created, the participating devices exchange encryption keys using the so called Diffie-Hellman key exchange. After the secure end-to-end connection has been established, we generate a picture that visualizes the encryption key for your chat. You can then compare this image with the one your friend has — if the two images are the same, you can be sure that the secret chat is secure and no man-in-the-middle attack can possibly succeed.

Note: I'm in no way affiliated with Telegram—I just happen to think it's a great piece of software and deserves more highlight.

And Telegram [supports](http://telegram.org/faq#q-how-do-self-destructing-messages-w...) true self-destructing messages.

This isn't the problem the blog post talks about.

The issue isn't the security of the network layer for Snapchat, it's the security of the data once it's on the devices.

Which is to say, when the message self-destructs, it doesn't actually self-destruct on the device, at least not fully.

How does the Diffe-Hellman key exchange happen? How do you know that Telegram is not secretly intercepting the keys? Based on the FAQ, it looks like they are using some form of RSA public/private keys. Does each user have their own set of keys signed by a CA? Has the source code been vetted on both client and server side to ensure that the encryption is happening properly?

There are a lot of problems with just saying "it's encrypted."

Every time I see "snap chats can be screen shot" I get frustrated. This seems to be a trivially solvable problem. Most smart phones can display 60 frames per second or more. The human eye registers about 20-30 frames per second as fluid. Thus, couldn't you write an algorithm to cut the photo into 4-10 non-overlapping masks, and play those bits sequetially as a pseudo movie at 60+ fps. To the human eye it could look nearly or totally like a static image but to any camera it would be broken image (like taking a picture of an old CRT monitor, or worse)

Am I missing something about what would make this hard or impossible? It just seems like such an obvious solution to me.

Not all smartphones are able to continuously display parts of pictures at 60 fps (at least, not at a constant 60 fps), and in any smartphone that would result in very increased battery drain (and increased heat) when displaying pictures.

Assuming everything worked as described, people could always take video screenshots, or record the screen with a camera (30+ fps is very common these days).

Would the battery use be much worse than playing video?

If one takes into account the fact that most smartphones have video coprocessors that speed up video decoding a lot (while reducing the battery usage), but which aren't quite appropriate to display that kind of "image puzzle" (that would be more in the GPU/CPU 2D acceleration field), unless the "puzzle" is comes encoded as a video, I would say the battery would be more drained than when playing video, yes.

It would waste huge amounts of battery, provide a worse user experience (would take longer to load, and would make images darker) and barely do anything to solve the problem, 3rd party apps would still be able to scrape it, as well as taking pictures of your phone screen, or just stitching together screenshots.

having to use a 3rd party app or having to collect a bunch of different screen shots to stitch together is a lot more work.

Brightness seems a real potential problem.

Load time and total battery/CPU consumption seem to be things that would be algo dependent.

I don't know how the "screen shot" works for a given phone, but it seem your solution could work.

But it would still be possible to just videotape a snap.

Yes, it was obvious after you explained it.

That's high praise in my, and Douglas Adams book.

I remember a while ago someone had done just this as a proof of concept, it worked really well.

Can anyone suggest why this might be the case (presuming that it is true)? It seems to be much more work to hide the image vs. simply deleting it, so I'm guessing that there is a reason...

I haven't seen the Snapchat codebase at all, but my knee-jerk suspicion is use of an off-the-shelf image cache.

Caching images on the device is basically a universal problem for mobile apps. It improves responsiveness and prevents unnecessary network usage. As such, there are open source libs that do all the boring heavy lifting for you.

Most images caches also don't hold sensitive images, nor do they really expire.

In this case, you may have deleted the database row around the post, but the image cache still has the image on-disk.

sounds like developers pre-occupied with style and fancy coding rather than efficiency and performance.

I never assumed the purpose of snapchat was provide bullet-proof self-destructing images, in the same way that I wouldn't assume the purpose of a lock on a diary or medicine cabinet was to provide bullet-proof physical security.

I assumed the purpose was to shift the expectation of reasonable behavior from "keep for as long as your like" to "let the image expire".

If you send someone an image via email or some other platform, it's perfectly reasonable for them to keep the image in their archives forever.

If you send someone a snapchat, the expectation of reasonable behavior is to let the image expire and disappear. If one discovered that someone was using clandestine means to keep snapchats sent to them, that person will suffer social repercussions.

In other words, snapchat have created a system where it's creepy to keep snaps forever, against the will of the sender. Yes, it's possible, perhaps even trivial. But it's also trivial to rummage through a friend's underwear drawer when visiting their home. The "security" of the underwear drawer is established by trust and social convention. That's how I feel about snapchat. It's an easy way of saying "please don't keep my messages".

The crypto solution he proposes is the same as employed by TextSecure* for encrypted SMS. The problem from a user experience perspective is that it requires a secondary channel of communication like a face-to-face meeting or a secondary IM service for key exchange.

* https://play.google.com/store/apps/details?id=org.thoughtcri...

I just can't get upset about this.

I think a root problem here is a lack of understanding of the modern nature of information. Nobody fully understands it yet, but here is an example of some that are less aware of its properties (users of Snapchat) and something that is obfuscating it further (Snapchat).

Encryption does not fully seal the analog hole, at best it is suitable for protecting structured groups of bits until they must be prepared for crossing the analog gate.

The only way to have exclusive control of any analog or digital property is to exclusively own all access vectors to it. Any form of communication that is not neuron-based removes this lock by necessity, permitting various external channels and receivers access.

Share freely or share nothing - possibly not just a zealous philosophy, also a honest reflection of reality.

I use Snapchat, and loads of my friends use it. I have never met a single Snapchat user who is under the false impression that there is any guarantee that their messages will be deleted. The 'self-destruct' feature is just a fun twist on picture messaging; nobody would rely on it for securing sensitive info! Have a bit more faith in people's intelligence.

All this hand-wringing is by non-Snapchat users who have read about the app in the media and completely misunderstood what it is for. It's just for sending funny pictures to your friends, not for sending PIN numbers or secret mission briefings.

so much for unlink(filename);

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact