Fast140 Dodginess and OAuth Authorization Clarity

[Rod Begbie]

Hey folks.

It's been noted that the fast140.com app, posts a tweet as the authorized user. In fairness, they do disclaim this on their homepage, although users tend not to notice and are surprised to find they've spammed their friends

However, they are also adding the @fast140 account to the user's Following list.  This isn't disclosed anywhere.

Does Twitter have a policy on this?  Should it?

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?

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

[Cameron Kaiser]

> 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 * cka...@floodgap.com
-- Sarcasm is a spiritual gift. -- Paul Austin --------------------------------

[Abraham Williams]

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

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

[Chad Etzel]

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

[Rod Begbie]

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.

[Stuart]

I would be all for Twitter having an agreement for all API users
(usage being implicit agreement) that, among other things would mean
applications that take action on the behalf of users without their
express permission will cause them to have their app banned from the
API. If basic auth is going to stick around in any shape or form I can
see this being pretty difficult to enforce, but I think even a simple
public statement from Twitter that such behaviour is unacceptable
would be a big step in the right direction.

I also think it should require that reasonable terminology is used.
For example on twply.com the question "Support Twply on your first
login?" does not make it clear that this means they'll post a tweet as
you promoting themselves.

-Stuart

--
http://stut.net/projects/twitter

2009/4/16 Rod Begbie <rodb...@gmail.com>:

[stevenic]

So just as an FYI... It's not just fast140.com that's doing this....
In order of offenderness (the most spam first) its also currently:

wefollow.com (5x the spam of fast140.com)
fast140.com
tinychat.com
macheist.com
geofollow.com
... and many more I'm sure...

[Matt Sanford]

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

[Chris Messina]

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 <m...@twitter.com> 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 <jazzyc...@gmail.com>  

> > >> ckai...@floodgap.com

[Chad Etzel]

On Thu, Apr 16, 2009 at 3:03 PM, Chris Messina <chris....@gmail.com> wrote:
>
> 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/

Oooh, I really like this a lot. Maybe even a total number of people
that have authorized the app vs. revoked access (in addition to
showing those in your friends/followers network). Not sure if you
would want to track "denies" as well?

Thinking along these lines... what if, in the "Connections" tab, each
user were able to rate each app they've authorized on a 1-5 star
scale? Then the auth page could show the average rating by users, or
something like that...?

Regarding my "buyer beware" comment:
I do agree that some/most of the onus is on Twitter to communicate
what exactly is happening (I'm also for stronger language), but users
do have to use their brains at some point and quit blindly trusting
everything that turns their mouse into a hand-pointer.

Also, I don't condone sketchy activities like forcing an auto-follow
without disclosure, so please don't think I'm defending this behavior.

-Chad

[Alex Payne]

Great stuff, Chris. Thanks for taking the time to mock it up.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

[Rod Begbie]

Yeah, but I think giving people a little bit of a scare is exactly the right thing to do.  It wasn't until I was writing my first email that I realised that an authorized app could change my display name and avatar, or block followers!

Ideally, I would like there to be finer-grained permissions for developers to request.  If I created an app that, say, updated users' Location based on FireEagle, it would be nice to only request the "Update Location" permission, and give users the assurance that I won't tweet as them.  This would also mean that a compromised database of tokens couldn't be used for (as much) evil.

(I'd still let it be an all-or-nothing decision for end users to Approve or Deny)

Rod.

[Rod Begbie]

On Thu, Apr 16, 2009 at 12:21 PM, Chad Etzel <jazz...@gmail.com> wrote:

Thinking along these lines... what if, in the "Connections" tab, each

user were able to rate each app they've authorized on a 1-5 star
scale?  Then the auth page could show the average rating by users, or
something like that...?

Only if there isn't a public API method for authorized apps to rate themselves as 5 stars ;)

Rod. 

[Chad Etzel]

On Thu, Apr 16, 2009 at 3:55 PM, Rod Begbie <rodb...@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 12:21 PM, Chad Etzel <jazz...@gmail.com> wrote:
>>
>> Thinking along these lines... what if, in the "Connections" tab, each
>> user were able to rate each app they've authorized on a 1-5 star
>> scale? Then the auth page could show the average rating by users, or
>> something like that...?
>
> Only if there isn't a public API method for authorized apps to rate
> themselves as 5 stars ;)
> Rod.

Darn, you foiled my evil plot! :)
-chad

[Rod Begbie]

On Thu, Apr 16, 2009 at 12:03 PM, Chris Messina <chris....@gmail.com> wrote:

1. create a directory of known/good apps and promote the ones that are
"safe" (see Facebook)

(Not speaking on behalf of my employer)

I would not necessarily hold Facebook up as a good example of what to do.

It should be noted that Facebook app developers face a swirling mass of ever changing rules, restrictions and policies (When you can post to a feed, what it can say, what happens when you click a link, etc).  FB have to spend an insane amount of time policing applications, and making there a solid penalty for violations of policy.

I really don't think Twitter would want to go down this route.

 

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/

Pretty cool.  I'd support something like that.

Rod.

[Lachlan Hardy]

> The current language "to access and update your data on Twitter" is so
> vague as to be meaningless.

Agreed.

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

Why is that? Do you have any evidence against it?

My own (limited, informal) testing tells me people feel more in
control with checkboxes.

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

You mean, like the Flickr example, yeah?
http://www.flickr.com/photos/factoryjoe/3295727080/sizes/o/

My preferred implementation would not have them as 'levels', but as
'options'. They're different components or aspects of the
functionality.

