I would definitely support greater disclosure here, but would avoid the checkbox model of authorizing different levels of access (http:// www.flickr.com/photos/factoryjoe/2601626420/sizes/o/).
Instead, you should allow the application developer to pick the appropriate API access level it needs (read only, posting, friending, direct messaging, all access) and then provide that language to the user upon authorization. The current language "to access and update your data on Twitter" is so vague as to be meaningless. Stronger language will potentially scare off people (especially initially when they're not used to this flow) but that's the point. Previously people were handing over their credentials, having these bad experiences, and then having no recourse to disable that app from having access (unless they changed their password — thereby breaking every other app to which they'd supplied their credentials). To Chad's point about "buyer beware" — that's not good enough here. The risk you run with OAuth is that folks operating in a gray area will simply say "well, we don't take user's passwords anymore" and then go do something shady like auto-friend their account without permission. That's breaking the social contract and Twitter needs to step-in to make that procedure transparent, or else it'll negatively impact other apps built on Twitter's API. In other words, it's up to Twitter to ensure that people can TRUST the authorization screen — and that nothing evil will happen if they hit "allow" — unless they specifically authorize someone to have all access. "Buyer beware" also suggests that Twitter has an obligation to inform the buyer, since there are few other mechanisms — especially when apps post unedited self-promotional tweets through user accounts — to help the buyer make an informed decision. I see two things that Twitter could do right away, one which I presume they're already working on: 1. create a directory of known/good apps and promote the ones that are "safe" (see Facebook) 2. layer in social awareness into the authorization screen so people have a better sense whether to trust an app Here's my mockup for #2: http://www.flickr.com/photos/factoryjoe/3448360090/ Also, other examples of authorization screens to consider: http://www.flickr.com/photos/factoryjoe/3295727080/sizes/o/ (note the "...Flickr partner" nomenclature) http://www.flickr.com/photos/factoryjoe/2707598617/sizes/o/ If you want more example, I've collected some: http://www.flickr.com/search/?q=authorization&w=25419820%40N00 Chris On Apr 16, 8:53 am, Matt Sanford <[email protected]> wrote: > Hi there, > > My initial wording for the pages was much stronger and the > biggest complaint during testing was that it scared people off … so I > obviously side with stronger language. In the light of how people are > using OAuth it seems like we need something more. I'll talk with the > product folks and see if we can't find some middle-ground. Thanks for > the feedback everybody. > > Thanks; > — Matt Sanford / @mzsanford > > On Apr 15, 2009, at 08:27 PM, Rod Begbie wrote: > > > > > There are two separate questions here: > > > 1) Should Twitter make the language on the Authorization page > > clearer as to exactly what an app can do if you click "Approve". > > This gives the user some amount of a hint at what can happen. I'd > > push wholeheartedly for this, as the current distinction of "read > > and update" versus "read" are easy to miss. > > > 2) Should Twitter introduce a policy/TOS document on expected > > behaviour for apps? I'd hope for at least a wiki page that can be > > pointed to as "Things that will get your app deauthorized". This is > > a policy/community change request, not a code one. > > > Rod. > > > On Wed, Apr 15, 2009 at 8:09 PM, Chad Etzel <[email protected]> > > wrote: > > > Again with the "OAuth does not prevent a bad app form being bad" > > point. All this same stuff can be done with Basic Auth apps. The > > point here is that users can prevent further badness by going to their > > "Connections" tab and revoking the access tokens. > > > No, this doesn't solve the "what happens when I initially authorize > > this app" problem. > > > imho, "buyer beware". > > -Chad > > > On Wed, Apr 15, 2009 at 10:51 PM, Abraham Williams > > <[email protected]> wrote: > > > My thoughts are not having a good enough notice is bad form and > > users will > > > start gravitating away from apps with bad form and better > > competition comes > > > out. > > > > But yes. I think it would be good for Twitter to make an official > > statement > > > and include it somewhere that that sort of misdirection is frowned > > upon. > > > > Abraham > > > > On Wed, Apr 15, 2009 at 21:21, Cameron Kaiser > > <[email protected]> wrote: > > > >> > From a user expectatins perspective, I'd suggest that the > > Twitter OAuth > > >> > dialog also add a bullet list of what "access and update your > > data" > > >> > means > > >> > (like Flickr does) to prevent further surprises. I'm not sure > > users > > >> > appreciate that an authorised app can: > > > >> > * Post and delete tweets in your name > > >> > * Add and remove users you are following > > >> > * Block and unblock users > > >> > * Change your name, email address, location, avatar or > > description > > > >> > Thoughts? > > > >> This is an excellent point. > > > >> -- > > >> ------------------------------------ personal: > > >>http://www.cameronkaiser.com/-- > > >> Cameron Kaiser * Floodgap Systems *www.floodgap.com* > > >> [email protected] > > >> -- Sarcasm is a spiritual gift. -- Paul Austin > > >> -------------------------------- > > > > -- > > > Abraham Williams |http://the.hackerconundrum.com > > > Hacker |http://abrah.am|http://twitter.com/abraham > > > Web608 | Community Evangelist |http://web608.org > > > This email is: [ ] blogable [x] ask first [ ] private. > > > Sent from Madison, Wisconsin, United States > > > -- > > :: Rod Begbie ::http://groovymother.com/::
