homepage Welcome to WebmasterWorld Guest from 54.161.155.142
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

This 476 message thread spans 16 pages: < < 476 ( 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 ... 16 > >     
Google Windows Web Accelerator
Brett_Tabke




msg:736302
 8:09 pm on May 4, 2005 (gmt 0)

[webaccelerator.google.com...]


System Requirements
Operating System: Win XP or Win 2000 SP3+
Browser: IE 5.5+ or Firefox 1.0+
Availability: For users in North America and Europe (during beta testing phase)

Press Release:

Google Web
Accelerator significantly reduces the time that it takes broadband users to
download and view web pages. The Google Web Accelerator appears as a small
speedometer in the browser chrome with a cumulative "Time saved" indicator.

Here's how it works. A user downloads and installs the client and begins
browsing the web as she normally would. In the background, the Google Web
Accelerator employs a number of techniques to speed up the delivery of
content to users.

Looks like some of the Mozilla hires are paying dvidends.

 

walkman




msg:736482
 9:36 pm on May 5, 2005 (gmt 0)

"You have a hidden link on your page"

consequences? maybe a ban ;)

jomaxx




msg:736483
 9:54 pm on May 5, 2005 (gmt 0)

Scarecrow, thanks for the info. Don't think I am comfortable rejecting requests based on IP address though, since I can imagine GoogleBot or the AdSense bot, or humans at the Googleplex for that matter, trying to access the site through that same IP range someday.

atadams




msg:736484
 9:59 pm on May 5, 2005 (gmt 0)

To counter Google's "7.5 minutes saved," someone needs to figure out how determine the webpages the the WA cache but are never accessed and put a display on their website: "Google Web Accelerator: 12.3Mb bandwidth wasted"

shorebreak




msg:736485
 10:04 pm on May 5, 2005 (gmt 0)

Phew, I just read ALL 19 pages to see if my question was already asked.

I'm not among the most technically inclined, but want to better understand what issue GWA poses to site's efforts to track user behavior and transactions with cookies?

Of all the things I've read on this thread, that's the one that has me most nervous.

-Shorebreak

incrediBILL




msg:736486
 10:10 pm on May 5, 2005 (gmt 0)

Another ponder for the day .....

How can I be sure that my connection to Google WA is as fast or faster, if now SLOWER, than my direct connection to the site I seek?

Let's see, I'm pinging Google and the RTT is avg about 20+, but the RTT on the site I'm going to is about 15+, so how is Google WA going to improve my access to this site? Also, how do I know what the speed is from Google WA to the site I'm seeking as it could be worse than my direct access time from my desktop!

Also, how do I know Google even has a connection to the site I seek [if they have no cache of it] at the time of the day I make the request when it could be accessed directly from my location but not from theirs?

Ah the tangled Web Accelerator we weave...

[edited by: incrediBILL at 10:13 pm (utc) on May 5, 2005]

abates




msg:736487
 10:11 pm on May 5, 2005 (gmt 0)

Having read this thread:
When the accelerator is pre-caching pages, is it loading them from the original web site, or the stored proxy copy?

It seems to me that in the long run this will save bandwidth rather than increase it, as if *everyone* on the net used it, they would all be getting copies of your page from Google's proxy rather than directly from your site, thus reducing your bandwidth.

To the people who are having trouble with users logging in and getting the unloggedin copy of pages, are you using the "Cache-Control" header in your request responses to prevent proxy servers caching the pages? I had similar problems with a message board on my site (with an ISP proxy server) until I added a "Cache-Control: private, proxy-revalidate" header to the response, and I'm curious to know if this will work with Google's proxy.

reseller




msg:736488
 10:11 pm on May 5, 2005 (gmt 0)

The Winner Takes It All!

Just thinking loud....

In theory, Google can force at least AdSense publishers to allow access of surfers using Web Accelerator.

And is it possible that Google use this tool to assist advertisers to qualify sites for the new AdSense "Site targeting: focusing on the audience" which Google is testing at present?

Is it also possible that we see sites, which are blocking this tool, loosing their positions on the serps for being "less surfer friendly" in the eyes of Google?

And who can stop Google from doing that?

Brett_Tabke




msg:736489
 10:13 pm on May 5, 2005 (gmt 0)

