Subtle bug in Google can get you banned
I just had my IP banned from google and I couldn't understand why, after enabling the 'google toolbar'.
The toolbar is useful because it allows you to see the pagerank of your pages, after enabling it the browser will restart.
And that's where the problem will occur, if you have a large number of browser windows or tabs open when you do this (or if after a browser crash you do a recovery) google will interpret the flurry of toolbar requests when the browser comes back up as an attempt at automated requests to their servers and will block your IP accordingly.
Highly annoying! Effectively the use of one (luxury) google service disables the use of another one that is far more essential.
I hope there is a way out of 'toolbar induced google purgatory'.
update: I can use google again (after 15 minutes), but the toolbar still does not function.
28 comments
[ 4.7 ms ] story [ 64.4 ms ] threadhttp://www.google.com/support/toolbar/bin/request.py?contact...
The official toolbar should not exceed request limits that were designed to prevent PageRank scraping by third-party software.
"We're sorry...
... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now."
Right...
I'll try to file a bug with them, but my experience with google and support issues so far does not lead me to believe that anybody will actually read the report.
"I know this form is used to track new issues so I won't receive a response"
Does not give me great hope.
Thanks for the tip!
What a silly situation to be in.
I could change my IP by calling my provider but it is also entered in a fairly large number of ACLs that will not be updated automatically.
How about changing the toolbar code so it paces the requests to something that sits below the frequency of the 'ban for bot use' trigger? That would seem to me to be an obvious fix.
I'm assuming the toolbars can't communicate between each other. On toolbar launch, it should pick a random number between 1 and x and wait that many ms before contacting google. Pick x by looking at the number of req/sec that trigger a ban and the high-end number of tabs a power user might restart with. This would spread the requests out over that time period and keep it under the ban.
It's obvious the limiting is rate based, otherwise this would never have happened, so if it is rate based then the toolbar could pace itself to below that rate. Of course that would 'give away' the rate to observers of the toolbar during a browser restart but they could observe that just the same by checking when they get blocked, so that's no loss.
The toolbar knows I'm logged in, knows that a browser has just restarted and presumably can see how many instances/tabs are open (after all that's what it provides the info on) so it has all the data at it's disposal to make the right decision. This seems like a simple oversight to me (that a user installing the toolbar on a machine with a large number of tabs open would land in this situation).
Firefox extensions are Javascript CSS and XUL so I don't think that's obvious. I think it's entirely reasonable to assume that they might be sand boxed and have no awareness of each other. Is it one instance of the toolbar per "page-opened" event? Is it one instance per window? What I was describing was a way to stay under the limit without having centralized state-aware rate-limiting code. If that's possible, then yeah sure, do it that way.
It's obvious the limiting is rate based, otherwise this would never have happened, so if it is rate based then the toolbar could pace itself to below that rate.
It's not obvious to me. I think the issue is that the OP opens 50 tabs simultaneously after a crash and each window opens a connection to google without a rate limit of any kind. My idea was a way to do it without a centralized state.
Multiple Mozilla extension instances are indeed able to communicate via some centralised code.
Meh, I have trouble believing that spammers cannot experiment to find this number out themselves. The binary search on rate would require only a handful of IPs before you acquire it to a sufficient resolution for working purposes.
Of course, that solution is so simple, I'm sure there's a reason it's not possible.
If they do, isn't that precisely what Google would want? Isn't it only the rate and volume of requests that are a problem?
It's not an easy problem to solve.
Unlikely, I'm in the sticks, most people here are old and wouldn't know a mouse from a keyboard
> or a worm has been sending automated queries to Google.
That would have to be a linux based worm then. Unless that suspected worm is sitting on another IP of course.
Do you want me to try to make it reproducible ? I'd happily spend the time if it would help to make this problem go away. I understand how hard it is to differentiate between bots and regular users, but you should be able to pick up the difference between your own toolbar in normal use situations and a bot.
And if that's not the case then either the battle is 'lost' or it might be better to simply only let the toolbar query the google servers when explicitly asked to do so.