There's another issue lurking here, and that's just how much "typical Twitter end users" know about what an app can do once authenticated, either using the soon-to-be-history basic authentication or oAuth/xAuth. I think the page Twitter displays when asking "Deny/Allow" is fine, but I'd be surprised if people really read that. They just push the button. ;-)

What it all boils down to is that once you Allow for Read, the application can do *anything* in your account that the API can do with a GET, and if you Allow for Read/Write, which most applications do even if they only read, the application can also POST and DELETE. It can follow, unfollow, block, report spammers, read your DMs, post DMs, edit your lists, and, of course, tweet. And I'd also venture a guess that most "typical Twitter end users" don't know how to get to Connections/Settings and revoke access.

So I think another "developer principle" needs to be to clearly state which of the many available actions an app can take "on behalf of the user", how to detect if the app has taken other actions, and how to revoke access. Twiffiency semi-clearly stated that it was going to tweet, but it most certainly did not state what other actions it was going to take to compute the "score."

M. Edward (Ed) Borasky

"A mathematician is a device for turning coffee into theorems." - Paul Erdos

Reply via email to