How to use Twimailer securely

TwimailerTwimailer is a nifty service that launched recently that makes Twitter BACN (“email that you want, just not right now“) more useful and informative (example).

The only problem is that it requires you to change your Twitter account email to point to an address provided by Twimailer — on the whole, not a big deal if you trust Twimailer, but in general bad practice. (Rod Begbie also pointed out that this prevents people from being able to find you by your email address).

Fortunately there is a better and more secure way to take advantage of Twimailer.

I’ll demonstrate in Gmail but really I’m just auto-forwarding new follower notifications from Twitter to your Twimailer address. That’s it.

  1. First, go ahead and sign up for a new Twimailer account. To get started, they just need an email address to send your notifications to. Twimailer will assign you a unique email address like twitter1234567@twimailer.com. Set this aside (copy it to TextEdit or something).
  2. Next, load up your Gmail inbox and search for “is now following you on Twitter!”. Open up one of the notifications from Twitter (the From email should be something like twitter-follow-your.address=gmail.com@postmaster.twitter.com). In the right hand drop-down menu, pick “Filter messages like this“:
    Filter messages like this
  3. You should then see an interface like this (click to enlarge):
    Create a filter
    Go ahead and test this search to make sure it’s working (presuming you haven’t deleted all your notifications).
  4. If everything looks good, go ahead and click Next Step and at check off “Forward it to” and enter your Twimailer email address that you set aside in Step 1.

    If you don’t want duplicate notifications from Twitter and Twimailer, you should also check off “Skip the Inbox” or “Delete it” (the message will still be forwarded).

    My setup looks like this (click to enlarge):

    Twimailer Filter

  5. Bonus: to filter or create a label for Twimailer notices, use this search: from:(notices@twimailer.com) OR to:(notices@twimailer.com).

That’s it!

It seems to me that this kind of feature improvement is something that Twitter should really do itself, but of course it’s great to see someone from the community pitch in and add incremental value until Twitter gets around to it.

At the same time, putting Twimailer in between you and Twitter’s password recovery mechanism seems unnecessarily dangerous (i.e. Twimailer could go down, get hacked, sold or might be simply be implemented insecurely (consider Spotify’s recent security breach)). I actually have no insight into these things about Twimailer, but I’d rather not take any unnecessary chances.

The approach that I described above should mitigate any risk with using Twimailer and keep you in direct control over your Twitter account.

Twitter can has OAuth?

Twitter / Twitter API: Call for OAuth private beta participants ...

Twitter API lead Alex Payne announced today that Twitter is now accepting applications to its OAuth private beta, making good on the promises he made on the Twitter API mailing list and had repeated on the January 8 Citizen Garden podcast (transcript by stilist).

It’s worth pointing out that this has been a long time coming and is welcome news, especially following Alex’s announcement to limit Twitter API requests to 20000/hr per IP.

But it’s important to keep in mind that, in light of the recent security breaches, OAuth in and of itself does not, and will not, prevent phishing.

It does, however, provide a way for Twitter to better track the use of its API, and to enable higher quality of service for trusted (paying?) applications and to surface them through a Facebook-like application directory. It also means that Twitter users will have finer grained control over which applications have ongoing access to their accounts — and will be able to disable applications without changing their password.

I’m on the beta list, so I’m looking forward to seeing what their current UI looks like — and what lessons we can extract for other services going from zero OAuth to a completeld delegated authentication model.

Twitter and the Password Anti-Pattern

Twitter / Alex Payne: @factoryjoe Yes, OAuth is ...

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.
Continue reading “Twitter and the Password Anti-Pattern”

Responding to criticisms about OpenID: convenience, security and personal agency

Twitter / Chris Drackett:  openID should be dead... its over-rated.

Chris Dracket responded to one of my tweets the other day, saying that “OpenID should be dead… it’s way over-rated”. I’ve of course heard plenty of criticisms of OpenID, but hadn’t really heard that it was “overrated” (which implies that people have a higher opinion of OpenID than it merits).

Intrigued, I replied, asking him to elaborate, which he did via email:

I don’t know if overrated is the right word.. but I just don’t see OpenID ever catching on.. I think the main reason is that its too complex / scary of an idea for the normal user to understand and accept.

