GSoC Project Idea: Encrypted RSS/Atom Feeds

schuyler1d's picture

Added to official ideas list at

Overview: With Encrypted RSS/Atom feeds, buddylist-like features become possible cross-site. The project would be to develop a module which generates and consumes syndicated feeds, where reading them in only possible behind a login.

Details: With all of the social networking sites these days, decentralized ways of connecting across communities are still being developed. One thing that's impossible now is sharing private blog posts with someone outside of your group. This project touches on social networking, encryption, both of which are fascinating, topical and good on a resume :-)

Drupal is a perfect platform for this, because of the wide use across micro-communities. With this module, two separate bloggers that use drupal should be able to share their private posts with each other without necessarily requiring a user name.

With this in place, future directions could lead to browser plugins which decrypt these feeds/microformats on a page with public keys.

Some relevant starting points:



Boris Mann's picture

I've looked at something like this for a while. Don't duplicate, look at adding feed_encrypt / feed_decrypt to the Feed API module set.

Also, the OAuth token system might fit in somehow to authenticate between sites on behalf of the user?

I actually think the cooler thing would be feed element level encryption with different keys (i.e. one post I can read, the next one I can't because it's keyed for someone else).

agreed on the

schuyler1d's picture

agreed on the non-duplication. Ideally, this would tie in, so getting the standard 'cornucopia' of contribs would give it to you automatically.

feed element encryption sounds interesting, but i'm not sure outside of a static system (which drupal is not), there's a reason not to give a custom feed/public key (via some hash in the URL).

Please check out

alex_b's picture

Please check out - isn't this what you're talking about?

OAuth is an emerging standard for this

Boris Mann's picture

And yes, it's token based.

Obscure urls for "private" feeds

jbrauer's picture

An additional idea I think could fit within the scope of this project:

Google Calendars uses the idea of a URL with a longish hash in it to provide "private" urls for somebody who wants to subscribe to content they'd rather keep private in a reader that doesn't support encryption (iCal etc).

This isn't a substitute for encryption but could be a nice supplement. My current "itch" in this area is that I'd love to subscribe to d.o/project/issues/user as an RSS feed. It is one of those things where somebody else reading the feed wouldn't be the end of the world but not something many people would want to be as simple as project/issues/user/userid ... The Google Calendar interface also has the ability for the user to go in and revoke or have the URL changed.

Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch

I like the idea of having

kyle_mathews's picture

I like the idea of having private urls rather then encrypting the feed or requiring a login. Many RSS readers don't support either of the latter two yet.

Kyle Mathews

Kyle Mathews

well, at the beginning, it

schuyler1d's picture

well, at the beginning, it would essentially be a protocol layer between drupal sites hooked up via aggregators. This would be the groundwork for browser support, etc.

The problem with private URLs is if you use online feed readers, the feed is often exposed to the world, and then a private URL isn't so private anymore.

I agree that requiring a login isn't very useful, comparatively.

That said, hashes (with auth_token) per member would probably be the address space anyway, so the 'private url' would be built-in, from the start.

+1 this project (in

btopro's picture

+1 this project (in concept). I agree that you could then pipe private data to the outside world but at least the use case I would be thinking of is creating a secure back channel from one drupal site to another so that you could securely share content via RSS. Maybe a use case would be that the owners of the two sites had an agreed to share content but can't expose it to the outside world due to copyright issues (such as educational materials that both parties need access to each other's streams but the content is copyrighted so not everyone can). Also more generally moving your content from one site to another so that you can manually edit / change the content on the end but don't want people to see where it's coming from (such as private blog out to a public one from many sources to annonymize the content for display to the end users automatically).


alex_b's picture

What aggregator will you build on?

I'd be happy to give advice on integrating this module with FeedAPI

+1 for integrating this

bonobo's picture

+1 for integrating this functionality with FeedAPI -- perhaps some combination of tokenauth and the FeedAPI?

Tools for Teachers

Already available

praseodym's picture

Private feeds are already available for some time; even this site is using a module which provides it ( Might be a bit too easy for SoC.


JerryH's picture

Looks good to me, all the options I've seen so far require user interaction or are done at the application level.

I'm checking out how to do this at the moment, but from a system and token approach.

I know its a bit early for

bobbyaldol's picture

I know its a bit early for gsoc 2013. But I am very much interested in this project. Do people still have interest in this project (I mean what are the chances that this would get accepted) because we now have a password based encryption system. But I think public key encryption will be more secure ans serves the purpose because many people dont want to give their passwords away to RSS readers.

Sandbox for the module

bobbyaldol's picture

I have created a sandbox for the module here
Any more ideas and views regarding this please leave them in the issue queue.