Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In the end the application needs a key to decrypt the storage. That key has to be stored somewhere on the device. On a rooted phone there is no place out of reach, so all they can do is make the storage obscure. Unless the hardware provides some inaccessible secure thingy there's not much they can do... I guess even if it did a script like that could access the secure thingy via USB debug as well.

I don't think the developers are to blame. They did what they could.

The real problem is that snapchat promises something it can not technically deliver. Once a photo leaves your phone and is delivered to somebody else, you lost control over that photo.



The real problem is that snapchat promises something it can not technically deliver. Once a photo leaves your phone and is delivered to somebody else, you lost control over that photo.

It's precisely the same problem with DRM. You either lock down everyone's devices against their owners (a massive "do not want" situation) - and then you could still copy the data via the old-fashioned analogue hole (I'm not including the truly disturbing idea of adding implants to people's brains that force them to "delete" something they've seen) - or accept the inevitable fact that data that can be accessed is data that can be copied.

Quite frankly, Snapchat is a form of DRM, except it's marketed toward users in a way that makes it appear desirable.


> or accept the inevitable fact that data that can be accessed is data that can be copied.

I think this is something that is orders of magnitude easier for technophiles to accept than the average person.

Because to the average person it so so easy to delete data - they press the delete key and its gone! So they look at the problem and think the computer programmers just need to do a better job.

Whereas you or I realize that it virtually is impossible to prevent access of data - at least on a systemic level, and the problem (though in some cases it is the programmer's fault) isn't something that better programmers could fix.


No matter how secure they store the photo, at the end the day a simple screenshot makes it all for nothing. It would be cool if Android had some API to disable screenshots.


It actually has — Apps can prevent the system from taking screenshots by telling the DRM hardware chip that they are showing important data. Actually you can even prevent users from obtaining the data if you encrypt it with a secure key and store this key in the DRM hardware chip.

Only problem: Someone could still decompile your app, use your API and request the decryption keys.


Uhm, Android had an API to disable screenshots since forever - see http://developer.android.com/reference/android/view/WindowMa... . As soon as you add this flag to the Window, the contents will disappear from screenshots or device will refuse to make them (depending on Android) version.

The reason why Snapchat has screenshot notification is actually due to that API being absent from iOS for a long time.


And then people will just have a second phone (or camera) and take a 'photo' of the original screen itself.


Or, you could take a photo of the screen, if you wanted to save images you already have access to (something snapchat is supposed to prevent). The good old analog hole.


I believe that SnapChat alerts the sender if a screenshot happened. While this doesn't prevent the action, obviously, it at least lets the sender know.


They shouldn't store the images on the phone. You should be only able to view the image immediately after downloading it. After 10 seconds of viewing the image, everything gets deleted from ram.


It's also not difficult to bypass the app completely and poll the service from another program (for instance, run by cron on a server). Like other people have said, the entire premise is flawed.


I wouldn't say the premise of the app is flawed, rather it's just that people seem to misunderstand its technical capabilities.

Snapchat was designed for ephemeral communication, not secure "send-and-destroy" messages. It would be very foolish of them to market it as something it cannot possibly be.


Then you have to wait for the download every time you open the app.

This is an okay compromise tbh.

(They could offer a super secure option or whatever, I guess)


Actually you could just download the encrypted images without the unique key( for every image ) and then get the key on demand. Load the image into ram, decrypt, show the image and then erase everything.


That would be more secure, but you still need to wait for the key to be downloaded on-demand - you don't exactly get butter-smooth scrolling that way.

(I like security.)


And you would have to be connected to the internet. That is a problem. The delay could be hidden behind a ui.


Snapchat doesn't work particularly well offline...


I wonder why they didn't choose this path. A trade off for better usability ? Why would an app break it's core promise to offer better usability ?


Because it's still totally flawed? Nothing stops anyone from writing a program that pretends to be Snapchat and downloads the keys and images as it pleases.


If you hide a per-device API key inside the real Snapchat app, you might at least require that the user root the device before being able to grant an Evil App access to their photos.


How would you generate this key in the first place? I'd just write a program that looks like the Snapchat, generating the per-device key.


If you look at the link, even the current method requires root on the device.


I was thinking about Bad Apps that users voluntarily hand their login details to (so they can download snapchats they get sent). Those don't need root, since they're just mimicking the Snapchat app and receiving the photos directly.

But it doesn't work, since you need some way to generate new API keys for your second device... which could be a Bad App.

If you 1) enforce one key at at time (so one "device" at a time), 2) rate-limit key changes (if you switch to a new device, or Bad App, you can't switch back within a day or two) and 3) eliminate Bad Apps in the app stores- you effectively limit Bad Apps to being entirely web-based, and hopefully the restrictions on webapps will make the Bad App sufficiently a pain in the ass to use that people won't want to switch to it, even though it lets them save photos, since it locks them out of the real app.




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

Search: