- Have a dedicated page for login
- Expose all required fields
- Keep all fields on one page
- Don’t get fancy
Friday, February 22nd, 2019
Thursday, February 21st, 2019
Monday, August 20th, 2018
A good half-hour presentation by Stephen Rushe on the building blocks of the indie web. You can watch the video or look through the slides.
I’ve recently been exploring the world of the IndieWeb, and owning my own content rather than being reliant on the continued existence of “silos” to maintain it. This has led me to discover the varied eco-system of IndieWeb, such as IndieAuth, Microformats, Micropub, Webmentions, Microsub, POSSE, and PESOS.
Sunday, July 1st, 2018
Here’s the video of the talk I gave at Design4Drupal last week in Boston. There’s a good half an hour of questions at the end.
Thursday, November 30th, 2017
Here’s the talk I gave at Mozilla’s View Source event. I really enjoyed talking about the indie web, both from the big-picture view and the nitty gritty.
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
Tuesday, January 22nd, 2013
Twitter has come in for a lot of (justifiable) criticism for changes to its API that make it somewhat developer-hostile. But it has to be said that developers don’t always behave responsibly when they’re using the API.
The classic example of this is the granting of permissions. James summed it up nicely: it’s just plain rude to ask for write-access to my Twitter account before I’ve even started to use your service. I could understand it if the service needed to post to my timeline, but most of the time these services claim that they want me to sign up via Twitter so that I can find my friends who are also using the service — that doesn’t require write access. Quite often, these requests to authenticate are accompanied by reassurances like “we’ll never tweet without your permission” …in which case, why ask for write-access in the first place?
To be fair, it used to be a lot harder to separate out read and write permissions for Twitter authentication. But now it’s actually not that bad, although it’s still not as granular as it could be.
One of the services that used to require write-access to my Twitter account was Lanyrd. I gave it permission, but only because I knew the people behind the service (a decision-making process that doesn’t scale very well). I always felt uneasy that Lanyrd had write-access to my timeline. Eventually I decided that I couldn’t in good conscience allow the lovely Lanyrd people to be an exception just because I knew where they lived. Fortunately, they concurred with my unease. They changed their log-in system so that it only requires read-access. If and when they need write-access, that’s the point at which they ask for it:
We now ask for read-only permission the first time you sign in, and only ask to upgrade to write access later on when you do something that needs it; for example following someone on Twitter from the our attendee directory.
Far too many services ask for write-access up front, without providing a justification. When asked for an explanation, I’m sure most of them would say “well, that’s how everyone else does it”, and they would, alas, be correct.
What’s worse is that users grant write-access so freely. I was somewhat shocked by the amount of tech-savvy friends who unwittingly spammed my timeline with automated tweets from a service called Twitter Counter. Their reactions ranged from sheepish to embarrassed to angry.
I urge you to go through your Twitter settings and prune any services that currently have write-access that don’t actually need it. You may be surprised by the sheer volume of apps that can post to Twitter on your behalf. Do you trust them all? Are you certain that they won’t be bought up by a different, less trustworthy company?
If a service asks me to sign up but insists on having write-access to my Twitter account, it feels like being asked out on a date while insisting I sign a pre-nuptial agreement. Not only is somewhat premature, it shows a certain lack of respect.
Branch and Medium are typical examples of bad actors in this regard. The core functionality of these sites has nothing to do with posting to Twitter, but both sites want write-access so that they can potentially post to Twitter on my behalf later on. I know that I won’t ever want either service to do that. I can either trust them, or not use the service at all. Signing up without granting write-access to my Twitter account isn’t an option.
I sent some feedback to Branch and part of their response was to say the problem was with the way Twitter lumps permissions together. That used to be true, but Lanyrd’s exemplary use of Twitter for log-in makes that argument somewhat hollow.
In the case of Branch, Medium, and many other services, Twitter authentication is the only way to sign up and start using the service. Using a username and password isn’t an option. On the face of it, requiring Twitter for authentication doesn’t sound all that different to requiring an email address for authentication. But demanding write-access to Twitter is the equivalent of demanding the ability to send emails from your email address.
The way that so many services unnecessarily ask for write-access to Twitter—and the way that so many users unquestioningly grant it—reminds me of the password anti-pattern all over again. Because this rude behaviour is so prevalent, it has now become the norm. If we want this situation to change, we need to demand more respect.
The next time that a service demands unwarranted write-access to your Twitter account, refuse to grant it. Then tell the people behind that service why you’re refusing to sign up.
And please take a moment to go through the services you’ve already authorised.
Wednesday, November 7th, 2012
Let’s be polite. Especially when starting relationships.
Saturday, February 11th, 2012
Andy sounds a cautionary note: the password anti-pattern may be dying, but OAuth permission-granting shouldn’t be blasé. This is why granular permissions are so important.
Monday, January 2nd, 2012
A one-stop-shop with links to the authentication settings of various online services. Take the time to do a little Spring cleaning.
Thursday, September 22nd, 2011
Dana has put together an excellent grab-bag of data on people’s password habits.
Friday, April 29th, 2011
Ben documents the improvements in Twitter’s OAuth flow. Maybe this will help to stop people blindly giving permission to dodgy third-party sites to update their Twitter stream.
Monday, February 9th, 2009
There's no such thing as a good CAPTCHA but if there were, these would be ...Best. CAPTCHAs. Ever!
Thursday, January 8th, 2009
A thoughtful post from Ben on how the flow of OAuth, OpenID and Facebook Connect can be improved.
Thursday, December 18th, 2008
"Facebook has rolled out an identity system â€” Facebook Connect â€” with a slick UI that trains a gazillion tech-naÃ¯ve users to slap their identity credentials into any old website."
Monday, September 22nd, 2008
David has written an excellent comparison of the two differing mindsets when approaching online authentication. In no uncertain terms, OAuth (or an OAuth style authentication) is right and the password anti-pattern is wrong, wrong, wrong.
Wednesday, June 4th, 2008
Brothercake looks at the problems, issues, and alternatives to requiring a human to prove that they're not a bot.
Friday, April 25th, 2008
As promised by Kevin Marks in the Q&A after my panel at South by Southwest, the Google Contacts API now supports OAuth. w00t!
Tuesday, April 1st, 2008
Now this is how to do the "find your friends" trick. For GMail, Yahoo Mail, and Hotmail, Flickr never once asks for your password. Bravo!
Tuesday, March 18th, 2008
Aral points to what is possibly the most egregious password anti-pattern implementation yet: a new startup called Spokeo http://www.spokeo.com/public/join
Friday, March 14th, 2008
A cautionary tale that explains just why the password anti-pattern needs to die. Coding horror indeed: in this case, 1,777 GMail accounts were compromised.