OAuth Will Murder Your Children(zachholman.com)
zachholman.com
OAuth Will Murder Your Children
http://zachholman.com/2011/01/oauth_will_murder_your_children/
37 comments
Even better: Let the application also say why it needs the permission:
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> |
| |
+------------------------------------------------------+
Or you could use meaningful button labels:
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.
<format> <cancel>
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.
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.
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.
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.
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.
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.
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
Link to the paper: http://www.dundal.com/R2M-CCNC2010.pdf
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.
Quit it with the "most users" reasoning, unless your goal in life is to part fools from their money.
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.
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.
If they don't care about the information then it's presence doesn't hurt them.
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.
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.
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.
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.
Maybe 80% people will still press "Allow" instantly, but at least this makes the 20% other more comfortable.
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.
As the worms spreading through e-mail show, social filtering may not be sufficient to identify rogue apps in time.
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.
I am deadly serious.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
How do you enforce they tell the truth, and the whole truth?
[email protected]
or web interface equivalent.
But even better, the requested capabilities should be specific enough, so that any additional description wouldn't be necessary.
But even better, the requested capabilities should be specific enough, so that any additional description wouldn't be necessary.
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?
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.
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.
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.
Making Facebook apps, we ran into a tiny fraction of users who disabled some of the permissions that we asked for. It was simpler to just keep popping up the permission window until they accepted or left the app rather than code special cases for the tiny minority that cared about nonstandard permissions settings. This became pretty standard in Facebook apps, although it's a bad experience, because hardly any users actually care.
So, be careful what you wish for.
So, be careful what you wish for.
> hardly any users actually care
I’d be careful before making assumptions like this. Many users may care but still value using an app enough to put up with giving up permissions they’d prefer not to. Other users might not have any idea what the permissions settings do or say. Still other users (for example, me) just avoid facebook apps altogether because they universally ask for distasteful levels of access.
I’d be careful before making assumptions like this. Many users may care but still value using an app enough to put up with giving up permissions they’d prefer not to. Other users might not have any idea what the permissions settings do or say. Still other users (for example, me) just avoid facebook apps altogether because they universally ask for distasteful levels of access.
Schemes that avoid users like you may be good business, similar to the way that fine-grained low pricing invites pathological users.
Meh. The problem with this is that every empirical study of actual users is going to demonstrate that they simply don't care. The primary control that OAuth dialogs like these express is "prevent malicious phishing apps from coercing users into inadvertantly opting in", and the dialog we have now is sufficient to that purpose.
For the tiny subset of users (I am one of them) to whom this issue matters, you can mitigate the problem by periodically culling your OAuth tokens through the Twitter interface.
For the tiny subset of users (I am one of them) to whom this issue matters, you can mitigate the problem by periodically culling your OAuth tokens through the Twitter interface.
There's still a culture of too-much-access (we might need it in the future!!) that needs to be addressed here. Perhaps once we're all super used to these interstitials, then it'll become a no-brainer to come back to them and request info.
Personally, i think we should go even further; lets request sunset/timeout clauses on access. I'm willing to give the kanye analyzer two weeks access to my twitter account, but after that, i want my token rescinded.
Personally, i think we should go even further; lets request sunset/timeout clauses on access. I'm willing to give the kanye analyzer two weeks access to my twitter account, but after that, i want my token rescinded.
I agree, but I think that's an issue Twitter needs to take up with app developers; there's no dialog you can design that enables them to punt that concern to end-users.
Absolutely right. LinkedIn is doing this. access for one day, one week, ... when granting permissions.
Here's screenshot of how it looks: http://developer.linkedin.com/servlet/JiveServlet/downloadIm...
However the reason LinkedIn does it is probably because the nature of information accessed is very fragile.
Similar, but slightly different solution, I'd suggest, would be to track by provider if application is actively used and perhaps revoke token after some period of time (or at least present user with that data on their profile settings page).
However the reason LinkedIn does it is probably because the nature of information accessed is very fragile.
Similar, but slightly different solution, I'd suggest, would be to track by provider if application is actively used and perhaps revoke token after some period of time (or at least present user with that data on their profile settings page).
Due to a long-standing bug in the Twitter API, you can not add write support to an app without deleting it entirely and re-creating the app in their system. It will let you change the flag for future users, but there is no way to request the additional privileges from a user if needed. As such, it unfortunately a "good idea" to always create your Twitter apps as read-write.
Reference: http://code.google.com/p/twitter-api/issues/detail?id=669
Reference: http://code.google.com/p/twitter-api/issues/detail?id=669
I recently discovered that to use the @Anywhere javascript API you have to have your app request read and write access even if you don't want write access.
* http://dev.twitter.com/anywhere/apps/new
* http://dev.twitter.com/anywhere/apps/new
The article discusses how many applications request write access when they don't need it.
I think that the reverse problem is even worse. Many of the applications that I use (Posterous, Picplz, Instagram) only need write access, yet they always get read permission. I don't want these applications reading my direct messages. Unfortunately, Twitter does not provide a write only permission.
I think that the reverse problem is even worse. Many of the applications that I use (Posterous, Picplz, Instagram) only need write access, yet they always get read permission. I don't want these applications reading my direct messages. Unfortunately, Twitter does not provide a write only permission.
This is a crucial step for safeguarding privacy/security if OAuth is to become more prevalent.
Any app may request any number of permissions from me; but I as a user should be able to choose what permissions it gets. I would take this one step further and allow the user to retroactively withdraw permissions (OAuth already allows for asking the user for additional permissions).
Any app may request any number of permissions from me; but I as a user should be able to choose what permissions it gets. I would take this one step further and allow the user to retroactively withdraw permissions (OAuth already allows for asking the user for additional permissions).
Twitter is half of the problem here. Once you request read access and a user approves it, there is no way under the same application then go back and get write access. Ideally every app would start with read and then only upgrade to write when needed but Twitter won't allow it. There are multiple bugs in their api issue tracker and they don't seem to care. The only way to get around it is to have two applications, a read and a read-write which actually is more difficult and why bother working around Twitters short comings when most users don't care?
I know this wasn't only about Twitter, but this is an issue I've had myself and it's incredibly annoying.
I know this wasn't only about Twitter, but this is an issue I've had myself and it's incredibly annoying.
A good example of this is Clickpass that Hacker News uses for logins. With Google, it asks for access to "Google Contacts". There is no explanation of why it needs access to Contacts or what it is going to do with it. As far as I can tell, it doesn't do anything nefarious. I have seen other sites using Google Accounts for sign in with requesting OAuth access.
Probably a coincidence, but this sounds a lot like a post written by @richardhenry in November last year, right down to the "41 of the 43 apps":
http://www.quora.com/Richard-Henry/Improving-Twitter-OAuth-W...
Richard now works at Twitter.
http://www.quora.com/Richard-Henry/Improving-Twitter-OAuth-W...
Richard now works at Twitter.
I 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 people to allow the maximum set of permissions to a complete stranger is a good thing?
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 people to allow the maximum set of permissions to a complete stranger is a good thing?
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
It also easier to revoke access to just on app, previously you had to change your password and then update all the other apps
I admit there was some slight hyperbole there. Let's say it's one better than giving out your password because it cuts down on the password reuses issue and you can revoke.
If that's all that OAuth will ever get us, then it's a failure: either because the goals of the spec were infeasible or because developers weren't able to use it to its fullest (I lean toward the later).
OAuth is not about solving password reuse. It's about granting other clients rights to specific resources on your behalf. It's about telling a 3rd party app they can tweet once, and not read my direct messages; they can read my Gmail contacts, but not send; and so on...
I for one believe in the need for this. But the original poster is right: as long as developers request blanket permissions, I'm not going to use their apps. I may be in a small category, but I'll ask again: is this the kind of behavior we want to condition into users?
If that's all that OAuth will ever get us, then it's a failure: either because the goals of the spec were infeasible or because developers weren't able to use it to its fullest (I lean toward the later).
OAuth is not about solving password reuse. It's about granting other clients rights to specific resources on your behalf. It's about telling a 3rd party app they can tweet once, and not read my direct messages; they can read my Gmail contacts, but not send; and so on...
I for one believe in the need for this. But the original poster is right: as long as developers request blanket permissions, I'm not going to use their apps. I may be in a small category, but I'll ask again: is this the kind of behavior we want to condition into users?
Android needs this too, perhaps even more than OAuth does.
My first thought as well. It annoys me when apps add optional "sharing" features that require access to my contact list, and there's no way to allow the app to run without those permissions. And the Internet and SD card permissions are too coarse-grained; developers should be able to list specific directories and hosts that the app can access.
Trust me, as an app developer it annoys me too that there's no easy way for me to allow users to opt-out of contacts access. Making a second app is just too complicated.
I think that Android needs it to go a bit further by differentiating between required permissions and optional ones. Having them all optional could cause the app to plain not work (no, Handcent can't send messages) or users would just block apps that request internet access for fetching adverts from doing so.
However, I'd welcome annotations for exactly why an app requires each permission.
However, I'd welcome annotations for exactly why an app requires each permission.
A capability that I'm looking at for working with Facebook Connect is gradually adding more privileges as a user has more experience with the site and gains more trust.
Overall this problem is worse with things that are more app than web site or that put up an authentication wall before you can see anything interesting.
Overall this problem is worse with things that are more app than web site or that put up an authentication wall before you can see anything interesting.
I agree with the criticism. This OpenID stuff was promoted as single sign in. That is not what it is at all! You are forced to give write permission to every app out there before being allowed to sign in to their site to do trivial things, and then they start spamming your feed and harvesting your data. When you try to turn it off there is no off switch that can be found. It's insane.
It's the same level of intrusion as if you wrote a letter to the editor of the local paper and by sending your opinion on local parking fees, the newspaper is given access to your private mail, is allowed to set up cameras inside your house, and asserts that you agreed the newspaper's publisher can have sex with your daughter.
What the hell does any of that have to do with submitting an editorial letter?
What it has to do is this system ALLOWS them to invade your privacy, so they REQUIRE you to give up your privacy and allow them to invade it in order to do things like post comments or vote in polls that have nothing at all to do with any of what they demand they must have.
It's an abusive system that violates consumers.
It's the same level of intrusion as if you wrote a letter to the editor of the local paper and by sending your opinion on local parking fees, the newspaper is given access to your private mail, is allowed to set up cameras inside your house, and asserts that you agreed the newspaper's publisher can have sex with your daughter.
What the hell does any of that have to do with submitting an editorial letter?
What it has to do is this system ALLOWS them to invade your privacy, so they REQUIRE you to give up your privacy and allow them to invade it in order to do things like post comments or vote in polls that have nothing at all to do with any of what they demand they must have.
It's an abusive system that violates consumers.
I agree with the OP's conclusion - permissions need to be finer-grained and authorisation prompts more informative. But with OAuth as it stands, those things are under the control of the API provider, and app developers have limited control.
If my app has a button to follow someone on Twitter, my app needs Twitter write permission, which also lets me tweet as you and read your DMs. All I want to do is follow someone, but Twitter doesn't offer finer-grained authorisation, so I have no choice but to pop up the dialog box asking for full write access.
Twitter's an extreme example, but not the only one. The Facebook API also has some unintuitive permissioning requirements (for example, you need more permissions to "like" a post than you do to comment on it). Unless the permission model makes sense to users, apps have a hard time communicating to users why they need the permissions they're requesting. Judofyr's suggestion above would help a lot with this problem, but it's still not something that can be blamed entirely on lazy app developers.
If my app has a button to follow someone on Twitter, my app needs Twitter write permission, which also lets me tweet as you and read your DMs. All I want to do is follow someone, but Twitter doesn't offer finer-grained authorisation, so I have no choice but to pop up the dialog box asking for full write access.
Twitter's an extreme example, but not the only one. The Facebook API also has some unintuitive permissioning requirements (for example, you need more permissions to "like" a post than you do to comment on it). Unless the permission model makes sense to users, apps have a hard time communicating to users why they need the permissions they're requesting. Judofyr's suggestion above would help a lot with this problem, but it's still not something that can be blamed entirely on lazy app developers.
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.
You are missing the point. Apps need to respect a User enough not to get banned from Twitter.
Twitter also in their TOS specify how not do do things. If you don't follow the TOS and expected behavior of the app, then you are going to get complaints, and twitter will shut down your app.
In general it's not good business to get shut down.
Twitter also in their TOS specify how not do do things. If you don't follow the TOS and expected behavior of the app, then you are going to get complaints, and twitter will shut down your app.
In general it's not good business to get shut down.
Facebook has made a lot of progress in app privileges. Under http://www.facebook.com/settings/?tab=applications, there is a categorical line-item veto - you can revoke access to certain things, such as wall posting, access posts in news feed, access my data at any time, check-ins, etc. It also specifically shows what information was accessed by an app, and when (Last Accessed: Basic Info, Likes, and Current City on January 25th).
LinkedIn has time-out on permissions. You can set a specific time setting or allow access until revoked.
There's no reason that Twitter can't do the same. The subset of users who care about specific privileges can go and revoke them, and the app can re-request permissions if needed.
LinkedIn has time-out on permissions. You can set a specific time setting or allow access until revoked.
There's no reason that Twitter can't do the same. The subset of users who care about specific privileges can go and revoke them, and the app can re-request permissions if needed.
While I agree that there are problems with access granularity for Twitter, the author ignores the access models of the other providers. Facebook for one provides an extremely rich set of granular controls. The grant screen, is however 1 page, so maybe that is why he chooses not to analyze Facebook further.
I also believe that the author has some fundamental misconceptions about OAuth. OAuth is merely a standardized way of gaining access to proprietary APIs. There is nothing in the specification about what sort of level of permission an access token will provide the consuming site. The statement: "And KanyeAnalysis™ uses OAuth, which lets you use your Twitter credentials to sign in!" is misleading and makes OAuth sound much more like OpenId than it really is.
I also believe that the author has some fundamental misconceptions about OAuth. OAuth is merely a standardized way of gaining access to proprietary APIs. There is nothing in the specification about what sort of level of permission an access token will provide the consuming site. The statement: "And KanyeAnalysis™ uses OAuth, which lets you use your Twitter credentials to sign in!" is misleading and makes OAuth sound much more like OpenId than it really is.
The problem, as I see it, is over the top access requests to access elevated privileges and personal information is the norm. This is not a user problem.
There must be a way for :
1. third-party developers to use the api to access information for their app in a kind of handshake mode - without the ability to use that information externally - or to access elevated privileges in a kind of sandbox arrangement.
2. for the api developers to use their control of market places and warnings to make these low level access privileges the norm, rather than the exception.
Getting these two things in place would mean developers would have to make a case to you, the user, if they wanted to do something more powerful or dodgy with the api.
There must be a way for :
1. third-party developers to use the api to access information for their app in a kind of handshake mode - without the ability to use that information externally - or to access elevated privileges in a kind of sandbox arrangement.
2. for the api developers to use their control of market places and warnings to make these low level access privileges the norm, rather than the exception.
Getting these two things in place would mean developers would have to make a case to you, the user, if they wanted to do something more powerful or dodgy with the api.
So because some apps abuse the system, we all have to suffer writing lots of extra code?
In one of my apps, I request read/write access and then allow the user to select whether they want to tweet on an interaction basis, not on a connection basis. It would provide an extra pain point if the user did want to the application to tweet to have to go back to Twitter.com to change their settings (and if the setting can be changed via the API, then that defeats the purpose altogether).
It's not ideal when any app can spam, but it's better than having a user choose their access levels before they've even used the application (where the OAuth request dialogue tends to sit).
In one of my apps, I request read/write access and then allow the user to select whether they want to tweet on an interaction basis, not on a connection basis. It would provide an extra pain point if the user did want to the application to tweet to have to go back to Twitter.com to change their settings (and if the setting can be changed via the API, then that defeats the purpose altogether).
It's not ideal when any app can spam, but it's better than having a user choose their access levels before they've even used the application (where the OAuth request dialogue tends to sit).
OAuth is powerful and awesome because even when people hand over full control they can revoke that access at any time they want.
Previous to OAuth people would hand over their credentials to third party apps. That's what sucking looks like.
Previous to OAuth people would hand over their credentials to third party apps. That's what sucking looks like.
Before, all you needed to do to revoke access to all those crazy 3rd parties you gave your password to was: change your password.
Now, you need to figure out where to go to revoke permissions, figure out what 3rd party app you no longer want, and figure out exactly what permission (in Facebook's case, but not Twitter's). It's confusing even for technical people because it's nonstandard and different on every OAuth provider's site.
1) Unless the app was evil and changed your password for you.
2) Or unless you wanted to let some apps keep access to your account, but not others.
3) And if you can easily deal with remembering new passwords (most users can't).
2) Or unless you wanted to let some apps keep access to your account, but not others.
3) And if you can easily deal with remembering new passwords (most users can't).
We had a similar problem at Yahoo! with BBAuth and OAuth. Developers started out initially building an application that needed access to (for instance) Yahoo! Mail. Unfortunately, there's no way in the Yahoo! Developer Network to "upsize" an application ID or consumer key after it has been created. You can't go back and say, "You know what? My application could be 2x as awesome if I added Yahoo! Address Book support." As a result, developers requested the kitchen sink: Yahoo! Mail, Address Book, Calendar, Flickr, Profile, MyBlogLog, Delicious, Fantasy Sports, Messenger, Updates and so on. In addition, each of those services has different permissions ranging from Read-Only to Read/Write (see https://developer.apps.yahoo.com/dashboard/createKey.html).
Google did a better job of this with their OAuth flow, allowing a "scope" to be passed in the authorization request so applications can dynamically select what they want access to (http://code.google.com/apis/gdata/docs/auth/oauth.html#Scope). This means applications don't have to ask for the world up front when registering. Unfortunately it doesn't fix the "OAuth will murder your children" problem.
Ultimately it's a user experience problem. As the article points out, add too many checkboxes and it becomes too complex. The average user doesn't pay attention (like reading a EULA) and in several cases they're not going to understand the scopes presented to them anyway. Read/Write is pretty clear to most of us, not so clear to my mother.
As an amusing aside, I went to log into Hacker News using their Clickpass integration to sign in using my Yahoo! account. Clickpass does the OAuth song and dance and requests read/write access to my Address Book. "http://www.clickpass.com is asking you and Yahoo! for the ability to automatically sign-in as you to your Yahoo! account through a service or application that is provided by http://www.clickpass.com, and to read and store to your data in Yahoo! Address Book." Evidently OAuth will not only murder your children, it will wipe them from your Address Book, too.
Google did a better job of this with their OAuth flow, allowing a "scope" to be passed in the authorization request so applications can dynamically select what they want access to (http://code.google.com/apis/gdata/docs/auth/oauth.html#Scope). This means applications don't have to ask for the world up front when registering. Unfortunately it doesn't fix the "OAuth will murder your children" problem.
Ultimately it's a user experience problem. As the article points out, add too many checkboxes and it becomes too complex. The average user doesn't pay attention (like reading a EULA) and in several cases they're not going to understand the scopes presented to them anyway. Read/Write is pretty clear to most of us, not so clear to my mother.
As an amusing aside, I went to log into Hacker News using their Clickpass integration to sign in using my Yahoo! account. Clickpass does the OAuth song and dance and requests read/write access to my Address Book. "http://www.clickpass.com is asking you and Yahoo! for the ability to automatically sign-in as you to your Yahoo! account through a service or application that is provided by http://www.clickpass.com, and to read and store to your data in Yahoo! Address Book." Evidently OAuth will not only murder your children, it will wipe them from your Address Book, too.
the "scope" parameter that google included is actully from the OAuth 2.0 spec (still in draft iirc). There are a lot of improvements in OAuth 2.0 which are worth checking out, but this is one of the main ones
Couldn't have found a more linkbait title if I tried.
Yeah, but it works because a.) Zach follows through with the metaphor throughout the article and b.) it isn't slimy self promotion.
"43 Ways OAuth Will Murder Your Children"
Don't forget the tangentially-related-through-twitter https://github.com/lg/murder
I'm building a startup and I want to make things easier for my users.
Should I let them "sign up" with OAuth?
I read somewhere that doing that I don't "own" the users. What does that mean?
All I want is for folks to find their friends automatically, and not to force people to remember another password.
Should I let them "sign up" with OAuth?
I read somewhere that doing that I don't "own" the users. What does that mean?
All I want is for folks to find their friends automatically, and not to force people to remember another password.
I don't think developers get that users simply don't care about this kind of stuff.
There's a reason Steve Krug titled his book on good UI design 'Don't make me think'. We should be trying to make things simpler (from the User's POV) not more complex.
There's a reason Steve Krug titled his book on good UI design 'Don't make me think'. We should be trying to make things simpler (from the User's POV) not more complex.
I agree, limiting third parties access to your data is why OAuth exists in the first place. Although everything in this article is about Twitter's implementation of OAuth and not OAuth in general. The title is misleading.
Maybe give the user permission to revoke any permission from any application - so that if some application is spamming your followers, you can promptly force it to cease and desist.
Good point, bad example: your "KanyeAnalysis app" really does not need write access, so no need for checkboxes. It simply should not request write access, ever. Period.
This is "double click SETUP.exe" all over again.
People don't read any message boxes' contents, they only see the "Ok" button and click it. It's amazing, but unfortunately true.
People don't read any message boxes' contents, they only see the "Ok" button and click it. It's amazing, but unfortunately true.
But where would the business incentive be for the app writers? If they can't spy on you for later extortion techniques, how will they make money?
Why 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 have three: GoogleTV, Mobile, Iphone. (I used to have TweetDeck and a couple others, so 6 total.)
I've got 33.
I agree. A simple solution in the meantime maybe to allow users to revoke certain access levels to specific services in an admin panel.
Facebook does a decent job of this, with the exception that you don't get to have a line-item veto. Users deserve a line-item veto.
The problem with twitter in particular is that it lets you do two things: read and post messages. What granular options do you see?
His post wasn't Twitter specific; he just used Twitter as an example.
But since you asked, here's a couple I can think of: * A rate limit on the number of Tweets per hour/day/week * Ability to follow or unfollow * Ability to index my tweets if they're private
But since you asked, here's a couple I can think of: * A rate limit on the number of Tweets per hour/day/week * Ability to follow or unfollow * Ability to index my tweets if they're private
You can do a lot more than that with twitter:
1. Read Tweets 2. Write Tweets 3. Read direct messages 4. Write direct messages 5. Follow someone 6. Unfollow someone 7. Create a list 8. Add to a list 9. Remove from list 10. Delete List 11. Edit profile information/avatar ..etc...
1. Read Tweets 2. Write Tweets 3. Read direct messages 4. Write direct messages 5. Follow someone 6. Unfollow someone 7. Create a list 8. Add to a list 9. Remove from list 10. Delete List 11. Edit profile information/avatar ..etc...
I wish android did this.
[deleted]