Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Accelerator: Be Careful Where You Browse

Posted by timothy on from the press-three-for-random-deletions dept.

Eagle5596 writes "It seems that there can be a serious problem with Google's Web Accelerator, and I'm not talking about the privacy concerns. Evidently some people have been finding that due to the prefetching of pages their accounts and data are being deleted."

18 of 89 comments (clear)

  1. Just goes to show.... by Anonymous Coward · · Score: 4, Funny

    Google should have beta tested it first.

  2. Another POV... by Gothic_Walrus · · Score: 2, Insightful
    Something Awful had an article on this subject a few days ago.

    I'm not sure if I agree with the "Google is the new Microsoft" sentiments, but thinking before you install new software is always a good idea.

    --
    Goo goo g'joob.
    1. Re:Another POV... by Jerf · · Score: 3, Insightful

      Actually, that's yet another different problem, one where you get the wrong page from the cache, specifically somebody else's personalized page. It is completely unrelated, in the sense that one could fix either problem independently. (It is possible that they have the same root cause, but I doubt it.)

      This bring the current list of reasons not to use the Accelerator up to three, counting the obvious privacy issues.

    2. Re:Another POV... by orkysoft · · Score: 2

      I think the author is jumping the gun. I believe that this Google Web Accelerator was born from the "Hey, why not use Google's cache all the time when browsing sites on frequently slow servers?" idea, and that these issues are merely unintentional side effects that still need to be fixed (which will be pretty complicated if you ask me).

      Still, Google will have the opportunity to store virtually the entire browsing history of Google Web Accelerator users, which people should keep in mind when installing the program.

      --

      I suffer from attention surplus disorder.
    3. Re:Another POV... by Jerf · · Score: 2, Informative

      No matter what links you click on, you can't see another user's page, unless the web application is just horrifically badly designed, well beyond merely not quite conforming to a strict interpretation of certain HTTP standards that actually say "should" instead of "must". It is reasonable to assume many web apps use GET in ways going against the spec's recommendation, but surely if merely clicking a link could log you in as arbitrary other users, it would have been noticed. Not to mention only other users of Google's caching are showing up, indicating the bug isn't coming from random link pseudo-clicking.

      If you're getting pages from other users, it is a distinct problem from aggressive precaching.

  3. Bug in the pages, not Google by keesh · · Score: 5, Informative

    According to the HTTP spec, GET requests must not be used to change content. POST actions must be used if you're deleting / changing something. And google doesn't prefetch POST, does it?

    1. Re:Bug in the pages, not Google by toastyman · · Score: 2, Interesting

      Unfortunately, it's not that simple in the real world though.

      If you want to POST something, the only way to do that is to use a form. Forms cause a few problems.

      IE and Opera render forms slightly "creatively". Wherever a form ends, the browser inserts vertical space in many situations, some of which are unavoidable. This usually makes the page render very strangely. If I want a list of links, and some of them have side-effects and some don't - my choices are to make some of them forms and some regular <a> tags or make all of them forms. If I make some of them forms, the spacing on the page is inconsistent/wrong. If I make all of them forms, I lose a lot of functionality in the pages that don't have side-effects.

      If you want a regular text link to submit a form, you have to use Javascript. This creates a dependancy on Javascript for even the most simple of actions, and makes the links unbookmarkable, and uncopy/pasteable into another window/browser.

      If you want to avoid javascript you have to use images or rather ugly UI buttons for every link. Images aren't always appropriate (download times, accessability issues, etc) and there's no way to put a TINY submit button on the page for little-used functions if you're using the standard submit buttons the browser provides.

      Other issues with form POSTing include the inability to use the back button after POSTing. Even if we can deal with rePOSTing of the same data on the server side and handle it correctly and gracefully, there's no way for webmasters to tell the browser not to pop up with the "Are you sure you want to resend the POST action again?" window.

      So, if we choose to follow the HTTP guidelines, we break UI and style guidelines even worse. If we want to use POST we have to give up having the page rendering correctly in major browsers, break the back button, break the ability to bookmark state information (unless you encode variables both in the URL in get fashion AND others in a POST), and make every link either an image(bad for accessability and download speeds) or use some Javascript magic (even worse for bookmarkability and accessability).

      I would love something like:

      <a href="/link.script" method="post" variables="a=1;b=2">

      or even just:

      <a href="/link.script?a=1&b=2" method="post"> (if the only goal is to use POST instead of GET, forgetting about the other differences)

      Things like this aren't clear "bad webmasters not following the spec" issues. When the browsers that all the clients are using don't give you the tools to use POST in any meaningful way, you're kinda screwed no matter what you do.

    2. Re:Bug in the pages, not Google by Anonymous Coward · · Score: 5, Informative

      If you want to POST something, the only way to do that is to use a form. Forms cause a few problems.

      With all due respect, even though forms aren't perfect, they've been around over a decade, and if you can't deal with them by now, don't bother calling yourself a web developer.

      Wherever a form ends, the browser inserts vertical space in many situations, some of which are unavoidable.

      You're kidding, right? If you don't want a bottom margin, say so with CSS. This is basic FAQ newbie stuff.

      If you want a regular text link to submit a form, you have to use Javascript.

      You can use CSS to make the button look like a text link.

      This creates a dependancy on Javascript

      No it doesn't. You can easily use Javascript without depending on it. That's the way it's supposed to be used. This too is basic newbie stuff.

      Other issues with form POSTing include the inability to use the back button after POSTing.

      Huh? Works fine here.

      there's no way for webmasters to tell the browser not to pop up with the "Are you sure you want to resend the POST action again?" window.

      That's not a bug, that's a feature! POST is not idempotent. Resubmitting a POST is something that absolutely needs to be warned about, because it's a fundamentally different action to reloading a page with GET.

      GET followed by refresh == just GET it again

      POST followed by refresh == send the server some more data

      So, if we choose to follow the HTTP guidelines, we break UI and style guidelines even worse.

      There is a reason submit buttons look different to links. It's because they do different things. There are semantics associated with clicking a button that aren't associated with clicking a link. If style guidelines instruct you to make submit buttons look like links, then the style guidelines are probably broken.

      So, if we choose to follow the HTTP guidelines, we break UI and style guidelines even worse. If we want to use POST we have to give up having the page rendering correctly in major browsers, break the back button, break the ability to bookmark state information (unless you encode variables both in the URL in get fashion AND others in a POST), and make every link either an image(bad for accessability and download speeds) or use some Javascript magic (even worse for bookmarkability and accessability).

      Wow. Get with the times. No really. I'd expect this kind of attitude from a newbie developer in the mid 90s.

    3. Re:Bug in the pages, not Google by sepluv · · Score: 2, Informative
      And just after that it goes on to say that, as it is expected that GET requests are sent without the explicit permission of a user, the server side (web developers) accepts all responsibility for any breach of the previous "SHOULD NOT" and have no right to blame the user side (users, Google) if they decide to make GETs do more than just retrieval of a document.

      FFS, how can these stupid web designers be threatening to sue Google when the HTTP itself (protocol of the WWW which they should all have read) says that it is there frigging fault and they should blame themselves if they use GET requests in that way.

      --
      Joe Llywelyn Griffith Blakesley
      [This post is in the public domain (copyright-free) unless otherwise stated]
  4. Stupid web developers by Anonymous Coward · · Score: 2, Informative

    The root of the problem is stupid web developers ignoring RFC 2616 and using the GET method to change state.

    Now all the people who cut corners thinking it didn't matter have been caught with their pants down, they look silly because the web applications they wrote are losing data, so they have gotten angry and pointed the finger at Google.

    Sorry kids, but this is what happens when you don't follow the specs. They are there to make all our lives easier, you ignored them, you fucked up.

    Yeah, maybe Google could have guessed the fact that you've fucked up and hobbled their software to hide your bugs. But you've got no right to complain that they didn't mollycoddle your stupid, broken web applications when it's you that broken them in the first place trying to cut corners.

    1. Re:Stupid web developers by zenyu · · Score: 3, Insightful

      The root of the problem is stupid web developers ignoring RFC 2616 and using the GET method to change state.

      Seriously, using POSTs was something we all learned in 1994... Hopefully, this Google accelerator thingy will be popular enough to rid us of these creaky old broken sites.

    2. Re:Stupid web developers by 0x461FAB0BD7D2 · · Score: 3, Insightful

      A lot of "stupid" web developers use GET so that those states can be bookmarked or sent to others so they can do something with it.

      Unless you have another idea, using GET for states is here to stay.

    3. Re:Stupid web developers by pk2200 · · Score: 2, Interesting


      You can use POST without sacrificing bookmarkability. After your code processes the POSTed request, redirect to a GET-style URL that provides a view to the same content.

      This technique is quite common.

  5. input type=image by slashkitty · · Score: 2, Informative

    It's quite easy and common.. and it's in the HTML spec. Too many people just create a GET link instead of a POST form becuase it's a little easier.

    --
    -- these are only opinions and they might not be mine.
  6. Re:What the cunting fuck. by mkavanagh2 · · Score: 3, Funny

    Oh, and obligatory "lol slashdot" comment: Think about what most people would be saying if Internet Explorer suddenly did this because Microsoft thought it would be a good idea. You'd be all over them like rats over a rotting horse cock.

  7. Re:What the cunting fuck. by mkavanagh2 · · Score: 2, Insightful

    It is still Google's fault. Any half-competent software engineer would have thought about this, and the people at Google did not. It doesn't matter if the websites affected were non compliant to the RFC, because they were the existing state of affairs. Google stuck this crap out there with no thought for the existing state of affairs, so it is their fault. It's the practical view of things, and the practical view is the only one that anyone should take.

  8. Re:What the cunting fuck. by sepluv · · Score: 2, Informative

    I wouldn't be quite so harsh. Isn't the point of early beta tests like this to find out how their UA works out there in the Real World? Apparently they've already issued a fix to solve the problem (or go some way to...I don't know the details).

    --
    Joe Llywelyn Griffith Blakesley
    [This post is in the public domain (copyright-free) unless otherwise stated]
  9. Appreciate the irony by Presto_slashdot · · Score: 2, Informative

    Nearly every highly-rated comment points the finger at "stupid" web designers rather than at Google, because GWA simply reveals that putting side effects on links is dangerous.

    I hope you appreciate the irony of posting such comments on a site whose Logout link is implemented via a GET (see upper left of your screen.) That's the point: every site implements Logout as a link, and Google should have recognized this.

    PS while I'm writing I might as well point out my previous GWA comment from a few days before this whole controversy. I was kinda hoping to shed some light on this exact problem. No one noticed, so I went and told 37signals what was going on ;)