| 12:26 am on May 7, 2005 (gmt 0)|
|Okay, so they introduce something that BREAKS MY SITE, and I should just be patient....why? |
If WA causes problems with your site, then it is not WA that is breaking it. Your site is already broken. Fix your site.
If you don't like what it is doing, then block it.
|Also, by #2, you seem to assume that their reasoning is as they state. That reason absolutely does not hold water. They're using it to ultimately make more money, at the expense of webmasters who did absolutely nothing wrong. That's not "evil?" |
Nope, I don't consider greed or self-interest, by itself, to be evil. I also don't consider spammers or telemarketers to be evil. Annoying yes, evil no. I have seen evil, and this ain't it. (this is the day after Holocaust Rememberance Day after all)
You have a way of blocking it. Do it.
The user has their choice of clients to use, and they can certainly chose to go through WA, and the service provider (you) has the choice of whether you want to serve them.
You can also voice your concerns, but you should at least be voiced in a reasonable way. Accusing someone of Evil for making a tool is not reasonable.
| 12:39 am on May 7, 2005 (gmt 0)|
Have to agree on the rather excessive overuse of "evil" for something that is just ill considered / or non-caring about the consequences.
I do find it strange though that because someone has hacked together a way of blocking it, that this is somehow an appropriate replacement for an opt-out process. After all, the fix works on the basis of an ip range that is (to be the best of my knowledge) unstated, and in flux. It's no substitute at all for an opt-out.
It also doesn't change the fact that from a wider perspective, this tool will undoubtedly generate large amounts of web traffic that will never be seen by a human being - for a potential very small time saving for those that are. Me blocking it from my site will do nothing to address this wider issue.
EDIT: Also, I think given the position Google occupy, they have a responsibility not to make this sort of tool available to a general population who will have no notion of the side effects of its widescale use. The fact that people elect to use it, does not mean they do so whilst in full posession of the implications. This sort of thing is also reinforced by time saving claims that are clearly bogus as detailed a couple of pages back.
| 12:48 am on May 7, 2005 (gmt 0)|
>> After all, the fix works on the basis of an ip range
Actually this is only if you would like to block all use of the WA...
Since G is sending X-moz prefetch headers only with the request for the page they are prefetching, you can block access to that specific request, but still allow those browsing your site to use WA without the prefetch capability...
IP blocking is a much more dangerous way to do this for 3 reasons. 1.) if you want to ensure it works you must update your block file every time they use a new address. 2.) you will be blocking real users from your site, who will very likely just go somewhere else. 3.) any G-bot with the same IP range will be blocked.
By blocking only the X-moz prefetch request, you are not dependent on, or subject to, any of the previous conditions.
The example on page 22 is *not* dependent on IP and only blocks the prefetch request.
| 12:56 am on May 7, 2005 (gmt 0)|
Accusing someone of Evil for making a tool is not reasonable.
to which I reply
Agreed, but they are using it (at least in test) or providing it to others who are using it.
Please be very careful about equating things to "Evil".
Now about the other parties site being broken, just because an automated tool screws up a site doesn't mean that the site is "broken", sites have a design point, if the site functions according to its design it would be considered correctly functioning.
The incorrect activity in this case is the activation of links that were not indicated to the prefecth system as beinging prefetchable.
This activity was carried out by the WA.
I still have not seen a definitive answer to the how do I turn OFF this thing.
I see an answer that throws back an error message that may or may not (I don't run *dows) make it to the user.
Tossing it back in Google's face by way of a redirect is interesting but it doesn't provide a good user experience, likewise the error messages.
I will wait a bit longer before I suggest the tar pit method of control.
| 1:10 am on May 7, 2005 (gmt 0)|
Last one, for real this time:
>> I see an answer that throws back an error message that may or may not (I don't run *dows) make it to the user.
I prefer not to go off half-cocked, so I tested it before I posted... with the .htaccess modification on page 22, the prefetch is blocked, but you can still navigate the site without any error generation... not much more I can say on the matter.
Have a good day all.
| 1:16 am on May 7, 2005 (gmt 0)|
Thank you Justin. Didn't want to provide any bad user experiences.
| 1:31 am on May 7, 2005 (gmt 0)|
I have also verified that blocking pre-fetch does not cause any problems for enduser surfing our site w/ GWA turned on. I find it annoying that now I can't use prefetching hints in any of my pages without having to muck w/ my Apache config every single time.
Also, has anyone verified that GWA does or does not honor Cache-control and Expires headers?
| 1:36 am on May 7, 2005 (gmt 0)|
I think good ol' Google pulled a switch on us. I put a block on the 72.14.192-207.* on one server yesterday, and left the other server unblocked. That was because almost all the prefetches were coming in on this range, and I figured that the 64.233.*.* range was not worth blocking.
Today on the unblocked server, the numbers switched around, so that the 64.233.*.* is the problem, and the 72.14.*.* is minor. That means I have to start blocking 64.233.172.* and 64.233.173.*
Fortunately, these are the only Class C addresses within 64.233.*.* that I know of that are used for legitimate (non-WA) search functions:
Therefore, a block on 64.233.172.* and 64.233.173.* Class C addresses should not have any side effects. If the WA switches again, I'm going to get suspicious.
Google wouldn't be playing games with us, would they?
| 2:07 am on May 7, 2005 (gmt 0)|
They giveth and then they taketh away (whoever they are).
Life is like that when folks play by their own rules.
The only question becomes what happens when the other side decides to play the same way?
And with that as something for some folks out there in the wacky WWW to ponder upon, I'll call it a night.
| 2:12 am on May 7, 2005 (gmt 0)|
|is that a joke oneguy...it had nothing to do with you, it's happening on this very page! |
No... I really messed up the forum display, and I wasn't using WA. I edited my post, and my edit fixed the issue I created / saw in my own browser.
I didn't mean to negate any seperate WA issue you might have had, apart from that. I only mentioned it because we were posting at the same time, and I wanted to be honest about what WA is messing up, and what it isn't.
It seems to be a terrible idea by itself.
| 2:23 am on May 7, 2005 (gmt 0)|
|Now about the other parties site being broken, just because an automated tool screws up a site doesn't mean that the site is "broken", sites have a design point, if the site functions according to its design it would be considered correctly functioning. |
Maybe from a web design standpoint that does not count as being broken, but as a software engineer, I never would have gotten away with that excuse.
To me, the WA breaking a site is the same as not checking for an error on every fopen when writing c code, and taking appropriate action on an error.
Writing firmware for HA servers and NUMA systems, we didn't have the option of just breaking if something we didn't like happened. And there are a lot of bad things that can happen to big ol servers, and to little ol websites.
Blocking a rogue client or proxy is certainly one of the legitimate options as far as fixing your site, as long as it is within the realm of your design goals. If it is not, then you have to find some other way to deal with fixing your problem.
| 2:39 am on May 7, 2005 (gmt 0)|
I subscribed now, after I enjoyed reading this topic. With Accelerator ON, the confirmation link in my email did not work! WWW page said:
You don't have permission to access /register.cgi on this server.
Occured again when I clicked "style codes" here!
| 2:45 am on May 7, 2005 (gmt 0)|
The webmaster help page at http://webaccelerator.google.com/webmasterhelp.html offers a vague overview of the accelerator.
1) It states that pages can be specified for pre-fetching using the link tag and pre-fetch attribute.
2) The page references the Mozilla specification for pre-fetching.
3) Google includes the X-moz header for all accelerator requests.
It seems they are trying to give the impression that the Google accelerator follows the Mozilla specification when this is not the case. The Google accelerator follows all anchor links. The Mozilla fetches only those links with the relation 'next' or 'pre-fetch'.
Given this major difference in operation, why is the Google accelerator using the X-moz header? If we block all requests based on this, then we also block the well behaved original Mozilla pre-fetch feature.
In the absence of a complete opt out option, shouldn't Google be using a unique identifier in the header.
| 2:54 am on May 7, 2005 (gmt 0)|
"We also include an X-Forwarded-For header which provides the original IP address in case webmasters want to perform granular geotargeting."
Then why did't Google implement this before releasing it as beta?
I load WA and go to Google and get Google U.S. I clicked on a few adwords that were not supposed to be targeted at me by accident. oops!
This should have been released as alpha to a select group imho.
| 3:11 am on May 7, 2005 (gmt 0)|
|Bill... your code and text improvements please... |
I would do it but I was so upset by Google WA's barbarian inconsiderate loutish affront to my site that I had to spend some quality therapeutic time at the pub this evening. Do you have any idea how much an hour of pub therapy costs in California?
Claus posted the redirect you need in msg #325, just change from Google.com to your domain/pagename.html
Then write some page that spreads fear, uncertainty and doubt about Google Web Accellerator and publish it at that redirect page. Lots of sample material to choose from in this thread.
Maybe by Sunday I can write coherent paragraphs again and will post an anti-GWA manifest :)
should gin and tonic be used to wash down antibiotics? oh well...
| 3:26 am on May 7, 2005 (gmt 0)|
I just checked our eCommerce site which automatically converts/targets prices for Canada/US/EU. with WA on, it just assumes you are in US.! :-(
[edited by: LeoXIV at 3:30 am (utc) on May 7, 2005]
| 3:29 am on May 7, 2005 (gmt 0)|
While you guys are at it, get to work blocking those adblockers [webmasterworld.com]. Be careful, there may be some unintended consequences [webmasterworld.com].
| 4:03 am on May 7, 2005 (gmt 0)|
|Eric Schmidt, Google's chief executive, did highlight a few broad priorities for the company, like adding more types of information to Google's index and using personal information about each user to answer queries better. "We are moving to a Google that knows more about you," |
Combined with the Google patent application [webmasterworld.com] which spells how they plan to integrate user behavior in the algo, I fail to see how you can't connect the dots and see this as a piece of spyware that gives google all of the data it could possibly want. However as they say you can lead a horse to water but you can't make it drink ...
| 4:22 am on May 7, 2005 (gmt 0)|
I'm with you on that one graywolf..
google = spyware. Time to find a new engine to use.
| 4:37 am on May 7, 2005 (gmt 0)|
|google = spyware. Time to find a new engine to use. |
I can't be the only one wondering...
Is this the showdown issue?
Does Google finally prove or disprove that the opinions of webmasters and techies are important to their long term success?
Many of us seem to think it was important for the rise of Google. I thought they already ran away with themselves, but I'm not so sure now.
| 4:50 am on May 7, 2005 (gmt 0)|
"I fail to see how you can't connect the dots and see this as a piece of spyware that gives google all of the data it could possibly want"
could've used your help a few days ago..I got hammered on Google's "search history" thread. [webmasterworld.com...]
| 6:18 am on May 7, 2005 (gmt 0)|
I wanted to stop by for at least one post before I went to bed. I talked to an engineer about this, and he said if you use the "Cache-Control: private" HTTP header then we don't serve it from our servers because we obey the http spec. There was also some helpful additional information on the Slashdot discussion, e.g. [yro.slashdot.org...]
I'll try to stop by this weekend; not sure if I can answer questions, but I'll try.
| 7:52 am on May 7, 2005 (gmt 0)|
|not sure if I can answer questions |
We've been formulating opinions about that and I'm in the lead in the fantasy game pool.
Just kidding, your input has been STELLAR under the circumstances, I'm a fan, you've performed above and beyond.
Even if I'm a cynic at heart :)
| 8:19 am on May 7, 2005 (gmt 0)|
I've read lots about this application, probably more than any other beta release in history. And I've managed to learn a little more about HTTP specs and web application development along the way.
Perhaps meaninglessly, but I wonder what happened during the alhpa test phase of this product. Was it confined to Google Labs employees who worked on it during thier 20% free time? It has that feel about it. As if they consulted each other, and the published specs, but completely failed to realize that we don't all understand and/or follow specs, and some of us even (gasp) intentionally break those specs - for any number of reasons. A simple example: http://www.google.com/accounts/Logout?continue=http%3A%2F%2Fwww.google.com
For the most part I don't see how this app is going to hurt me. There are a few things about it that concern me and which remain as unknowns - particularly in the area of log-on/log-off screens, shopping cart and a few admin scripts that I've developed. I've read the horror story of someone deleting database records because the GET action of a link was performed by the prefetch. And I've read where this is totally debunked. So while I don't know yet what to make of this particular scenario, I do know that I have employed regular links on my admin pages to perform database operations. And I do know that I would be highly highly upset to discover those actions were performed as a result of a prefetch. The intent was that I (or someone with the proper authority) actually CLICK the link, with a reasonable expectation that only by clicking would the action be performed.
So this weekend, I get to: Perform a search of every page on my web site to ensure that there is not an inadvertent link to the admin area - since logging in seems to be no longer required.
Start re-writing my apps to use form submits for critical operations. (You've forced me into using better processes)
It would have been nice, as in Not Evil, to have had some advance knowledge and time to consider the implications and to render fixes. Instead, I'm forced to wade thru literally thousands of posts in dozens of forums across the web to try to discern what is most critical and what is bunk. That's just not nice. May the chef burn the cookies next week! ;-)
Another aspect of this application this causes me to have a little concern. It seems as if Google itself is undecided about releasing this app. I tried to access the page and could not. Got the toolbar page instead. Then the page comes back. Then it disappears.. what's up with all this? Either it's in release or it isn't. This shows (to me) more than a little bit of indecision on part of the decision makers. Or maybe this is a case of too many chiefs. Whatever, it doesn't exactly inspire confidence.
| 8:57 am on May 7, 2005 (gmt 0)|
Stark, you´re 100% right:
Blocking is not the same as opting out - blocking is something you have to do because you can't opt out (as a webmaster).
And, it should be "opt in" in the first place, not "opt-out" (just like for users).
| 9:04 am on May 7, 2005 (gmt 0)|
Here are all the different ways you can block prefetch in htaccess [webmasterworld.com] (#61, #62)
Some might work for your server while others might not.
| 9:27 am on May 7, 2005 (gmt 0)|
|he said if you use the "Cache-Control: private" HTTP header then we don't serve it from our servers because we obey the http spec. |
Just saw this - sorry for posting three times in a row. Imho, the above is close to an opt out, although it is not specific to the WA.
As using this header might conflict with something else, it could turn out to be an opt out you can't use - but still, it's better than nothing.
| 10:10 am on May 7, 2005 (gmt 0)|
Sorry if this has already been brought up, but I skipped a bunch to post this question now...
Claus had a great post (#130) which got me thinking....
WHAT would keep Google from using this to serve UNWANTED advertising?
Kind of like links in about.com and others, where they are served back as a page within a page'.
(If I'm making sense, now we're up to the question:)
What's to keep them from serving YOUR page to a user in a frame, surrounded by ADWORD ADS FROM YOUR COMPETITORS?
Imagine if you will someone goes to your site and is served the following by Google:
¦ Competitor ¦
¦ Adword Ads Here ¦
¦ You Webpage ¦
¦ Content Here ¦
| 10:25 am on May 7, 2005 (gmt 0)|
|What's to keep them from serving YOUR page to a user in a frame, surrounded by ADWORD ADS FROM YOUR COMPETITORS? |
A supernova backlash from the webmaster community that would make this one look like a party popper. Google employees would probably walk, too. I wouldn't worry about it though, i'm sure this is ultimately about improving search results more than anything else.
At the end of the day, everyone here knows that Google is facing a harder time producing good quality search results, and the one thing that would help [any search engine] improve thier results is access to good quality surfing habits that shows where real users spend time on the web.
Personally, I think if they want to do that they should get into bed with ISP's and factor in data off their proxy servers rather than try and re-route the entire Internet through the Googleplex.
| 12:13 pm on May 7, 2005 (gmt 0)|
I removed the accelerator two days ago. I am unable to get high speed anything where I live, and am still on dialup.
The problem was that when I disconnected from the internet, I was not able to reconnect. My explorer would not bring up the auto dial dialog box. I tried everything to get mypc to dial.
I have all the latest Explorer updates as well as XP Professinal. Appeared as though the software was looking for something on my pc. I tried all the standard procedures, finally had to remove the only new piece of software I had.
When removing, the software tried to do somthing on the web, however I was not connected. I suspect the software was trying to inform google and maybe ask a survey "Why are you leaving me" qustion.
The software does not appear to have been fully tested.
| 12:25 pm on May 7, 2005 (gmt 0)|
The way google is entering our privacy, i think, soon, once you write a NickName in google search , say 'sobriquet' , it will display a list of all guys using this nickname for any program in the world ( any forum, yahoo id, hotmail id google is, etc etc etc).
It will then display the IP addresses of all such people, and then the country, location, city, locality, home address, bank account, family details, girlfriends, ... think more.... chat details...... and what not! just because you said "I Agree" .
Are we ready for throwing ourselves in the open for googles hunger for data?