> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Blaine Cook > Sent: Saturday, May 02, 2009 5:12 AM
> Given that a service provider can reject any request that has a > referrer set (because desktop mobile apps *must* be, by definition, > referrerless), it's extremely difficult to exploit the desktop flow, > since the attacker would need to get the user to follow a link from > outside the browser and click "authorize" despite a strongly-worded > warning. This proved to be useless in practice which is why it was not included in the advisory. Most of the large providers have no easy access to referrer information and there might have been other reasons why it was considered impractical. There is a basic problem that most users don't read the fine print of authorization pages because they encounter them as part of an activity they would like to perform. It is not as if an authorization page jumps in front of them and surprises them. Putting big red warnings or using scary language will just cause users to drop, and will do very little to actually improve security. It is there mostly to make lawyers happy. When your OS asks for an elevated access to install software, how many people really stop to think what is going on? I think we need a completely different flow for clients that cannot accept callbacks AND where entering a verification code is not practical. This is an ever-shrinking subset of devices and so far I have not seen any real demand for it. Can anyone offer real life examples? Let's get real here. We are working on a quick patch. We are scheduled to perform a full and through review of the protocol in the IETF. Can't we just ignore clients that cannot accept callbacks AND cannot deal with manual verification code entry for now? (I'm asking). EHL --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
