Five days ago I proposed my article: Secure Web Feed Protocol, to the PST05 conference. Two days after I came around 15 things you can do with RSS. Two of these applications got my attention:

  1. Collect your email from all your email accounts in your RSS reader
    Stay updated on someone’s schedule
  2. I thought: these ideas are wonderful! What about the security of these services? Could they use SWFP? There is what I found.

1. Google is supposed to have tested a RSS feed service for Gmail in their GoogleLabs in 2004. I can not confirm if the service is always available because I do not have any Gmail accounts and I can not sing-in for one. This service put new incoming messages of a Gmail account into a RSS feed. Then if you subscribe to that feed you will see your new Gmail messages directly into your web feed reader. What an excellent idea! However, I was surprised to found that they used SSL to create a secure channel between the feed and the feed reader.

In the section 5 of the SWFP article I explained why I think that using SSL to secure a web feed is not the good strategy to adopt. It is for this reason that I was surprised to discover that they tried to use SSL to secure the inbox web feeds. JC suspected that they did not create it for this purpose but for another application called Google Notifier. I think he is right.

I do not know what was the real purpose of this test but the result is the same: the idea of using RSS feeds to check your mail is interesting. However, using SSL does not seem to be the good strategy to adopt. Not all stand alone feed readers support SSL. If you do not wish to enter the login and password of the private feed each time you want to check for new messages, you will need to do something like that:

https://USERNAME:[email protected]/gmail/feed/atom

This solution is even worse than not encrypting the web feed at all. With this string an intruder could sing-in into your account then check, delete or send messages with your Gmail account. It is far worse than only having access to the unencrypted inbox content.

This is a beautiful idea that could be handled by the Secure Web Feed Protocol. Now check out the second application of RSS feed that could use SWFP.

2. This time we are sharing our calendar with our friends and family using a service called RSS Calendar. When you add something to it all your friends and family will have access to your calendar’s changes. Is that not beautiful? Yeah it is. What about the security of this other service?

You could wish that the planet know that you are going to Mont Washington the 20 Mai 2005. But what if you only wish that your friends and family know it? There is no privacy feature in the service for the moment.

I think that the implementation of the Secure Web Feed Protocol could be really interesting in this case too. Only the people you choose would be able to read your calendar. I like the idea.

You are now thinking: how could the implementation of SWFP could be done in such services? The only thing that will change with what I discussed in the article is the way you will distribute the asymmetric keys

Technoratie: [] [] [] [] [] [] []

2 thoughts on “New applications of the Secure Web Feed Protocol – In Gmail and RSS Calendar

  1. I think that this is a wonderful idea. I have recently been working on something that behaves like an RSS reader but I hope to make it do many more things than just display feeds. The ability to have email feeds and other optional components is excellent and I would love to implement it.

  2. Hi Hussain,

    Wow, you dig deep in my blog to find that old blog post. I am happy to see that you like the idea.

    What you mean by “something that behaves like an RSS reader”? Are you talking about something that use RSS feeds but that doesn’t look-like/work-like a “conventional” Web Feed reader?

    It is a good idea to create feeds from email accounts, but the problem, as I said, could be one of security. However, if we take into consideration that the security is A one, then it’s wonderfull!

    But I would see another problem.

    By example, if I receive my email on my feed reader, I would also like to answer them form that same feed reader! It is what is really interesting with feeds: aggregation of information. However, I would also like to do something with that information: re-plying to the email, blogging about something, etc. The problem is that there is no way to feed readers to know if the feed came from a mail account and if so, how he can reply (the reply email address) to that item.

    In that case, why not creating an email ontology that we could use in RSS 1.0 web feeds that would publish emails information?

    Did I understand what you are trying to do: an aggregator that just doesn’t aggregate, but that also perform actions on that aggregated information?




Leave a Reply

Your email address will not be published. Required fields are marked *