Great stuff, Chris. Thanks for taking the time to mock it up. On Thu, Apr 16, 2009 at 12:03, Chris Messina <[email protected]> wrote: > > 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/:: >
-- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
