Accessing Private and Authenticated Feeds - Why it's important
Niall Kennedy blogs about accessing private feeds, but doesn't mention that IE7 and Office 2007 doesn't support it.
Niall says:
HTTP Authentication works with most desktop aggregators but runs into trouble with most online aggregators which rely on a common feed store based on feed and/or link URIs.
He's close. The Common Feed Store in the new Microsoft RSS Platform is an offline store that can't handle authenticated feeds. Since Microsoft is heading towards (headed?) dropping a huge ball here, it'll really depend on Bloglines, My.Yahoo and Live.com to get it right and support secure, authenticated feeds.
Dare posts about Niall's post and has an interesting comment:
"At the end of the day, can Bank of America trust that RSS Bandit or Bloglines is doing a good job of adequately protecting the feed from spyware or malicious hackers?"
Of course they can't, just as BofA can't control that I might use any old HTTP stack to talk to their regular website. Angle brackets over HTTP are what they are. RSS just makes them more regular and a little easier to parse. It's true, a man-in-the-middle attack or trojan that targets offline aggregators would have a field day; but they would with any client and nearly any protocol.
Dare adds:
More importantly, even if they certify these applications in some way how can they verify that the applications are the ones accessing the feed? Niall mentions white listing user agents but those are trivial to spoof. With Web-based readers, one can whitelist their IP range but there isn't a good way to verify that the desktop application accessing your web server is really who the user agent string says it is.
I would propose within the context of banking, keying off Dare's comment, that OFX and RSS are arguably the same thing with RSS just being more presentation focused. OFX being pulled into Microsoft Money and Yodlee is no different from RSS being pulled into RSS Bandit or Bloglines.
What's more interesting a question to ask is, how can we integrate CardSpace-style trust - real trust - between a client and server over the wide open Internet while still allowing for the unattended retrieval of data? Multi-factor authentication just isn't possible given the RSS model at any point other than the initial subscription. We'll have to include an InfoCard (read: client-side cert) token within an HTTP POST (or long GET) request for an RSS Feed. That's at least 12-18 months away from adoption by the masses - and that's assuming that VISA gives free InfoCards away to everyone. It'll take someone with the power of VISA or AMEX to become a (free) Security Token Service (STS); adoption by Verisign who will charge us $14.95 will be a non-starter. But this is all future talk.
I say this: IE7 and Office 2007 not supporting Basic or Digest Authentication out of the box for accessing secure feeds will negatively affect adoption of RSS more than any other failing of the spec since its inception. It will slow adoption down at every level; it will make it harder for Financial Institutions to justify it and it will flummox internal Enterprises who don't have completely NTLM/AD infrastructure.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
I really like the idea of integrating
It's really too bad that IE 7 won't support authenticated feeds. That'll lead to everyone implementing their own authenticated feed support. That sort of security infrastructure is best left with the experts, or we get this type of thing happening.
What most aggregators do (desktop or web based) is cache items/feeds.
So even if Authentication and wire encryption is used the contents end up in a clear text cache either on the local system or the aggregator. Thus the so called secure items are no longer secure, in fact it is worse since the users assumes the information is still secure.
So how does one solve the cache issue, other than turning it of!
I think one of the key points here is that RSS is different to user based web browsing and the security model isn't really thought out from a users perspective (and actually from a developers perspective for that matter.). Thus even defining it as a purely developer issue is mistaken particularly in the age of Phishing. RSS can be made easy for the user, but secure RSS is a whole different ball game, and the user must get more involved in my opiion, perhaps providing a key each time the secure content is accessed for a given channel or item if aggregated/routed.
Niall was talking about my.yahoo.com leaking BaseCamp subscribers' information.
http://e.my.yahoo.com/config/cstore?.opt=search&.keywords=basecamp
I checked to see if there was any truth to it
and sure enough found out that there were many feeds I could access. I was told by 37signals that most of the RSS feeds were about 1 year old entries. However I could see some entries which were more recent. (However, when I rechecked a few minutes ago, I noticed that either 37signals or the most individual customers of basecamp had cleaned up many of the feeds).
as more and more companies use 2 phase authentication, they may become emboldened to use Private feeds and such
situations like the my.yahoo.com situations can happen.
BR,
~A
One lesson is to be careful who you trust. I wasn't comfortable with MoneyCentral having my info so I stopped using it. I probably wouldn't trust subscribing to a secure feed via Yahoo or Google.
Of course the average user might be fine with it, but they are really trusting that Yahoo is being safe with it. Then again, they probably have just as much personal information in their email accounts. They already trust these companies with their data. What happened with my.yahoo.com isn't an RSS specific problem but a general problem with security practices at these companies.
Two-factor authentication requirements is going to provide a big challenge for anything that is implemented in RSS right now, because all feeds going out of the bank, including RSS, will need to have the same level of protection. So building an RSS feed today, that you need to turn off in 3-months until there is a way to handle RSS two-factor, is just a waste of money for the banks.
Comments are closed.
From an application development standpoint, sure, it's a problem and it sucks, but in the Large Scheme of Things as far as app development is concerned... somehow I'm just not getting too worked up about this. (On the other hand, gimme ten minutes and I'm sure I'll be more agitated. I promise.)