> is it loading them from the original web site,
> or the stored proxy copy?

No, it is grabing them live. This is twice as troubling when you consider the implications of generated content that looks like static.

incrediBILL




msg:736490
 10:18 pm on May 5, 2005 (gmt 0)

Brett, have you moused over a link to DELETE something yet?

I'd be interested in your experience with that :)

elsewhen




msg:736491
 10:22 pm on May 5, 2005 (gmt 0)

in most of the posts in this thread people are speculating that the data collected from WA will be used as another element to google's ranking algorithm... but what if it was used to supplement their most prized component to the algorightm - PR.

heres what i mean. PR was a great idea partly because it is an off-page metric - that way webmasters have more difficulty gaming the system... of course, this has been overcome.

but by tracking CTR of links on the internet with WA, google can factor this into the algorithm. so some link tucked in at the bottom of the page that no one ever clicks on, will not pass PR as much as a prominent link that everyone clicks on.

it could be a great way to prevent the gaming of PR that is currently going on, and it could salvage the one thing (PR) that brought them to such prominence in the first place.

so it might improve the SERPs in the long run, its just unfortunate that they had to do this to accomplish it.

incrediBILL




msg:736492
 10:27 pm on May 5, 2005 (gmt 0)

but by tracking CTR of links on the internet with WA, google can factor this into the algorithm

Yeah, give me a few thousands IPs and we can start a new business tomorrow gaming that idea with automated tools designed to randomly hit sites and supposedly make "random" clicks on customer sites to bump their PR.

elsewhen




msg:736493
 10:34 pm on May 5, 2005 (gmt 0)

Yeah, give me a few thousands IPs and we can start a new business tomorrow gaming that idea with automated tools designed to randomly hit sites and supposedly make "random" clicks on customer sites to bump their PR.

good point... but we probably wouldn't do this, because it is becomming increasingly difficult to reverse-engineer the algorithm. google is holding its hand very close to the chest as they are adding more and more off-page elements to the algorithm. some off-page elements that MIGHT be used:

  • CTR on the SERPs
  • CTR of links tracked via WA
  • sticky-ness of websites tracked via WA
  • manual site-checking using the people they recruited in online classefieds

Scarecrow




msg:736494
 10:41 pm on May 5, 2005 (gmt 0)

1. Cookies

Many sites, following login, assume that the cookie they plant will be offered by the browser on every page visited by that user subsequent to login. Does Google pass through your cookie properly? If so, they either do a scan of all your cookies with every page you surf, or they cache the cookies under an ID that is unique to you, so as not to confuse your cookied page with someone else's cache of the same page with a different cookie. Seems messy to me, and accident-prone.

2. POST forms

What about POST forms instead of GET forms? Does WA handle these properly?

3. Clicks you didn't make

What if Google clicks them for you? Examples are a) Click to add to shopping cart; b) Click here if you want us to send you news about our many special offers; c) Click here if you accept these legal terms; d) Click here if your browser or screen width is different; etc., etc. Is Google prescreening for forms and being very careful to let these through unmolested? What if these types of links are not in a form?

4. The bot-trap example

On one site I disallow bots from cgi-bin, and I catch a lot of Kool Kids in Dorm Rooms with their personal bots and unlimited bandwidth, by using a simple 1 x 1 cgi-bin image that links to a trap. A human has trouble clicking this link with a mouse even if they know where it is. But it's a lot easier to mouseover it inadvertently. Does WA avoid all cgi-bin prefetches, or what? I hope so. But what if it wasn't a cgi-bin link? Even a lot of cgi pages are disguised with static URLs these days.

____________

The problem is that with so much malware junk out there, and so many clueless users, the unwashed masses won't blame Google even if Google messes up frequently. They'll think it's business as usual. With WA, and the abiding faith that any WA user would necessarily have in Google as God, the mess-ups from Google will get blamed on us webmasters. The clueless user will think that our sites are broken.

Before now, malware was a problem for users, and webmasters could still be proud of sites that worked well, because they worked well for almost everyone. Now Google's WA is like malware for webmasters. It can make even our good sites look bad.

Xoc




msg:736495
 10:45 pm on May 5, 2005 (gmt 0)

