Hacker News Reader

Comment by judofyr | Hacker News Reader

Even better: Let the application also say why it needs the permission:

    * Read access
        We want to analyse your tweets
    * Read/write
        Because we want to spam your friends

View on HN

Both OS X and WinAPI do this now. Users (in general) hate it. You make a good point, but it's going to have little impact in the real world. People livin' in that 21st century do it better'n anybody you ever seen do it and they want their Kanye analysis now; they ain't got nothin' to lose! They rollin'!

I am deadly serious.

Users dislike it on Windows because requesting elevated privileges became so common that they rationally chose to tune out. Had Windows been designed from the start with UAC, developers would have been less cavalier in requiring administrator abilities, then maybe a UAC request might actually have meant something. Given that so many legacy games request privilege authorization, it's no wonder the users don't take it seriously.

Look at the mobile platforms for an example of implementing this idea correctly. Android users, the same who are likely to detest UAC, rave about the ability to see which parts of the system an application accesses before they install it. I'm an iPhone user, and I've always appreciated its piecemeal approach to authorizing location and notification services.

Zach's article is about making the message more meaningful, such that it's not just another automatic clickthrough. My guess is that users would much prefer this screen to what twitter is using now.

> "Had Windows been designed from the start with UAC, developers would have been less cavalier in requiring administrator abilities"

Android and the Android Marketplace appear to contradict that theory.

Your point about Android is half correct, yes I like seeing what the app needs to access, but I don't see why. Why does your calculator app need access to the internet? I know the author can just offer some bullshit excuse, but it's better than nothing...

I would very much like the checkboxes in Android too, although obviously they'd place a greater burden on developers. For example, I tried installing the official XBMC remote app a while back; it requested all sorts of crazy permissions ("read SMS" etc) which they were intending to use for debatably useful features but I ended up not installing it because of the privacy concerns. In the end I installed a third-party remote app which didn't ring as many alarm bells on installation, but I'd have been happier to stick with the 'official' one if I could selectively disable some of the permissions they wanted.

I can certainly see why that isn't an option; it'd make things much harder for developers if they suddenly have to test against different sets of security permissions. But it's on my wishlist.

Oh, no, I don't need checkboxes (I realise it would make development hard). I only need a justification under each permission to see if the app has a good reason to want to read my texts, but I'm quite happy denying it as a whole.

XBMC remote needs that because it has a "show your texts on the TV" feature which you really, really shouldn't turn on. Trust me.

