
Is Google Burying Firefox With User Agent Strings? - adito
http://www.thepowerbase.com/2012/05/is-google-burying-firefox-with-user-agent-strings/
======
Matt_Cutts
I've been using Ubuntu for years with both Chrome and Firefox and I've never
seen issues like Firefox getting higher connection resets. I'm happy to ask
people at Google to dig into this report, but I have to say this sounds
completely off base to me. Google wants Google.com to work well with with
Firefox.

~~~
Natsu
A long time ago, I went through a period where I was getting a lot of resets.
But now, I'm just fine.

Perhaps it's just a problem with the particular machines he's connecting to? I
use Firefox almost exclusively and I haven't seen any resets for ages now.

~~~
diminish
I am using firefox, and chrome on linux for 5 years already, and didnt notice
such an error. I hope and don't expect Google to do ever such a trick to ff.

------
pilif
AFAIK, the chrome user agent switcher extension only changes the agent on a JS
level. You can't change what is being sent to the server due to limitations in
the extension API.

This explains the Adsense warning because the server-side part of the
framework used (gwt) is seeing a different user agent than what the client
part is seeing.

Granted, UA sniffing is bad practice on either client or server side, but if
you do it and send content tailored for browser A and then see that,
strangely, the client is actually browser B, then you are probably allowed to
be confused and complain (better than failing in strange ways).

Also knowing that, it's unlikely that something on the server side is causing
these connection reset issues because, as I just said: the server still sees a
chrome user agent and producing a connection reset error (RST packet) requires
connection level involvement (server or somewhere in between, but never the
client browser, minus bugs).

In general: be very careful what error messages you see: the Adsense error is
different from the gmail error which in turn is (likely) different from the
connection reset issue.

Overall there is too much conflicting information to attribute malice or even
just intent to Google here.

If I were in that users position, I'd check my firewall and/or proxy
configuration (and try disabling HTTP pipelining if it's active in Firefox -
it's disabled by default for a _reason_ ) as the problem is much more likely
somewhere over there.

~~~
Dylan16807
I would be surprised to have an internet company as big as google screw up
pipelining. How likely is that?

~~~
pilif
Not likely. But any proxy server in between might very well have. Including a
transparent proxy on the ISPs side that the original poster knows nothing
about

------
xoebus
Could it be that this is an innocent mistake or a bug in the way that Google
servers are sending HTTP. Chrome wouldn't be affected as it will be using SPDY
for all Google services. As soon as Chrome switched back to the Firefox user
agent it started using HTTP again and the same bug was found.

Besides, this just doesn't make sense. If this was an attempt to make Firefox
look bad then it's a dreadful one. This just serves to make Google services
look faulty as Firefox will still work for everything else. Because of this I
doubt there is any malice behind this and it is just a bug.

~~~
padraigm
Firefox has SPDY support as of a version or two ago and uses SPDY on Google
sites. I seem to that feature being on by default, even.

~~~
mbrubeck
SPDY isn't enabled by default until Firefox 13 (currently on the beta channel,
scheduled for release in four weeks).

~~~
frio
I wonder if that's what this is though: Ubuntu LTS having modified the FF
build they run to use SPDY by default (given the LTS is supposed to be out for
5 years now, they may have chosen to jump the gun on that feature), and the
SPDY support in the bundled FF isn't complete?

------
mgkimsal
I've been pretty consistent in my Firefox use the past few years (probably
>80% of my browsing is in Firefox), and I've _never_ encountered this. Ever.
I'm doing nearly all of this from OSX, with occasional browsing from FF and IE
in a Windows VM or FF in a Linux VM.

Perhaps this is more to do with a Linux string being picked up vs the Firefox
aspect?

~~~
w1ntermute
I've almost exclusively been using Linux on Firefox as my main browser for the
last 5 years. I also use pretty much every Google service under the sun, and
I've never seen any of these problems.

------
evmar
Another potential possibility:

Ubuntu Firefox is Mozilla's Firefox coupled with arbitrary modifications by
the Ubuntu developers. In principle I respect Ubuntu's position and desire to
make things right by their users.