But is Google honoring the Cache HTTP headers? If so, then no problem. If they aren't, then big problem. If I tell all download caches not to cache the page, and Google caches the page, then they are just doing it wrong.

I don't see what the difference is between the Google proxy and the AOL or any other proxy unless Google doesn't honor the HTTP headers.

Scarecrow




msg:736496
 11:10 pm on May 5, 2005 (gmt 0)

But is Google honoring the Cache HTTP headers? If so, then no problem.

Slight problem: the prefetches from the page. This is an escalation that the cache headers never anticipated. It should be opt-in.

NAME="google-prefetch" CONTENT="Google is allowed to screw up this page any way they possibly can"

Twice now I've scrambled for Google. The first time was when I had to install NOARCHIVE on tens of thousands of pages. The second was when they announced their image search a month after they started crawling images, and I had to scramble to put all images in a separate, disallowed directory.

This time they don't even offer an opt-out. But if they do, I'll still be unhappy because it should be opt-in.

Angonasec




msg:736497
 11:16 pm on May 5, 2005 (gmt 0)

Thanks Claus, I've blocked Google's WebAccelerator using the code you posted.

I already have about 20 Rewrite conditions that block various nasties (using the code from WebmasterWorld), so to avoid duplicating the last line
RewriteRule .* - [F]

I added your code to my existing block, which now ends like this: Can you confirm I've done it OK please... (There are no 'broken pipes' in my htaccess code, and I added the [OR] after ^EmailCollector)

RewriteCond %{HTTP_REFERER} q=guestbook [NC,OR]
RewriteCond %{HTTP_REFERER} iaea\.org [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
# google proxy: 72.14.192.0 - 72.14.207.255
RewriteCond %{REMOTE_ADDR} ^72\.14\.(19[2-9]20[1-7]) [OR]
# google prefetch
RewriteCond %{X-moz} ^prefetch
RewriteRule .* - [F]

Also: I don't run my own server, I use a very good shared hosting server, so does the prefetch blocking line still work for me? The htaccess file is in my root directory. I got the impression that you can only block prefetching if you host your own server.

BReflection




msg:736498
 11:45 pm on May 5, 2005 (gmt 0)

WebmasterWorld is now blocking users using Google's Web Accelerator.

Angonasec




msg:736499
 12:00 am on May 6, 2005 (gmt 0)

Brett: Well done, if you've begun using the Google WA blocking code.

Sends a clear message to G (your part-sponsors) that it is the punters who come b4 sponsors. No chicken n'egg situation here.

GG uninstalls WA pronto...

The Contractor




msg:736500
 12:11 am on May 6, 2005 (gmt 0)

hey, anyone go to webcams.google.com? They are offering free webcams and streaming services through them, but you have to leave them pointed at your monitor 24 hours a day.

...ok, just joking...had to lighten things up a bit

LeoXIV




msg:736501
 12:16 am on May 6, 2005 (gmt 0)

The more i think about, the more I admire Google's thought process. I'd like to add another item to my list of features for WA (1. detecting cloaking/better results; 2. having access to queries sent to Yahoo and MSN)

with WA, perhaps after a year or so, Google will have enough user behavior data to analyze them and finally create a system that truly understand each individual's search needs and provide individually tailored serps.

One step ahead of Microsoft.

[note to self]stop taking pseudoephedrine based allergy pills :-) makes you think you are really smart[/note to self]

claus




msg:736502
 12:25 am on May 6, 2005 (gmt 0)

Angonasec, nothing wrong with your code as far as i can see. It looks perfectly OK to me.

This line (below) i personally use exactly "as is":

-------------------------------
# google proxy: 72.14.192.0 - 72.14.207.255
RewriteCond %{REMOTE_ADDR} ^72\.14\.(19[2-9]20[1-7]) [OR]
-------------------------------

However, it seems that the Web Accelerator has sofar only been seen from the lower IP numbers, ie. 72.14.192.---. So, if you want to block less than the full range, you can just use this line in stead:

-------------------------------
RewriteCond %{REMOTE_ADDR} ^72\.14\.192 [OR]
-------------------------------

incrediBILL




msg:736503
 12:42 am on May 6, 2005 (gmt 0)

OK, just a silly thought....

Why block WA?