In my opinion the only way to make OpenID seem safe (for people who are worried about privacy online) is if the user has full control over the OpenID provider. While this is possible for people like you and me, my mom is never going to get to this point, and if she wants to use OpenID she is going to have to trust her sensitive data to AOL, MS, Google, etc. I think that people see giving this much “power” to a single provider as scary.

Lastly I think that OpenID is too complex to properly explain to someone and get them to use it. People understand usernames and passwords right away, and even OAuth, but OpenID in itself I think is too hard to grasp. I dunno, just a quick opinion.. I think there is a reason that we don’t have a single key on our key rings that opens our house, car, office and mailbox, not that that is a perfect/accurate analogy, but its close to how some people I’ve talked to think OpenID works.

Rather than respond privately, I asked whether it’d be okay if I posted his follow-up and replied on my blog. He obliged.

To summarize my interpretation of his points: OpenID is too complex and scary, potentially too insecure, and too confined to the hands of a few companies.

The summary of my rebuttals:


Convenience

OpenID should not be judged by today’s technological environment alone, but rather should be considered in the context of the migration to “cloud computing”, where people no longer access files on their local harddrive, but increasingly need to access data stored by web services.

All early technologies face criticism based on current trends and dominant behaviors, and OpenID is no different. At one time, people didn’t grok sending email between different services (in fact, you couldn’t). At one time, people didn’t grok IMing their AOL buddies using Google Talk (in fact, you couldn’t). At one time, you had one computer and your browser stored all of your passwords on the client-side (this is basically where we are today) and at one time, people accessed their photos, videos, and documents locally on their desktop (as is still the case for most people).

Cloud computing represents a shift in how people access and share data. Already, people rely less and less on physical media to store data and more and more on internet-based web services.

As a consequence, people will need a mechanism for referencing their data and services as convenient as the c: prompt. An OpenID, therefore, should become the referent people use to indicate where their data is “stored”.

An OpenID is not just about identification and blog comments; nor is it about reducing the number of passwords you have (that’s a by-product of user-centered design). Consider:

  • if I ask you where your photos are, you could say Flickr, and then prove it, because Flickr supports OpenID.
  • if I ask you where friends are, you might say MySpace, and then prove it, because MySpace will support OpenID.
  • if you host your own blog or website, you will be able to provide your address and then prove it, because you are OpenID-enabled.

The long-term benefit of OpenID is being able to refer to all the facets of your online identity and data sources with one handy — ideally memorable — web-friendly identifier. Rather than relying on my email addresses alone to identify myself, I would use my OpenIDs, and link to all the things that represent me online: from my resume to my photos to my current projects to my friends, web services and so on.

The big picture of cloud computing points to OpenIDs simplifying how people access, share and connect data to people and services.


Security

I’ve heard many people complain that if your OpenID gets hacked, then you’re screwed. They claim that it’s like putting all your eggs in one basket.

But that’s really no different than your email account getting hacked. Since your email address is used to reset your password, any or all of your accounts could have their passwords reset and changed; worse, the password and the account email address could be changed, locking you out completely.

At minimum, OpenID is no worse than the status quo.

At best, combined with OAuth, third-parties never need your account password, defeating the password anti-pattern and providing a more secure way to share your data.

Furthermore, because securing your OpenID is outside of the purview of the spec, you can choose an OpenID provider (or set up your own) with a level of security that fits your needs. So while many OpenID providers currently stick with the traditional username and password combo, others offer more sophisticated approaches, from client-side certificates and hardware keys to biometrics and image-based password shields (as in the case of my employer, Vidoop).

One added benefit of OpenID is the ability to audit and manage access to your account, just as you do with a credit card account. This means that you have a record of every time someone (hopefully you!) signs in to one of your accounts with your OpenID, as well as how frequently sign-ins occur, from which IP addresses and on what devices. From a security perspective, this is a major advantage over basic usernames and passwords, as collecting this information from each service provider would prove inconvenient and time-consuming, if even possible.

Given this benefit, it’s worth considering that identity technologies
are being pushed on the government. If you’re worried about putting all your eggs in one basket, would you think differently if the government owned that basket?

