I find it interesting how often developers tend to reinvent because of looking at a problem from only one perspective. Today I read a blog post by Sean Gephardt called RSS and syndication Ideas? where he repeats two common misconception about RSS and syndication technologies. He wrote

What if I only want certain folks to has access to my RSS?

I could require the end user to signin to my site, then provide them access to my RSS feeds, but then they would be required to sign in everytime they tried to update thier view.

More specifically, how could a company track people that have subscribed to a particular RSS feed once they are viewing it in an aggregator? Obviously, if someone actually views the page referenced, then web site tracking applies, but some aggregators I've seen simply render the contents of the description, which if it contains a URL to somewhere, and the user clicks that link, the reader gets taken over to that URL, bypassing the orignal.

Since there is no security around RSS and aggregrators, and no way to prompt users for say, a Passport authentication, should RSS be used only for "public" information? Do you make people sign in once they try to access the “deeper” content? Do you keep the RSS content limited to help drive people to the “real“ content?

Am I missing something glaringly obvious?

Considering that fetching an RSS feed is simply fetching an XML document over the Web using HTTP and there are existing technologies for authenticating and encrypting HTTP requests, I'd have to say "Yes, you have missed something glaringly obvious Sean". In fact, not only can you authenticate and encrypt RSS feeds with the same authentication means used by the rest of the World Wide Web, aggregators like RSS Bandit already support this functionality. In fact, here is a list of aggregators that support private RSS feeds.

As for how to how to track readership of content in RSS feeds. A number of tools already support tracking such statistics using web bugs such as dasBlog and .TEXT. One could also utilize alternate approaches if the feeds are private feeds since one could assign a separate URL to each user.

All of this is stuff that already works on today's World Wide Web when interacting with HTML and HTTP. It is interesting that some people think that once you swap out HTML with XML, entire new approaches must be built from the ground up.



Saturday, June 5, 2004 7:57:20 AM (GMT Daylight Time, UTC+01:00)
WebBugs? Please don't recommend web bugs, you're relying on the aggregator supporting their display, and frankly, I'd hope to see aggregators start to realise that the nasty little things are appearing and start to filter them out.

Come on, the web has spent the last few years increasing privacy support, now you want to through that work away just because you feel a need to track RSS? That's a backwards step.
Saturday, June 5, 2004 8:07:53 PM (GMT Daylight Time, UTC+01:00)
I think you missed the point, and possibly I didn't make it clear enough....

"Should RSS be used only for "public" information? Do you make people sign in once they try to access the “deeper” content? Do you keep the RSS content limited to help drive people to the “real“ content?"
Sunday, June 6, 2004 12:00:40 AM (GMT Daylight Time, UTC+01:00)
Your original post was about technical issues. The questions you are asking now are about how to manage access to content on your website. That's really decided by your website's content, its revenue model (if any) and your users. The choices for how accessible RSS feeds are for certain sites and how much content is exposed in the feeds varies very widely from site to site. There is no generic answer to the question and I'm unsure of why you'd expect one.
Sunday, June 6, 2004 2:32:17 AM (GMT Daylight Time, UTC+01:00)
I would have to agree with everyone here. Dare: yes, possibilities abound for solutions to some of these common problems. But, I dont know how common these concepts are in blogging software as well as aggregators. Sure the challenge response mechanism is widely supported, but such a method is not very user friendly when you want to have more public information than private in the same feed. How many rss aggregators support Cookies (the technology I chose to implement for the ease of use for users) though? Sure there are plenty of existing solutions to solve these problems, but how common are they and how easy are they to use? Now to the others though, Dare does have a point though that while the technology can sometimes be a barrier (as I also commented), it is the trickier questions related to what the goals of your feed, your audience, and your content are that are the tougher problems in this arena. J.P.
Comments are closed.