Some apps need to change your profile, but most don't. Some apps need
to send tweets but not do anything else. Some apps need access to
everything. I'm building an app at the moment where all I need is to
know you own the account. Anything else is superfluous to my needs,
but any user that authorises my app will be giving me the valet key to
the kingdom.

I want to be able to pick the options my app needs in order to work to
fullest effect, and display them to the user as checkboxes. In my
OAuth admin panel, I indicate which functionality is required and
which are just 'nice-to-haves'. Twitter presents the form to the user
as options and indicates which are required for the app. User picks
want they want and validation determines if they meet the minimum for
my app.

I think OAuth tends to have the exact opposite user experience problem
as OpenID. OpenID needs to be faster with less options, whereas OAuth
is rushed and doesn't offer the user enough involvement.

I realise the above is far more work than simply stronger wording on
authorisation form, but I think something of that nature offers a far
superior experience for our customers.

Lachlan Hardy

[Chris Messina]

On Apr 16, 1:02 pm, Rod Begbie <rodbeg...@gmail.com> wrote:

> On Thu, Apr 16, 2009 at 12:03 PM, Chris Messina <chris.mess...@gmail.com>wrote:
>
> > 1. create a directory of known/good apps and promote the ones that are
> > "safe" (see Facebook)
>

> I would not necessarily hold Facebook up as a good example of what to do.
>
> It should be noted that Facebook app developers face a swirling mass of ever
> changing rules, restrictions and policies (When you can post to a feed, what
> it can say, what happens when you click a link, etc).  FB have to spend an
> insane amount of time policing applications, and making there a solid
> penalty for violations of policy.
>
> I really don't think Twitter would want to go down this route.

Not what I was suggesting. Only pointing to Facebook's proposed
directory of "trusted applications".

The idea being that there would be SOME editorial involvement from
Twitter or trusted community members to review apps and determine that
they're on the whole seemingly trustworthy.

It'd be a rat's nest, for sure, but something that might be worthwhile
in lieu of actually trying to trust users.

Chris

[Chris Messina]

On Apr 16, 12:21 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
>
> Regarding my "buyer beware" comment:
> I do agree that some/most of the onus is on Twitter to communicate
> what exactly is happening (I'm also for stronger language), but users
> do have to use their brains at some point and quit blindly trusting
> everything that turns their mouse into a hand-pointer.

I hate to sound like a curmudgeon, but requiring people to use their
brains is a recipe for disappointment and mild disaster.

It's not that people are dumb per se, it's just that 1) any
sufficiently advanced technology is indistinguishable from magic and
2) most technology looks like magic to people and as a result will
click through any warning screen you toss up to get the prize on the
other side. Why is phishing effective? Exactly.

Now, for the small small percent of users who will review these
screens, I think that they SHOULD be useful and informative.

The funny thing about the way that people plow through user interfaces
is that, once burned, they tend to be a little more hesitant next time
— so if you DO provide useful information to them, someday they might
actually read it.

So, in sum, this comes down to doing the best you can, being as useful
as you can without getting TOO much in the way and then tweak tweak
tweak.

Chris

[Chris Messina]

On Apr 16, 2:59 pm, Lachlan Hardy <lach...@lachstock.com.au> 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/).
>
> Why is that? Do you have any evidence against it?
>
> My own (limited, informal) testing tells me people feel more in
> control with checkboxes.
>

The evidence contrasting your findings is rather significant and,
AFAIC, indisputable.

Essentially Google and Facebook (maybe Yahoo as well) have all, at
various times, tried the "checkbox approach to authorization" and
found that users freak out, run away, call mom, go home and cry when
presented with such an interface. Without fail. Or rather, with a
bucket of fail.

Streamlining this procedure while also providing sufficient disclosure
about what's happening seems the nearest approximation we can get here
without having the utility of OAuth completely diminished by
interfaces that presume far too much savvy or sophistication on the
part of the user.

Remember, users are busy, often multitasking and rarely stop to fully
think through decisions that they're making on the web. Doing more
work up front to make it so that certain apps only have the ability to
perform certain functions is one important aspect to keeping people
safe (it's not so much that the app itself might do something harmful,
but that a compromised system might use that app to do something
nefarious) — the other is making it easy for people to provide only as
much access as is necessary for the external application to
functional. Minimal access, minimized potential for harm.

For more on some of the authorization research that's been done, check
this out:

http://sites.google.com/site/oauthgoog/oauth-practices/user-interface

Chris

[Chad Etzel]

On Thu, Apr 16, 2009 at 7:19 PM, Chris Messina <chris....@gmail.com> wrote:
>
> On Apr 16, 2:59 pm, Lachlan Hardy <lach...@lachstock.com.au> 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/).
>>
>> Why is that? Do you have any evidence against it?
>>
>> My own (limited, informal) testing tells me people feel more in
>> control with checkboxes.
>>
>
> The evidence contrasting your findings is rather significant and,
> AFAIC, indisputable.
>
> Essentially Google and Facebook (maybe Yahoo as well) have all, at
> various times, tried the "checkbox approach to authorization" and
> found that users freak out, run away, call mom, go home and cry when
> presented with such an interface. Without fail. Or rather, with a
> bucket of fail.
>

+1. As soon as I add another option/checkbox/knob to tweak in one of
my apps, there's an outcry of "it's too complicated" and they never
come back. I love checkboxes, and there are certainly those that like
to have super control over everything, but I'm afraid we are in the
very very small minority.

I think "Allow" or "Deny" is all that most people will be able to
handle, so having the appropriate copy surrounding those choices is
the key thing.

-Chad