Programming Social Applications

Abuse and Spam Protection

One of the largest challenges with this protocol has to do with preventing abuse and spam when the subscribers communicate updates back to the publisher. There are a few concerns that we need to address here:

1. How can the publisher ensure that the updated content is coming from a trusted source?

2. How can the publisher prevent spam or abuse if it is accepting content from a number of subscribers?

3. How can the publisher ensure the quality of the updates?

The Salmon protocol seeks to solve these problems by providing information about the source of the update through the upstream request. Specifically, each Salmon request has a verifiable author and user agent that the publisher can use to determine trusted content sources.

At a basic level, a publisher can follow certain steps to determine if the source of the Salmon update is valid. Let’s look at a simple example to showcase what this security flow may look like:

1. A subscriber site, subscriber.example.com, sends a Salmon request to the content publisher. The subscriber authors and signs the request with acct:[e-mail].

2. The publisher receives the Salmon request and uses protocols such as WebFinger, XRD, or LRDD (Link-based Resource Descriptor) to discover the identity provider (IdP) for acct:[e-mail]. If the IdP turns out to be owned by subscriber.example.com, then the publisher will continue with the verification process.

3. The publisher then verifies the signature using retrieved ...