But in practice, having been in the same relationship as an author of Chrome
for Linux I can tell you that it's always dangerous to have people who aren't
browser developers make modifications to a browser. More than once the Ubuntu
Chromium packager made changes to Chrome that were harmful for users because
they didn't understand the consequences of their changes.

~~~
el_presidente
Maintaining Chromium packages on Linux is a nightmare. Here's the line count
for different browser packages on Gentoo:

    
    
      408 chromium/chromium-20.0.1123.4.ebuild
      349 firefox/firefox-12.0.ebuild
      42  rekonq/rekonq-0.9.2.ebuild
      98  midori/midori-0.4.5.ebuild
      90  epiphany/epiphany-3.4.1.ebuild
      61  conkeror/conkeror-1.0_pre20120223.ebuild
      64  dillo/dillo-3.0.2.ebuild

~~~
mst
The interesting question isn't the raw number, it's what those 408 lines are
doing - it's entirely possible that half of that could go upstream.

For some years, lots of vendors had patches to mess around with perl's default
@INC order, all of which were distro-specific and not really generalisable,
because nobody had bothered to submit the upstream change that would have got
rid of that whole class of patches.

Now, I suspect the reasons for that may have been to do with perl's then
rather slower pace of releases, so people didn't see the point when perl5
version 10 was apparently not getting any closer, but just because that reason
doesn't apply to chromium doesn't mean there isn't a similarly convincing one
for local patches.

It also doesn't mean there -is-; I've always been fond of local patches to
software being corresponded with a distro bug and preferably with an upstream
bug explaining the rationale; it may not avoid the necessity for the patch but
it at least means the conversation that led to it is both visible and involved
the right people.

~~~
simcop2387
Looking through the ebuild it looks like a decent amount of it is related to
keeping it from using bundled libraries instead of the system ones when
building. After that it looks like most of the rest of the complexity is
related to getting things installed to the proper places.

------
gojomo
I would also suspect there could be something amiss in his ISP or network path
to affected sites.

Perhaps changing the User-Agent is making a difference, but not in the way he
expects. For example, his 'Firefox' User-Agent is 77 characters long, while
his 'Chrome' User-Agent is 106. That might be the difference between some
packets more often being a size that triggers a problem somewhere on the path.
(Or, the string or size might be triggering different handling in some
transparent proxy.)

------
AshleysBrain
It could just be connection problems/wifi playing up/whatever, badly timed to
coincide with the tests. I'm not sure this is much evidence really... Google
previously have been all for an open and competitive browser market (part of
the reason they started Chrome), they're not Microsoft in that regard, and I
doubt they have some code somewhere along the lines of "if (!chrome)
redirect_to_the_pentium_ii_in_the_basement();"

~~~
derefr
> if (!chrome) redirect_to_the_pentium_ii_in_the_basement();

I believe that code might go something more like

> if (!SPDY-capable)
> redirect_to_regular_somewhat_overloaded_http_load_balancers_without_resetting_client_ttl_value();

------
deniz
Even without this bug it's a stretch to think that Google would want to bury
Firefox. Google has a vested interest in Firefox's success. That's why they
pay Mozilla 300 million a year.

[http://www.zdnet.com/blog/btl/google-paying-
mozilla-300-mill...](http://www.zdnet.com/blog/btl/google-paying-
mozilla-300-million-per-year-for-search-deal/65921)

~~~
corin_
I'm not on the side of thinking Google are doing anything malicious here, but
worth pointing out that their paying Firefox money doesn't mean they wouldn't
neccesarily want to see Firefox die.

They pay that money not as a charitable donation but because the deal makes
them more in advertising than it costs. From a monetary point of view, of
course it would be better for them if all that advertising came from Chrome,
so they still make the money but they don't have to pay $300m because they
already own the browser.

------
cnbeuiwx
I never get any errors with Firefox on Windows, so this was a interesting
article. I will have to try it out some more on my Linux.

However, I got loads of "Connection was reset" when trying to use the
powerbase site where this article was. Server seems very very slow or
something is wrong with it.

~~~
angry-hacker
I get errors with Firefox on Ubuntu, but never on Windows...

Off topic: the pagination with blogs/news sites articles is total nonsense...

~~~
uxp
> pagination with blogs/news sites articles is total nonsense

