
OAuth Will Murder Your Children - holman
http://zachholman.com/2011/01/oauth_will_murder_your_children/
======
judofyr
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

~~~
tptacek
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.

~~~
mikedouglas
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.

~~~
StavrosK
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...

~~~
archangel_one
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.

~~~
ZoFreX
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).

------
lacker
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.

~~~
jacobolus
> _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.

~~~
tptacek
Schemes that avoid users like you may be good business, similar to the way
that fine-grained low pricing invites pathological users.

------
tptacek
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.

~~~
imajes
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.

~~~
baconner
Absolutely right. LinkedIn is doing this. access for one day, one week, ...
when granting permissions.

~~~
deno
Here's screenshot of how it looks:
[http://developer.linkedin.com/servlet/JiveServlet/downloadIm...](http://developer.linkedin.com/servlet/JiveServlet/downloadImage/38-1039-1130/400-276/oauth_window_screenshot.png)

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).

------
apike
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>

------
albertsun
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>

------
BarkMore
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.

------
gnok
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).

------
drm237
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.

------
ianburrell
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.

------
jjj38
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...](http://www.quora.com/Richard-Henry/Improving-Twitter-OAuth-With-
Mockups)

Richard now works at Twitter.

------
AndrewO
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?

~~~
rmc
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

~~~
AndrewO
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?

------
bryanlarsen
Android needs this too, perhaps even more than OAuth does.

~~~
orangecat
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.

~~~
pretz
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.

------
PaulHoule
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.

------
bugsy
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.

------
samstokes
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.

------
lsblakk
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.

------
jdavid
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.

------
liuhenry
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.

------
apinter
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.

------
milfot
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.

------
stevefarnworth
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).

------
staunch
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.

~~~
commanda
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.

~~~
staunch
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).

------
rckenned
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.

~~~
lenary
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

------
kierank
Couldn't have found a more linkbait title if I tried.

~~~
seiji
Yeah, but it works because a.) Zach follows through with the metaphor
throughout the article and b.) it isn't slimy self promotion.

~~~
joshwa
"43 Ways OAuth Will Murder Your Children"

~~~
RickHull
Don't forget the tangentially-related-through-twitter
<https://github.com/lg/murder>

------
swah
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.

------
trustfundbaby
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.

------
danperron
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.

------
neutronicus
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.

------
reqt
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.

------
yaix
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.

------
onomojo
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?

------
adamdecaf
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.)

~~~
steveklabnik
I've got 33.

------
brucehauman
I agree. A simple solution in the meantime maybe to allow users to revoke
certain access levels to specific services in an admin panel.

------
bound008
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.

------
EGreg
The problem with twitter in particular is that it lets you do two things: read
and post messages. What granular options do you see?

~~~
gnok
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

------
dalore
I wish android did this.

