* Read access
We want to analyse your tweets
Because we want to spam your friends
I am deadly serious.
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.
Android and the Android Marketplace appear to contradict that theory.
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.
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).
This has the advantage of generally being true, and being unobjectionable enough that most people will grant access.
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.
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.
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.
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.
As the worms spreading through e-mail show, social filtering may not be sufficient to identify rogue apps in time.
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.
If they don't care about the information then it's presence doesn't hurt them.
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.
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.
Maybe 80% people will still press "Allow" instantly, but at least this makes the 20% other more comfortable.
Link to the paper: http://www.dundal.com/R2M-CCNC2010.pdf
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?
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.
But even better, the requested capabilities should be specific enough, so that any additional description wouldn't be necessary.
| Are you really sure you don't want to format ? |
| <yes> <no> |
It's both intuitive and simple. Universally every HIG that exists advocates that. Personally, I'd make the button red as well.
 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.
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.
Or punching bag.
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.
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.
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).
So, be careful what you wish for.
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 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.
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).
I know this wasn't only about Twitter, but this is an issue I've had myself and it's incredibly annoying.
Richard now works at Twitter.
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?
It also easier to revoke access to just on app, previously you had to change your password and then update all the other apps
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?
However, I'd welcome annotations for exactly why an app requires each permission.
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.
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.
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.
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.
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.
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.
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.
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).
Previous to OAuth people would hand over their credentials to third party apps. That's what sucking looks like.
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).
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.
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.
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.
People don't read any message boxes' contents, they only see the "Ok" button and click it. It's amazing, but unfortunately true.
I have three: GoogleTV, Mobile, Iphone. (I used to have TweetDeck and a couple others, so 6 total.)
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
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