Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Google Businesses Security The Internet

Google Accelerator: Be Careful Where You Browse 89

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."
This discussion has been archived. No new comments can be posted.

Google Accelerator: Be Careful Where You Browse

Comments Filter:
  • by cryptoz ( 878581 ) <jns@jacobsheehy.com> on Saturday May 07, 2005 @04:25PM (#12463764) Homepage Journal
    Perhaps we should start keeping our own data secure, rather than relying on other people to do it for us? I mean, if you're paranoid about people using this program and gaining access to our "sensitive" data, then it's your own damn fault. Your data shouldn't be so wide open on internet web pages anyhow. Bah.
  • by toastyman ( 23954 ) <toasty@dragondata.com> on Saturday May 07, 2005 @06:52PM (#12464450) Homepage
    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.
  • by Anonymous Coward on Saturday May 07, 2005 @07:34PM (#12464699)
    Quoting from section 9.1.1 Safe Methods of the HTTP 1.1 RFC (2616):

    Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

    In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

    There is a big difference between SHOULD NOT and MUST NOT. The fact of the matter is the web development community has used GET to perform "non-safe" actions. That is the reality of the current world. It was irresponsible of Google to simple look at a spec and interpret what "should be the way of the world", when in reality the world isn't that way.

  • by Anonymous Coward on Saturday May 07, 2005 @08:22PM (#12464935)
    Ignoring the fact that you now have accounts that are logged in, couldn't you just as easily make a public site that allows anonymous visitors to edit content -- let's say, a wiki -- with "delete" links sprinkled on it?

    What would you say to a webmaster that sticks "delete" links everywhere on their pages, and suddenly finds that Googlebot, in its daily rounds, wipes out their entire wiki?
  • by pk2200 ( 324678 ) on Sunday May 08, 2005 @12:41AM (#12466022)

    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.

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...