Post #206,319
5/6/05 5:19:57 PM
|

Google Web Accelerator is a Bad Thing
[link|http://37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php|http://37signals.com...app_designers.php]
Those of you who have web sites that people use to administer stuff might want to consider discouraging its use.
Ben
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,323
5/6/05 5:41:48 PM
|

Thanks, good to know.
That could be bad news with my company's app.
The local Google search thinger can cause havoc as well with source code repositories that use local working repositories, like Subversion, by keeping files open long enough to prevent their deletion on platforms like Windows.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #206,328
5/6/05 7:08:19 PM
|

Nice to see someone understands HTTP
The commenter(s) at 37s who quoted RFC 2616, that is. \r\n\r\n People who use GET for non-idempotent operations should be shot.
--\r\nYou cooin' with my bird? \r\n[link|http://www.shtuff.us/|shtuff]
|
Post #206,333
5/6/05 8:21:54 PM
|

Maybe, but it will mess up our user metrics
Since now we don't know which links the user followed and which were just prefetched.
I call foul.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #206,336
5/6/05 8:57:12 PM
|

I doubt this will be a problem for long.
Unlike the AutoLink fiasco, there's an actual problem here, so I expect they'll find a way to fix it.
--\r\nYou cooin' with my bird? \r\n[link|http://www.shtuff.us/|shtuff]
|
Post #206,353
5/6/05 10:41:54 PM
|

I beg to disagree
That is a SHOULD, not a MUST. In RFCs, SHOULD is a suggestion about what the suggester would like, not a mandate about what you need to do. Plenty of implementations of plenty of RFCs have decided that they don't want to implement a SHOULD item for various good reasons.
A good reason to not want to follow this one is that there is no convenient way to have regular HTML links that log you out (and will work if you have JavaScript off) without using a GET for a non-idempotent operation. You'll note that even gmail does this.
Furthermore it is unreasonable to expect that a large web application developed by a number of people will have no problems. Even if most of the developers have paid attention to this particular recommend (which they won't because most developers have never heard of it, and there are lots of cases where it makes sense to break it), it is unreasonable that you'll be able to quickly QA it for problems left by the remaining developers over a period of years.
Google should know this. I believe that it is their job as good web citizens to not deliberately create lots of problems for lots of people. If they do so and then refuse to stop doing so after widespread damage is proven, I suspect that they'll find that their click-through disclaimer that they are not liable will prove to not be as bulletproof as they might hope.
Furthermore Google has really screwed up if they are letting people see each other's personal information. Reality is that if you have an HTTP login or a cookie that is part of the request, change that and you should get very different results from the same URL.
Cheers, Ben
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,370
5/7/05 12:23:34 AM
|

It's a SHOULD NOT
And when disobeying a SHOULD NOT one should understand that the recommendation as made for the best of reasons, and that contradicting it it may well cause Bad Things to happen. \r\n\r\n In other words, if you do something the RFC says you SHOULD NOT do, don't be surprised if it comes back to bite you. \r\n\r\n And frankly, you're asking Google to cover for people's bad coding practice. I'm not sure I'm OK with that.
--\r\nYou cooin' with my bird? \r\n[link|http://www.shtuff.us/|shtuff]
|
Post #206,372
5/7/05 12:32:44 AM
|

Coming from them it would be hypocrisy
They have a non-idempotent logout link in gmail for exactly the reason that I outlined. They also pay attention to login credentials in gmail for exactly the reason that I outlined. The questionable practice is one that they do as well.
You may be holier-than-thou and have never done that, and your employer may have no employees who have done that, but if so then you and your employer are in a definite minority.
Again, if you set out to deliver a product that you know breaks a lot of existing stuff, badly, then you share responsibility for that breakage. It doesn't matter whether you're technically in the right, you're still wrong in my books.
It may be that we'll have to disagree on the merits of Google's actions. But as a practical matter, if they want to fight this, they will lose. They are not more important than the rest of the Internet.
Cheers, Ben
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,387
5/7/05 6:05:14 AM
|

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
5/7/05 9:58:29 AM
|

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
5/7/05 12:44:33 PM
|

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
5/7/05 5:18:27 PM
|

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
5/8/05 1:21:35 PM
|

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]
|
Post #206,380
5/7/05 2:56:22 AM
|

Shouldn't be a problem from our apps...
...since we use https (and I'd hope that the browser would respect that boundary). Most of the page invocations are via a javascript submit and a login token is used to do some rudimentary checking for the purpose of sequencing.
But, yes I think it's a bad idea if there's not an easy out (such as a nobots type of metatag).
|