ACLU's Mobile Privacy Developer Challenge

An anonymous reader writes "Privacy groups announced a mobile privacy developer challenge yesterday. The competition, Develop for Privacy, challenges mobile app developers to create tools that help ordinary mobile device users understand and protect their privacy. It's sponsored by the ACLU of Northern California, the ACLU of Washington, and the Tor Project, with the assistance of the Ontario Information and Privacy Commissioner's Office. Submission deadline is May 31, 2011. The winner will be announced in August 2011 at an event in Las Vegas, coinciding with the DEFCON and Black Hat security conferences."

Comments

Not Gonna Work

[WrongSizeGlass]

Unfortunately there are people involved in the ownership of these mobile devices (aka users). When users are involved security is always inconvenient, an obstacle or even a nuisance. People want security via magic, not actual implementation of secure and common sense practices.

Re:Not Gonna Work

[Anonymous Coward]

Can you let me have an email address for your gullible family member? I had a similar experience and I'd love to share it with them. Thanks!

Re:Not Gonna Work

[16384]

Unfortunately there are people involved in the ownership of these mobile devices [...]

Unfortunately you don't really own a smartphone, even one that isn't tied down to a contract and paid big bucks to carry around. The phone doesn't obey to you instead obeys to the manufacturer, to google, to the app developers, etc. It keeps sipping information and reporting it back to headquarters, and it's blocked in such a way that bypassing that is not practical.

I was surprised to find that android phones *require* a google account, or that a iPod Touch requires being connected with iTunes to start. A HTC Desire comes with lots of widgets running in the background that you can't turn off (and it's even worse on Android 2.2, Froyo) and the terms of service clearly states they may collect data on you (duh!). Many apps requires far more permissions than they should, so after a while you either give up and ignore the permission requests or don't use any of them.

Mobile privacy? Is there such a thing?

Re:Not Gonna Work

[Miamicanes]

> proper security measures is what makes things easy to use, not hard.

Amen. My job involves application security, and the biggest single problem I see is that most developers have no real understanding of what they're trying to defend against or why, and when told they have to make an application "more secure", their usual reaction is to make it as awkward and user-unfriendly as they can on the theory that it somehow makes the application more secure. Most of the time, their misguided efforts end up making matters even worse.

Case in point: an account gets locked out because too many attempts have been made to log in with invalid credentials. OK, fine. That's good. What's NOT good is giving the user some response like, "The server is having problems, please try again later." 1) by displaying that different message, they've just let the attacker know that something significant has happened, and that if the attacker was blindly trying usernames and passwords, he's probably just found a valid username by locking it out. 2) By telling the user to "try later", you're giving them false hope that the problem will somehow resolve itself on its own. If a user's account has been compromised, the LAST thing you want him to do is to forget about it until "later". You want him to call the helpdesk NOW. The ONLY case where intentionally lying to the user might be acceptable is if you're dealing with access to something EXTREMELY sensitive whose security is backed up by real-world people with guns who are going to come running to investigate moments after the user sees the "system error" lie (in which case the user, if legitimate, will have someone right there to assist him immediately anyway).

So, how would you make the login more user-friendly WITHOUT creating new vulnerabilities? Easy: here's the response you give when someone attempts to log in with an invalid username, a valid username with invalid password, or a valid username & password that have been locked out:

"The username and password you entered is not associated with a user account, or the account might have been disabled due to excessive failed login attempts. Please try again. If you believe your account might have been locked out, please call 888-999-2222 for assistance."

There. Isn't that much nicer? You aren't revealing whether or not the account is valid or what went wrong, but you're making sure the user understands that lockout is a possibility if he screws up too many times, and you're telling him who to contact NOW if he thinks it's locked out. You've made it crystal-clear to him that IF the account is locked out, he can retry forever and won't be getting back in, so if he thinks it HAS been locked out, he might as well call RIGHT NOW and get it over with. There's no need to lie to the user, waste his time, piss him off, or ultimately delay communication that someone might be trying to compromise user accounts. You're respecting the value of his time, and telling him how to get in touch with somebody who can solve his problem NOW (or at least explain why it can't be solved now). Note the exact phone number, and not vague instructions like "contact your network administrator" or "call the helpdesk". Why? For one thing, assuming the user even has the slightest idea WHO to call, he probably doesn't know the damn phone number. Too many programmers get the wacky idea that they're somehow enhancing security by making it harder to get in touch with someone who can fix the problem. In reality, the opposite is true. Real users don't know, and don't care. Attackers, on the other hand, will do hours of research to find out.

