Webmention Abuse

I implemented webmentions on my site. They're like a modern, open implementation of pingbacks, a way for people on the web to be notified when others link to, "like" or "repost" their things.

Right now it's totally a DIY thing so hardly anyone uses it. At some point, plugins will be developed for WordPress and other CMSs and it could really take off at that point.

I see only one real problem at this point, and it's a big one that could easily sink the whole thing: webmentions are totally ripe for abuse.

Here's how they work in a nutshell. Suppose Dr. Drang's blog and my blog both support webmentions and he links to a page on my blog (don't ask me why).

1. His blog looks up the page that he linked to (joeldueck.com/posts/argyle-is-fun) and sees in the header of that page a link tag with rel=webmention and href=joeldueck.com/mentions.php. So now his site knows where to send the mention.
2. His blog software sends an HTTP request: to joeldueck.com/mentions.php with source=leancrew.com/argyle and target=joeldueck.com/posts/argyle-is-fun.
3. My site then checks his site to make sure it actually contains a link to joeldueck.com/posts/argyle-is-fun, and if it does, accepts the mention as "valid".
4. Now that the mention is accepted, my site can (at my option) display the mention on my post, and/or notify me by email, or whatever.

At least, that's how it works in theory.

Right now, abuse protection in webmentions is a complete afterthought. No one has implemented any security measures at all as far as I can tell.

The potential for abuse is certainly being discussed.

Possible abuses:

• Spammers could erect vast junk sites, fill them with links to valid blogs and spray out webmentions. These webmentions would look valid to most implementations as of today.
• DDoS attacks: Using the example above, someone who hates Dr. Drang could send me and a bunch of other bloggers a ton of webmention requests giving his site as the source. All of our blogs would then barrage his site to check the validity of these mentions.

Right now, the solutions being discussed sound much like the situation that has plagued email for the last couple decades: whitelists, blacklists, captchas, etc.

If there's anything we should learn from email it's that when the protocol isn't designed from the beginning to address abuse potential, you put yourself in a never-ending arms race against abusers.

From the current spec:

• The verification process SHOULD be queued and processed asynchronously to prevent DDoS attacks.
• Receivers SHOULD moderate Webmentions, and if a link is displayed back to the source, SHOULD link to source with rel="nofollow" to prevent spam.
• Receivers MAY periodically re-verify webmentions and update them.
• If a receiver chooses to publish data it picks up from source, it should ensure that the data is encoded and/or filtered to prevent XSS and CSRF attacks.

This is well and good as far as it goes, but it's not enough to keep abuse from potentially sinking the whole thing in the not-too-distant future.

"Moderating" webmentions may prevent spam from actually appearing on your site. But you're still going to get those junk webmentions in your inbox.

Moderating by itself doesn't prevent abuse.

If you have to wade through garbage, the abuse has already happened.

What needs to happen now

Right now abuse prevention is optional. The measures suggested by the spec are also insufficient.

The webmention spec needs to be updated as soon as possible to require:

• A clear mechanism for gauging and establishing trust of one site by another before webmentions requests from that site will even be evaluated
• Rate-limiting and checks for duplicate requests

Some kind of abuse mitigation needs to be baked into the spec before webmentions become widespread.

I've already implemented webmentions on my site, so I have skin in this game. At a minimum I'll be trying to design and code ways of mitigating abuse before it happens on my own web properties, now that I've opened that door.

But if in the coming months it turns out that abuse prevention remains an optional part of the spec, and people have to bake their own countermeasures (or not) on a site-by-site basis, then the writing will be on the wall.

An good idea from Nick Doty:

I think the spec should say that, when a receiver makes a verification request, it MUST include such a header, in order to mitigate abuse. The value should be set to the sender's IP address. … (more)

Vouch

Vouch is a proposal for abuse mitigation.

If A is sending a webmention to B (who don't know each other, i.e. B has never linked to A), A sends along a third parameter, "vouch=C", where C is a URL to a page that has a link to A's domain (thus "vouching" for A), and C's site is a domain that B approves of (e.g. has linked to in the past).

By doing so, A is telling B: please accept my webmention, because C, who you know or approve of, vouches for me.

That seems kind of baroque, but it doesn't have to be.

Returning to our scenario above:

1. Dr. Drang keeps a list of blogs he ‘follows’ or endorses, and so do I. And it so happens that Dr. Drang's blog is on my list.
2. Anyone who is on Dr. Drang’s list can now send me a web mention, even if I’ve never heard of them before.

The beauty of this approach is that it offers all the benefits of whitelisting without whitelisting’s super-rigid resistance to newcomers.

In my column on Microblogging with RSS I'm proposing that, in the future, blogging software would be fused with RSS reading. (Think Tumblr with its "follow" functionality, but self-hosted.)

The Vouch proposal for webmention abuse would fit very nicely with this model, if we allow follow lists to do double-duty as "endorsements".

So each blog will publish a list of other blogs it publicly follows -- basically a list of its RSS subscriptions.

These follows serve the purpose of Vouch's endorsements. Another blog could then send you a webmention if you follow them, or if a blog you follow follows them.

This automates the process of creating a vouch for webmentions you send, although the bulk of the "work" is still done on the sender's end. The sender simply needs to look up the follows of all the target's follows and see if it finds itself in there anywhere.