It's a shame that you can't pick and choose, as a user, because they can't remove that permission without breaking that feature for everyone [who?] that uses it. It's open-source though, so the good news is you could remove that permission and feature yourself if you really want it (you should: it's pretty nifty).

They need access to the internet so they can dynamically fetch the ads they are going to show you which is where they get their money from.

This has the advantage of generally being true, and being unobjectionable enough that most people will grant access.

That was an example, though.

There is a difference, though, OS X and Win apps ask for things that generally make no sense to a user, even if the app tried to explain them. 'I'd like to send tweets pretending to be you' is at least mildly meaningful unlike 'I'd like to BE you' which is the sort of permission desktop apps are stuck asking for.

> Both OS X and WinAPI do this now. Users (in general) hate it

Actually, I rarely see it popping up on OSX so I don't have much of an issue. Win7 on the other hand is downright dreadful: the whole screen flickers (not fades, mind you, you get the impression that the screen just shut down before you see the UAC window pop up) to black (and it manages to lag, which is terrifying), then your content reappears behind a lightbox and you end up with a small UAC window in a random position on one of your n screens (where n > 1 for me), unless somehow an other software has managed to steal focus and then all hell breaks lose (the program which started the UAC prompt will not respond, but I believe it does not focus UAC automatically, so you're left wondering why it's crashed).

And then it manages to not tell you anything useful about why you were prompted. And the window itself sucks: the details are mostly useless (they don't even tell you what the soft is trying to do), there are pointless effects (the zone where you have to enter your password becomes blueish if you hover, half the text of the window changes your mouse pointer to a hand even though they're not clickable, ...) and it pops up every time something tries to fart in Program Files.

OSX at least has the decency to let you drop softs in /Applications without bothering you.

Users have been well trained that all install dialogs are just barriers to task success. They don't read anything on them. Next next next next Finish.

I guarantee you I'd get 80% conversion to "Format C:/ and pillage your Googles" if it were the last step of the BCC instller.

Many experts agree with you. Facebook disagrees for this specific instance. They advise developers not to ask for more permissions than they need, because the more permissions you ask for, the fewer signups you'll get. That suggests that a non-trivial number of users are reading something on these particular dialog boxes.

Non-trivial is a large number for Facebook. They nerfed their "Friend Lists" feature because only 5% of their userbase, i.e. 25 million people, were using it.

It doesn't suggest that to me. It suggests to me that they would prefer you not ask for too many permissions because they've learned from Farmville that overbearing apps get bad PR for Facebook, and the fact that some number (perhaps quite trivial) of people will be turned off by it is a convenient disincentive.

Q: Why would an application developer want to make limiting promises?

A: Because more users will trust the application and be willing to authorize it.

I think this is the only correct answer. Sadly, without mechanisms in place to limit the scope of the authorization, the market is aiming for a scenario where ordinary people simply don't trust web applications. Even visiting new sites on the web for them will carry a baseline of non-specific fear.

Most users will never analyze the "This application requests the following permissions..." screens; see: anyone that owns an Android phone.

The reason is that there is no reason to analyze it. There's nothing to do on the screen, and you've already decided you want to download the app (after all, you did press the "Download" button).

Maybe 80% people will still press "Allow" instantly, but at least this makes the 20% other more comfortable.

I am not most users. Strangely, neither are most of the people I know. But we're the ones everybody looks to when they need to buy a computer, know if the web is safe, or clean up the mess when it turns out not to be.

Quit it with the "most users" reasoning, unless your goal in life is to part fools from their money.

The problem is lots of calls in the Android API have side-effects or can be used for a variety of reasons. Anytime you have ads for instance, you need internet access. If the app can be moved to the SD card, you need write access to that, and so on and so forth. They're little things but require opening up lots of possibilities.

Yeah I don't really know about Android. The article was really more about web apps.

But granular access controls are nearly impossible to implement in practice. Unix had it right all along: a set of limited users, and root. You're doing well if you can even defend that security boundary, anything in-between tends to be root-equivalent on general purpose systems.

That's ridiculous. The Unix security model doesn't even address untrusted applications, unless you think auto-downloading and running Unix executables would work out well. The situation with web security is terrible and there aren't any "good old days" we can revert back to -- every mainstream OS has done it wrong. Good security is difficult and influences many parts of a system, but if it were a priority for any of the big players, it would have already happened.

An untrusted application is handled in running it as a dedicated user, like 'httpd' or 'nobody'.

Can nobody access "user joe"'s SMS and Email?

A. If it can, then it can send my personal info to outside world. I don't care if it can't gain root access to my phone. My phone's root account is not important, my personal information inside that phone is.

B. If it cannot. Then most of my application is useless because it can't access any information at all. Why don't I add it to "trusted" zone? Because I don't trust it. And I shouldn't have to.

So what do I want? I want it to see my personal data but not being able to send it to anyone.

We're back to permission based system again.

Please educate yourself about Unix Security Contexts.

Quit it with the "most users" reasoning, unless your goal in life is to part fools from their money.

I don't follow your reasoning, but still:

Listing granular permissions is like throwing up a confirmation dialog before a destructive action: better than nothing, but more often than not gets ignored.

Yes, after that, your friends call wondering why all their data was deleted or why some app is updating their facebook wall. And you tell them to pay attention next time, and they swear they will.

And they don't.

I don't have a better solution, but that doesn't mean that this is the right one.

It doesn't matter if "most users" don't care about this level of information as long as they still click "allow", but it does make difference to the minority that do care. So what's the harm?

If they don't care about the information then it's presence doesn't hurt them.

Absolutely! It is not rare for me to get to the allow screen, notice that the app is basically requesting full access to my account which it clearly doesn't need, and leave.

As the worms spreading through e-mail show, social filtering may not be sufficient to identify rogue apps in time.

We proposed a reputation mechanism for mash-ups/apps that can be plugged on OAuth. The service provider (e.g: Twitter or Facebook) records every access to the user account and sends a report after a week. Users rate the application which reputation is maintained by the service provider. Average ratings and comments are displayed when a new user is asked to grant an authorization.

Link to the paper: http://www.dundal.com/R2M-CCNC2010.pdf

Unfortunately, a malicious app isn't likely to really say "we want to spam your friends"; it'll make up some other excuse. And, as tptacek keeps saying, only a vanishingly small fraction of users pay attention to this stuff anyway, at least until they get burned.

So, if there's something to be done here, it may be in helping them to recover after they get burned --- perhaps an easy and straightforward UI for revoking OAuth tokens once granted, if the user doesn't like what the app has done with them?

I'm not sure how it works now, but the way Facebook dealt with this issue is to present IFrame with confirmation what you're posting on your wall. This of course makes using client side scripting mandatory but it—very efficiently—limits any SPAMing capabilities of a rouge application.

Also, developers could request dropping this limitation but they had to go through Facebook's verification system, part of which was confirming that the app itself presents message before publishing and will only do that on the immediate UI input.

How do you enforce they tell the truth, and the whole truth?

openid-abuse@twitter.com or web interface equivalent.

But even better, the requested capabilities should be specific enough, so that any additional description wouldn't be necessary.

Would be cool. But really, I don't think people will double-guess themselves when QuizMatic3000 doesn't give reasons for it. (An age-old UX myth: users never read dialog boxes, they just click OK.)

One fearless developer I worked with would switch the meaning of the boxes every now and then to 'train' the users not to ignore the texts based on negative feedback.

  +------------------------------------------------------+
  |                                                      |
  |     Are you really sure you don't want to format ?   |
  |                                                      |
  |                   <yes>     <no>                     |
  |                                                      |
  +------------------------------------------------------+

He'd have made a pretty good BOFH I think.

That's like "training" a cyclist to use a helmet by smacking them in the head.

Plenty of times later in life when I saw some cryptic message in a dialog box I suspected that he'd found new employment, but based on the high frequency of such instances it's hard to believe they're all related to him ;)

I think we should do some A/B testing on this for efficacy.

Or you could use meaningful button labels:

    <format> <cancel>

(or something like that)

It's both intuitive and simple. Universally every HIG[1] that exists advocates that. Personally, I'd make the button red as well.

[1] Human Interface Guidelines.

For example, here's relevant section in KDE's HIG: http://techbase.kde.org/Projects/Usability/HIG/Messages#Conf...

EDIT: To clarify I didn't suspected this to be a revelation to anyone. I just wanted to put it here, since it's a very relevant audience and I was just surprised nobody have mentioned it already.

Yes, that's the only right way to do it. But unfortunately even the largest companies still get this sort of thing wrong with alarming regularity.

Another pet peeve of mine is error messages that list multiple possible causes when clearly the underlying software must know exactly which one was the 'real' cause. So then you have to go and investigate a bunch of stuff just on the off chance that that was what caused the issue.

I think IE8 did something like this, w.r.t content not served over https during an https session. It was a yes/no box worded like "Do you want to view the content only served over https?" assuming the users would generally click "yes" thinking it was the more permissive option.

> He'd have made a pretty good BOFH

Or punching bag.

Hence the 'fearless'.

I agree. My sister (a Normal Person) asked me why her new Android phone does this, and now she thinks she should have got an iPhone.

Reply on news.ycombinator.com