Simon Willison's Weblog: whitelisting

Clearing up inaccuracies about the Google OpenID IDP launch

2008-11-08T23:11:31+00:00

Clearing up inaccuracies about the Google OpenID IDP launch

Google took some undeserved flack when they launched their OpenID provider. For the record, whitelisting providers fits my definition of the “Open” in OpenID perfectly (providers and consumers are free to impose whatever policies they like).

Tags: google, openid, whitelisting

Javascript protocol fuzz results

2008-06-30T15:57:36+00:00

Javascript protocol fuzz results

If your HTML sanitizer uses blacklisting rather than whitelisting here are a few more weird ways of injecting javascript: in to a link that you need to worry about—but you should really switch to whitelisting http:// and https:// instead.

Tags: blacklisting, firefox, fuzztesting, html, javascript, sanitization, security, whitelisting

OpenID and Spam

2008-04-02T19:33:25+00:00

OpenID and Spam

Matt Mullenweg: “OpenID has a ton of promise for the web—let’s not hurt it by setting people up for disappointment by telling them it’s a spam blocker when it’s not.” True for the case of general registration, but I still believe whitelisting known OpenIDs could be a powerful tool for fighting spam on personal sites.

Tags: matt-mullenweg, openid, social-whitelisting, spam, whitelisting

Crowd 1.1.0 Release Notes

2007-06-21T08:29:44+00:00

Crowd 1.1.0 Release Notes

Atlassian software are now offering a commercial OpenID provider, with the ability to hook in to an existing LDAP directory and some smart whitelist / blacklist options.

Tags: atlassian, blacklisting, crowd, ldap, openid, whitelisting

Six cool things you can build with OpenID

2007-02-25T15:48:13+00:00

I've posted the slides from my Future of Web Apps talk on OpenID, minus the demo videos. I'm planning to put together a video that combines the slides, demos and audio once the official podcasts have been published.

Apart from explaining what OpenID is and how it works, the key point I was trying to get across in the talk was that OpenID is a simple piece of infrastructure on which smart applications can be built - applications that may not have been possible prior to the adoption of OpenID. This is due to two important characteristics of OpenID. The first is that OpenID significantly lowers the effort needed in creating an account, to the point that people might sign up for accounts with services that they otherwise would not have used. The second is that OpenID provides a globally unique identifier that can be used to correlate information across multiple services.

Light-weight accounts

Vanilla OpenID gives almost no useful information about a user and provides no defence against spammers; for many applications it makes sense to couple OpenID logins to a one-time account creation process, requesting additional details and using e-mail verification and CAPTCHAs to deter automated scripts.

There are plenty of services for which this is not an issue. One neat use-case for OpenID is as a simple tool for extending the lifetime of session cookies, or sharing those sessions between different machines. If your site offers simple customisation features that are only of interest to the user (and hence have no value to spammers) you can use OpenID to persist their preferences. All you need is a way for a user to prove that they're still the same person they were yesterday.

Pre-approved accounts

OpenID lets you create accounts for people without e-mailing them a password, or even talking to them before you sign them up. There are lots of useful things you can do with this ability:

Let your trusted friends delete spam comments from your blog, or fix your typos.
Invite a selected group of people to contribute to your new collaborative weblog, without having to create new accounts for it or deal with yet another password.
Invite friends to view a private document or photo gallery, pre-approving their public OpenIDs as able to authenticate with your site.

Restricted SSO

Once more of the popular open-source applications start supporting OpenID, I can see it really taking off as a simple SSO standard behind the corporate firewall. Create an OpenID for everyone in your organisation of the form username.internal.example.org, then configure your internal applications (MediaWiki, phpBB, WordPress etc) to only accept OpenIDs that match that format.

Site-specific hacks

Lots of sites are setting themselves up as OpenID providers, leading to many users having multiple OpenIDs; I have OpenIDs from Vox, LiveJournal and AOL, all of which were created as a side-effect of me using those services.