Re:Not Gonna Work

[Miamicanes]

You're assuming that there's actually a company phone book that a legitimate user would have ready access to. Quick... where's YOUR company phone book? Does it even exist in printed form, or (like most companies), is it all "online" now? Chicken, meet egg. Kafka's sitting on the bench over there, simultaneously groaning and laughing. And if it DOES exist in printed form, what's the likelihood that a remote employee at a hotel (or family member's house) with his laptop actually has a copy with him right then? No, "supposed to have it according to policy" doesn't count. When push comes to shove, statistically "nobody" will have it with them.

The truth is, real users NEVER know who to get in touch with, because until something goes wrong, they literally don't bother or care. Worse, most of the time, real users will get frustrated, say 'fuck it', and abandon the login attempt LONG before motivated attackers will. Printing the contact info on the back of something won't help, because it's the last place the user will look. Really. They've looked at it hundreds of times, but they didn't "see" it, because it didn't matter to them, it faded into the background noise and became effectively invisible. When crunch time comes, they won't even bother to look there, because they "know" it's not. If it were, they'd remember seeing it (so they theorize). The only way to ensure that a user with potentially-compromised account calls IMMEDIATELY is to make sure he knows beyond doubt that it's a possibility, and to put the number right in front of the user's face where he can't ignore it.

If anything, concealing the contact info opens the door to inverse phishing attacks. When a corporate user can't connect and has no idea who to call, guess where he's going to go first to try and find out? Google. Yes, Google. All the attacker needs is a reasonable-looking web site that looks suitably outsourced to India and VoIP service for a toll-free number, and our example pissed, frustrated corporate user will voluntarily spill his guts and tell the nice person who answers the phone whatever he wants to know. I know, because I've dealt with situations where it happened.

At the end of the day, would you feel safer a) making it easy for both attackers AND legitimate users to get in contact with security helpdesk staff with extensive training that includes hours of role-playing to recognize and deal with social engineering attempts, or b) hoping an employee who was forced to watch a lame, pompous, self-congratulatory exercise in legal masturbation posing as a "security training video" doesn't get misled into calling an attacker and spill his guts to someone staffing the phone lines for an organized crime syndicate?

Re:Droid Does

[Z00L00K]

True to some extent - but even if it does request something like internet access - what is it doing with my internet access? How much traffic will it generate? It may produce a humongous amount of traffic raising my phone bill to astronomical figures. This applies to everyone not on an unlimited agreement or as soon as international roaming occurs.

The question is sometimes like "Hey I need a hammer" - no real reason why the hammer is needed.

And if it wants to access your contacts - which part of the contact information is it going to access - and why. Maybe it's an app for chess and it allows you to do network chess with a friend.

I wish android let me *control* app access

[SuperBanana]

Here's a suggestion for anyone that's listening: Android tells you what access an application wants, and aside from minor problems like there being obscure reasons for why the program needs access to "make calls" (often this just means the program wants to be able to tell if you're *in* a phone call or not and behave appropriately), this is reasonably handy.

However, my main objection: you don't get to see this information in the marketplace, so you can't make a purchase decision based on it...and worse, you can't *control* what access a program gets. For example, a lot of programs request "coarse" location information, which is enough to tell where you are within a few blocks. I don't want my backgammon program to know my location, and I wish I had the ability to tell the Android OS "no, that's not OK".

It's an all-or-nothing approach that leaves me often feeling like my arm is twisted into accepting the app, often because there are no alternatives for the functionality I want...

Re:I wish android let me *control* app access

[hey]

Its in the market. Take a look again.

For example:
https://market.android.com/details?id=com.google.android.stardroid
and click on the PERMISSIONS tab.