I've often backed out of installing an OAuth app because of the overwhelming amount of info it says it wants read/write access to. I'd like to be able to choose what to give the app and I'd be willing to accept less functionality in some cases if necessary. Giving an app all your data could become the equivalent of a 'Pro' account.
OAuth Will Murder Your Children
41–50 of 101 posts
Re: OAuth Will Murder Your Children
#42Earlier quoted context omitted.
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 ? | | | | | | | +------------------------------------------------------+ He'd have made a pretty good BOFH I think.
Or you could use meaningful button labels: (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 ju…
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.
Re: OAuth Will Murder Your Children
#43Earlier quoted context omitted.
Most users will never analyze the "This application requests the following permissions..." screens; see: anyone that owns an Android phone.
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.
Re: OAuth Will Murder Your Children
#44Earlier quoted context omitted.
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 ? | | | | | | | +------------------------------------------------------+ 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.
I think we should do some A/B testing on this for efficacy.
Re: OAuth Will Murder Your Children
#45I see a couple of responses saying users don't care about this and they'd never read a dialog box. Honestly, if that's the case, what's the point of OAuth then? Why don't we just go back to handing over usernames & passwords and trusting some 3rd party to not do anything nasty? With everyone constantly complaining about Facebook privacy concerns and hijacked Twitter accounts, how can anyone pretend that conditioning…
OAuth has some advantages over storing passwords, firstly you're not giving your password away. Password reuse is very common, if you give one site your Facebook password, they probably have your email password.
It also easier to revoke access to just on app, previously you had to change your password and then update all the other apps
Re: OAuth Will Murder Your Children
#46Earlier quoted context omitted.
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 ? | | | | | | | +------------------------------------------------------+ He'd have made a pretty good BOFH I think.
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.
Re: OAuth Will Murder Your Children
#47Even 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
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…
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.
Re: OAuth Will Murder Your Children
#48Why the hell does he have 43 connected apps? Is this the norm? I have three: GoogleTV, Mobile, Iphone. (I used to have TweetDeck and a couple others, so 6 total.)
I've got 33.
Re: OAuth Will Murder Your Children
#49Even 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
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.
Re: OAuth Will Murder Your Children
#50Earlier quoted context omitted.
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.