Furthering the derail: Increases ad-space. Makes perfect simple sense to me,
though I may not agree with it all the time (or ever).

------
noibl
if (document.querySelector('h1').innerHTML.match(/^Is .*\?$/)) {
console.log('Probably not.') }

~~~
gildas
TypeError: Cannot read property 'innerHTML' of null

You should use UA sniffing to fix this bug.

~~~
noibl
Harr. :)

------
marshray
Packet capture or it didn't happen.

(OK, that's the cranky developer-speak for "If you can reproduce the problem
while taking a packet capture I'd be glad to help troubleshoot".)

I don't work at Google or on Chromium but I can take a look at it and pass it
along if it looks like something out of the ordinary. My email is in my
profile.

------
steve8918
I ran into similar problems at work where I am behind a proxy, where my
connection would time out to sites like gmail, etc. I think it had something
to do with cookies. When I revisited a site that timed out, but I went in
incognito-mode, I was able to instantly see it.

------
DanBC
I see similar errors very often. I use Google Chrome on OS X.

I also have a mobile broadband dongle (UK - T Mobile) which does weird and
unpleasant things to the connection. (All images are proxied with poor quality
versions, javascript is inserted into the page asking for key combos to
improve image quality; all alt tags are re-worded, etc.)

I blame any sub-optimality on the shitty broadband from T Mobile and the weird
proxies; then on overload from HN, then on errors I've made.

------
lordpenguin
For the record, the article poses a simple question and makes light of the
fact that the results are inconclusive. It should be taken with a grain of
salt, as the author intended.

------
shelf
Mozilla turn a significant profit through Google referrals, last time I
looked. The 'splintered' browser market masks a fairly comfortable arrangement
for both companies, as well as Opera. Don't assume a conspiracy where
incompetence or poor fortune provides a better explanation - chances are the
Gecko-optimised version you were loading had a minor bug, or there's a problem
with your system. Perhaps you encountered some A/B testing gone wrong?

------
mjcohenw
This article, with its black text on dark grey background, is incredibly hard
for me to read. It's almost like the author didn't want it to be read.

------
shocks
Doubt it. Tiny results set, huge accusations.

Works fine for me, Chrome & FF on Windows.

------
za
I wonder if the problem goes away if SPDY is enabled on firefox (it ships off
by default in v12)?

------
zobzu
Note that not all servers are equal.

What does that mean? Well, depending on your region, ISP, and a bit of luck,
you'll hit different Google servers, at different places, etc.

Some of them have different things, some of them have new updates others
don't, etc.

Which may be an explanation for the author having issues (then again it's just
ONE possibility).

Specially it could be that regular HTTP was failing and not SPDY for example.

Personally I haven't had that either.

------
jezclaremurugan
I've had the same problem while loading Gmail in Debian, but I blamed it on
the nightly build without checking.

However, Firefox nightly builds on Windows work without a hitch. I am
suspecting some firefox+linux combination messing things up. My two cents.

Try in windows, might give more leads...

------
driverdan
On a related note, do not use user agent sniffing. Use feature detection.
Sniffing is fragile and will be immediately out of date when browsers upgrade
/ add new features.

You shouldn't care which browser it is, you should care what features it
supports (or doesn't).

------
StavrosK
What if you change Chrome's UA string to Firefox's?

~~~
ddorian43
he did on the second page and problems started happening

~~~
StavrosK
Whoops, sorry, I must have missed that part.

------
stickfigure
TL;DR: No.

------
0xABADC0DA
Google search often breaks for me when behind a proxy, maybe for similar
reasons (sending different content based on the user agent). I don't know if
proxies have separately cached documents based on the user-agent or not, but I
regularly get a broken instant search (no results at all even after pressing
enter).

It's not all the time and I haven't investigated to find out what the problem
is... Bing search always works so I just use that.

------
tomerv
Does this mean that Google has given up completely on net neutrality? This is
a very bad notion.

~~~
tubbo
This article has nothing to do with net neutrality.

~~~
tomerv
I think it has a lot to do with it. Maybe not directly, but at the heart of
it, net neutrality is (in my opinion) about dividing resources equally.

~~~
Dylan16807
Net neutrality is about ISPs.

~~~
tomerv
Point taken.