OpenID won’t force anyone to change their current behavior, certainly not right away. But wouldn’t it be better to have the option to choose an alternative way to secure your accounts if you wanted it? OpenID starts with the status quo and, coupled with OAuth, provides an opportunity to make things better.

We’re not going to make online computing more secure overnight, but it seems like a prudent place to start.


Personal agency for web citizens

Looking over the landscape of existing social software applications, I see very few (if any) that could not be enhanced by OpenID support.

OpenID is a cornerstone technology of the emerging social web, and adds value anywhere users have profiles, accounts or need access to remote data.

Historically, we’ve seen similar attempts at providing a universal login account. Microsoft even got the name right with “Passport”, but screwed up the network model. Any identity system, if it’s going to succeed on the open web, needs to be designed with user choice at its core, in order to facilitate marketplace competition. A single-origin federated identity network will always fail on the internet (as Joseph Smarr and John McCrea like to say of Facebook Connect: We’ve seen this movie before).

As such, selecting an identity provider should not be relegated to a default choice. Where you come from (what I call provenance) has meaning.

For example, if you connect to a service using your Facebook account, the relying party can presume that the profile information that Facebook supplies will be authentic, since Facebook works hard to ferret out fake accounts from its network (unlike MySpace). Similarly, signing in with a Google Account provides a verified email address.

Just like the issuing country of your passport may say something about you to the immigration official reviewing your documents, the OpenID provider that you use may also say something about you to the relying party that you’re signing in to. It is therefore critical that people make an informed choice about who provides (and protects) their identity online, and that the enabling technologies are built with the option for individuals to vouch for themselves.

In the network model where anyone can host their own independent OpenID (just like anyone can set up their own email server), competition may thrive. Where competition thrives, an ecosystem may arise, developed under the rubric of market dynamics and Darwinian survivalism. And in this model, the individual is at the center, rather than the services he or she uses.

This the citizen-centric model of the web, and each of us are sovereign citizens of the web. Since I define and host my own identity, I do not need to worry about services like Pownce being sold or I Want Sandy users left wanting. I have choice, I have bargaining power, and I have agency, and this is critical to the viability of the social web at scale.


Final words

OpenID is not overrated, it’s just early. We’re just getting started with writing the rules of social software on the web, and we’ve got a lot of bad habits to correct.

As cloud computing goes mainstream (evidenced in part by the growing popularity of Netbooks this holiday season!), we’re going to need a consumer-facing technology and brand like OpenID to help unify this new, more virtualized world, in order to make it universally accessible.

Fortunately, as we stack more and more technologies and services on our OpenIDs, we can independently innovate the security layer, developing increasingly sophisticated solutions as necessary to make sure that only the right people have access to our accounts and our data.

It is with with these changes that we must evaluate OpenID — not as a technology for 2008’s problems — but as a formative building block for 2009 and the future of the social web.

Public nuisance #1: Importing your contacts

Facebook Needs OAuth

I’ve talked about this before (as one of the secondary motivators behind OAuth) but I felt it deserved a special call out.

Recently, Simon Willison presented on OpenID and called the practice that Dopplr (and many many others) uses to import your contacts from Gmail absolute horrifying. I would concur, but point out that Dopplr is probably the least offender as they also provide safe and effective hcard importing from Twitter or any URL, just as Get Satisfaction does.

Unfortunately this latter approach is both less widely implemented and also unfamiliar to many regular folks who really just want to find their friends or invite them to try out a new service.

The tragedy here is that these same folks are being trained to hand out their email address and passwords (which also unlock payment services like Google Checkout) regularly just to use a feature that has become more or less commonplace across all social network sites. In fact, it’s so common that Plaxo even has a free widget that sites can use to automate this process, as does Gigya. Unfortunately, the code for these projects is not really open source, whereas Dopplr’s is, providing little assurance or oversight into how the import is done.

What’s most frustrating about this is that we have the technology to solve this problem once and for all (a mix of OpenID, microformats, OAuth, maybe some Jabber), and actually make this situation better and more secure for folks. Why this hasn’t happened yet, well, I’m sure it has something to do with politics and resources and who knows what else. Anyway, I’m eager to see a open and free solution to this problem and I think it’s the first thing we need to solve after January 1.