Two things:

Google, to my knowledge, hasn't "fought" anything or pointed anyone back to the RFC. Other people have.

\r\n\r\n

Using a link to log out is non-idempotent, but not actually dangerous. The dangerous operations are ones like "delete all messages", and Gmail does not provide this functionality through links.

\r\n\r\n

And I do think it's hypocritical for application designers to build something which does not follow the RFC's recommendations, and then complain when it turns out to have a downside (particularly since this is not the first time such a problem with non-idempotent links has popped up; it's long been possible to do nasty cross-site attacks if you knew which URL paramaters another site used for certain operations).

I agree that there is no evidence that Google is fighting anything yet. But if they persevere in trying to get people to use a product that is this broken, they will.

As for dangerous operations, danger is in the eye of the beholder. For instance suppose that I'm using a site with a logout link from a public computer. First there is the minor annoyance that I can be accidentally logged out by Google. OK, so I log back in, I'm fine. Now I can't logout, though I might think I did because Google shows me the cached page. Now I walk away and am still logged in.

I don't know what you consider dangerous, but I hardly consider this safe.

For a more complex example, consider how difficult this site would be to use if Google was constantly marking forums read for you and you weren't getting uncached versions of the site. Not exactly dangerous, but rather annoying to say the least.

Judging from [link|http://z.iwethey.org/forums/render/content/show?contentid=206328|http://z.iwethey.org...?contentid=206328] you think that admin should be shot for having done that. I beg to differ, and think most people here would as well. Sure, as a result I can try to fool you into clicking on [link|http://z.iwethey.org/forums/actions/forum/markForumRead?forumid=27&markstamp=2005-06-07+09%3a43%3a08-04|this] to get you to exit this conversation. But for most of us the convenience of the interface far outweighs the potential risk.

As for your cross-site red herring, I call BS. First of all with most web toolkits a CGI parameter is a CGI parameter is a CGI parameter. Whether or not people use GET or POST on the front end, on the back end the form will accept and process the parameter. (Assuming that it fits in a GET of course.) Secondly even if you did worry about that fairly arbitrary distinction, it is trivial for other sites to write POST forms which target your script. They can even submit it for you with JavaScript.

In general if you're concerned with providing minimal protection against such nastiness, restricting dangerous operations to POST is a worse than useless first precaution. (It is useless because it doesn't solve the problem. It is worse than useless because you might think that you've done something about it when you haven't.) Instead you should check REFERER. OK, possibly you might restrict GETs in conjunction with locking down what HTML users can submit.

But in any case the point is that historically, potentially dangerous GET urls were not a problem. If someone is using Google's web accelerator, it is.

Cheers,
Ben

PS Disclaimer. I work for [link|http://www.rent.com/|http://www.rent.com/]. If you're a user using Google's web accelerator, user tracking will be all messed up. The result is that your odds of getting your $100 from us are greatly reduced. Even apparently idempotent URLs may be "dangerous"!

Post #206,387 by ubernostrum 5/7/05 6:05:14 AM Reply	Two things: Google, to my knowledge, hasn't "fought" anything or pointed anyone back to the RFC. Other people have. \r\n\r\n Using a link to log out is non-idempotent, but not actually dangerous. The dangerous operations are ones like "delete all messages", and Gmail does not provide this functionality through links. \r\n\r\n And I do think it's hypocritical for application designers to build something which does not follow the RFC's recommendations, and then complain when it turns out to have a downside (particularly since this is not the first time such a problem with non-idempotent links has popped up; it's long been possible to do nasty cross-site attacks if you knew which URL paramaters another site used for certain operations). --\r\nYou cooin' with my bird? \r\n[link\|http://www.shtuff.us/\|shtuff]
Post #206,397 by ben_tilly 5/7/05 9:58:29 AM Reply	Colour me unconvinced I agree that there is no evidence that Google is fighting anything yet. But if they persevere in trying to get people to use a product that is this broken, they will. As for dangerous operations, danger is in the eye of the beholder. For instance suppose that I'm using a site with a logout link from a public computer. First there is the minor annoyance that I can be accidentally logged out by Google. OK, so I log back in, I'm fine. Now I can't logout, though I might think I did because Google shows me the cached page. Now I walk away and am still logged in. I don't know what you consider dangerous, but I hardly consider this safe. For a more complex example, consider how difficult this site would be to use if Google was constantly marking forums read for you and you weren't getting uncached versions of the site. Not exactly dangerous, but rather annoying to say the least. Judging from [link\|http://z.iwethey.org/forums/render/content/show?contentid=206328\|http://z.iwethey.org...?contentid=206328] you think that admin should be shot for having done that. I beg to differ, and think most people here would as well. Sure, as a result I can try to fool you into clicking on [link\|http://z.iwethey.org/forums/actions/forum/markForumRead?forumid=27&markstamp=2005-06-07+09%3a43%3a08-04\|this] to get you to exit this conversation. But for most of us the convenience of the interface far outweighs the potential risk. As for your cross-site red herring, I call BS. First of all with most web toolkits a CGI parameter is a CGI parameter is a CGI parameter. Whether or not people use GET or POST on the front end, on the back end the form will accept and process the parameter. (Assuming that it fits in a GET of course.) Secondly even if you did worry about that fairly arbitrary distinction, it is trivial for other sites to write POST forms which target your script. They can even submit it for you with JavaScript. In general if you're concerned with providing minimal protection against such nastiness, restricting dangerous operations to POST is a worse than useless first precaution. (It is useless because it doesn't solve the problem. It is worse than useless because you might think that you've done something about it when you haven't.) Instead you should check REFERER. OK, possibly you might restrict GETs in conjunction with locking down what HTML users can submit. But in any case the point is that historically, potentially dangerous GET urls were not a problem. If someone is using Google's web accelerator, it is. Cheers, Ben PS Disclaimer. I work for [link\|http://www.rent.com/\|http://www.rent.com/]. If you're a user using Google's web accelerator, user tracking will be all messed up. The result is that your odds of getting your $100 from us are greatly reduced. Even apparently idempotent URLs may be "dangerous"! I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #206,408 by ubernostrum 5/7/05 12:44:33 PM Reply	Just to be clear I'm not arguing that Google shouldn't fix this; obviously it's a serious problem. I'm just saying, a lot of the problem wouldn't exist if people would follow the damn RFC. \r\n\r\n Also, a logout link doesn't, IMO, cause a problem. It changes state, so yes it's non-idempotent, but it doesn't take a destructive action. --\r\nYou cooin' with my bird? \r\n[link\|http://www.shtuff.us/\|shtuff]
Post #206,435 by dws 5/7/05 5:18:27 PM Reply	RFCs are clear on SHOULD vs. MUST Turning SHOULD into MUST in many an RFC would be a Very Good Thing, albeit too late to contain the damage.
Post #206,496 by ubernostrum 5/8/05 1:21:35 PM Reply	Yes they are. They're also quite clear that if you do something the RFC says you SHOULD NOT do, then you might well run into nasty problems, and that the SHOULD NOT is used with the best of intentions to prevent this happening to you. --\r\nYou cooin' with my bird? \r\n[link\|http://www.shtuff.us/\|shtuff]

Welcome to IWETHEY!