I don't see this as being a problem. As a user, I can pick which is my "primary" OpenID (and use delegation so I can switch providers if I change my mind). Those other OpenIDs can still be useful though, because they let us build functionality that takes the providing site in to account. Here are a few examples:

"Log in with your LiveJournal OpenID and we'll import your LJ contacts using your FOAF file" (doxory.com does something along these lines).
"Log in with your AOL OpenID and we'll send you status updates over AIM."
"Log in with your Last.fm OpenID and we'll add events from bands you like to your calendar."

Sites that offer APIs should start thinking about how they can use OpenID as a simple vector for pushing data out to third party applications.

Social whitelists

I've talked about these previously; Tom Coates has further thoughts. By sharing whitelists we can use OpenID to build a simple trust network.

A similar concept is that of publishing groups. Jyte offers a simple API to export the members of a Jyte group. Not only does this make groups portable to other services, it also lets you build an authentication mechanism for a site that only allows members of a specific published group to log in to a service.

Decentralised social networks

The problem with social networks is that you end up with profiles scattered across multiple different sites, and friend relationships that are duplicated in multiple places. The globally unique identifier offered by OpenID offers the basis for a decentralised social network, with profiles tied together across multiple sites and relationships easily portable between services.

Hopefully the above ideas explain why I am personally excited about OpenID, and why I'm dedicating so much time to encouraging its adoption. The more people there are that understand and use OpenID, the more interesting applications we can build with it.

Tags: future-of-web-apps, openid, speaking, my-talks, whitelisting

Group Membership Protocol

2007-01-22T08:27:21+00:00

Group Membership Protocol

Martin Atkins’ proposal for a simple “is OpenID X a member of group Y?” protocol, useful for whitelists that can scale to handle large numbers of entries.

Tags: martin-atkins, openid, whitelisting

Social whitelisting with OpenID

2007-01-22T03:01:02+00:00

A key feature of OpenID is that it provides a globally unique identifier for every user, no matter what site or service they are using on the Web.

This gives us a powerful tool to fight comment spam. If someone has logged in with an OpenID and we are confident that they are not a spammer (remember, spammers can create OpenIDs too) we can add them to a whitelist, allowing their comments to skip any moderation step or spam guard that we might have in place.

This weblog has a comment spam detection system based on simple heuristics. Comments are assigned a score; if the score exceeds a certain level the comment is placed in a queue for moderation. As of today, one of the heuristics is "does the comment author have an OpenID that is on the whitelist". I've populated my whitelist with the OpenIDs of people who have posted two or more useful comments and do not appear to be using an anonymous provider. I'll be adding to it regularly in the future.

Here comes the social part: I'm sharing my whitelist. If you run your own OpenID-enabled weblog you are welcome to include my whitelist in your comment spam heuristics. If you publish your own whitelist, I will happily do the same.

Social whitelisting benefits from being de-centralised, just like OpenID. If I find that you have whitelisted a spammer, I can unsubscribe from your whitelist. There's no central authority or point of failure.

Long-time readers may be feeling a strong sense of deja-vu. Way back in September 2003, I proposed shared comment blacklists as a solution to weblog comment spam. The idea was simple: every time you delete a spam comment, you add the link it was advertising to a public blacklist. Other blogs could then subscribe to your blacklist and block any new comments advertising the same site.

The blacklisting idea was flawed from the very start. It was a classic example of Marcus J. Ranum's number one dumbest idea in computer security: Default Permit. Spam blacklists assume that if we don't know a link is bad, it's good. Spammers can create new bad links far faster than we can blacklist them.

Here's Ranum's suggested alternative:

The opposite of "Default Permit" is "Default Deny" and it is a really good idea. It takes dedication, thought, and understanding to implement a "Default Deny" policy, which is why it is so seldom done. It's not that much harder to do than "Default Permit" but you'll sleep much better at night.

Social whitelisting uses Default Deny. As such, I believe it has a much higher chance of making a useful impact on the comment spam problem.

Update: I should have mentioned that this idea developed over a number of discussions with Tom Coates, which totally slipped my mind when I was writing it up at 3am.

Tags: commentspam, moderation, openid, tom-coates, whitelisting