Limiting the Audience for RSS Posts
The problem with RSS and feeds
I like RSS as a concept, but, where I’ve seen it used, it’s always felt like it’s missing one thing; the ability to dynamically limit the audience of some posts. This isn’t an inherent problem in RSS, but more how it’s been used as an all-or-nothing syndication method.
While there are many workarounds (e.g. having separate private feeds, each of which require authentication to access), I haven’t found a solution which would seem to work well with a reasonable number of dynamically changing groups. So I’m going to put out an idea which hopefully will start a discussion about implementing something which could handle that type of use case.
One of the things I discovered when I wrote the Enterprise Password Safe is that asymmetric crypto is great for doing access control. Having something which you can give away freely in order for people to give you information securely seemed a good fit for limiting the availability of feeds and posts, so I’m going to try to use those concepts to manage post and feed availability.
Reasoning
From the outset it’s worth making clear this isn’t going to include some type of DRM. This is about limiting the audience of posts, it’s not about trying to control what people do with the posts once they have them. This mechanism could be used to control who DRM material goes to, but nothing about it is designed to prevent someone taking a screenshot/copy of a post and sending it on.
There are people who believe that everyone should have their say, and in most cases I agree with that, but there are people who feel they should always have their say and their opinion should be more important than anyone else, which can damage a community, and so having the ability to make it harder for those people to get posts can make it harder for them to damage the community.
So here’s my initial pass at how this could work. If you want to implement this and try it out great, if you see or hit edge cases please let others know.
The details
Every reader would create a key pair; This could be derived from a password or created and stored somewhere secure in the cloud. The authenticity of the owner of this public key could be vouched for by a third-party, posting it their social media feed, or a web of trust arrangement.
The reading software of the person wanting to subscribe to a feed sends their name and their public key to an authors server. The author of the feed can then make a decision about which set of articles the reader should be given access to and puts them into the appropriate group or groups.
When the readers reading software wants to check and download new articles it encrypts the current time and the readers email address using their private key, then sends an unencrypted version of their email address and the encrypted bits of information to the authors server. The authors server then uses the unencrypted email address to find the readers public key, decrypts the timestamp and email address, validates they’re recent and for the correct email address, and responds with the articles appropriate for the groups the user is in encrypted with the users public key. When the reading software receives this it can decrypt it using the private key and treat the information appropriately.
It’s worth remembering groups can work negatively as well as positively; An authors server can be configured to treat membership of a certain group as a sign that no articles should be served to a reader, or that a limited set of articles should be served which commenting is not allowed on. How an authors server handles group membership precedence and meaning is entirely up to the authors configuration of the server.
Relevant considerations
Key management
There are probably many things to consider around key management. The main two I can think of are; Key Revocation - People lose devices; There should be a way for an author to say ‘This key is no longer under my control’. Multiple keys for one user - A users may have multiple devices, so the server software will need to be flexible enough to identify that any one of a set of keys can represent a user.
Author server authentication
All of this should take place over a TLS secured connection. This will reduce the chances of things being intercepted, and allow for the authors server to be validated via means of a server certificate.