Redirect it to a page the describes why it's bad technology burning bandwidth needlessly and should be uninstalled - educate those masses in their hypnotic trance that drool and chant "Goooooogle" all day on the net.

GaryK




msg:736504
 12:45 am on May 6, 2005 (gmt 0)

Can anyone help out us Windows Server webmasters who use ISAPI_Rewrite? I can't seem to find a way to make it block a range of IP Addresses. Thanks.

christopher w




msg:736505
 1:33 am on May 6, 2005 (gmt 0)

Google needs to hire an SEO - try searching for Google web accelerator ;)

In all seriousness - I have been using it since yesterday and so far have saved over 25 mins....

mrMister




msg:736506
 2:00 am on May 6, 2005 (gmt 0)

In all seriousness - I have been using it since yesterday and so far have saved over 25 mins....

The figure that Google presents you is just a guesstimate on their behalf.

I've seen pages that load slower through the Google Accelerator, yet Google Accelerator still declared that it saved me time!

LeoXIV




msg:736507
 2:49 am on May 6, 2005 (gmt 0)

The data gathered is so valuable that it is even worth for Google to pay everybody to use it. we should coin a new term beyond 'freeware'. how about Loonieware? [it pays the user $1 per month]

note: we call our $1 coin a Loonie in Canada [From the image of a loon on one side of the coin.]

Powdork




msg:736508
 4:37 am on May 6, 2005 (gmt 0)

In all seriousness - I have been using it since yesterday and so far have saved over 25 mins....
Problem is, when I view my pages with it on it says I am saving time. Viewing it with it off the pages load much more quickly. These are image heavy pages.
GoogleGuy




msg:736509
 6:31 am on May 6, 2005 (gmt 0)

Hey, I was in training today, so I apologize that I didn't stop by earlier. But I did get a chance to ask for some more info about the proxy cache. Here's what I heard back from someone more familiar with the accelerator:

- We do not change the user agent.
- We do add an "X-moz: prefetch" header to all prefetch requests. That way, webmasters can choose to just ignore prefetch requests if they so choose.
- We only prefetch URLs which according to the HTTP 1.1 spec should not have any side-effects. These are basically GET requests without a "?".
- We also include an X-Forwarded-For header which provides the original IP address in case webmasters want to perform granular geotargeting.

I think using X-Forwarded-For is the usual way that proxies like squid pass on a user's original IP address? So the accelerator is like most caching proxies in that sense. I'll be heading to bed in a little bit, but hopefully I'll have more time tomorrow to post. But I'm happy to relay questions if people want to find out more about how it works.

mrMister




msg:736510
 6:48 am on May 6, 2005 (gmt 0)

We only prefetch URLs which according to the HTTP 1.1 spec should not have any side-effects. These are basically GET requests without a "?".

I have to say this sounds a bit errenous. The querystring is not the only way to pass data. Cookies can be used to pass data as well.

If Google are hell-bent on introducing this without allowing webmasters any control over it, then, in order to prevent side-effects, the application should not fetch URLs when a cookie has been set.

I really don't understand why Google are so adamant that webmasters should have no control over the app. The prefetching mechanism is, in effect, a semi-automated web crawler and therefore it should obey robots.txt

Well, at least we know how to block it now. We have to append a "?" to each of the URLs we don't want to be prefetched.

GoogleGuy, do you know if doing this will have adverse side-effects with googlebot?

Powdork




msg:736511
 6:55 am on May 6, 2005 (gmt 0)

For me it seems to be slowing firefox way down. However I am on a slow dsl connection. Is there a speed at which it changes from helping to hurting and if so what would that speed be?

dmorison




msg:736512
 6:56 am on May 6, 2005 (gmt 0)

- We do add an "X-moz: prefetch" header to all prefetch requests. That way, webmasters can choose to just ignore prefetch requests if they so choose.

What's the best server response to a request containing the X-moz: prefetch header if you choose to "just ignore" it?

I just checked the mod_rewrite docs and couldn't see a rule flag that means "drop silently"; so you have to return _something_. What's the best _something_ to return in order to avoid additional side effects?

The particular side-effect that i'm worrying about is the WA assuming that my attempt to ignore the request is the actual response and return that to the end user....

This 476 message thread spans 16 pages: < < 476 ( 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 ... 16 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved