FF User agent fiascos

[GreyGeek]

As part of my dump Google efforts I switched my FF browser user-agent from Chromium to FF.

The first thing I noticed was that the YouTube videos would not buffer as fast, and at 720HD I experienced frequent interruptions while the stream caught up with the player. At the best the video would stop for a couple seconds every 15-20 seconds. Suddenly, when I attempted to play a YouTube video it appeared at full screen width, but only half the height. Hitting the play button got an instant message saying the video couldn't play "because one of the following protocols (vnd.youtube) isn't associated with any program". A reboot didn't cure the problem. I could no longer play any YouTube video. A DuckDuckGo search didn't show a fix for an unassigned vnd.YouTube.

So, out of curiosity I reset the user agent back to Chromium. Bingo! All videos played normally and the buffer shot down the progress bar well ahead of the video play point. All lagging caused by buffering stopped.

EDIT: I wrote too fast! YouTube videos showed severe lagging on videos I hadn't watched before. The new PBS SpaceTime vid from Dr Dowd would play for three seconds and buffer for a minute. It was obvious to me that part of running Chromium is getting special treatment by Google, and using a Chromium user agent didn't fool them for long. Chromium would be faster than FF on Google sites if Google was favoring Chromium browsers.

Anyway, I recalled that YouTube uses certain IP addresses to send filtered streams to end users and after doing some checking I found out that if I block the follow sites:
173.194.53.0/24
206.111.0.0/16
my video speed picks up tremendously. That PBS SpaceTime video, which I gave up watching about 5 minutes in, played smoothly, as the incoming stream stayed well ahead of the display and reached the end while the 15 minute video was less than half way done.

My router dispenses IP addresses in the 192.168.1.* range so I am using the following iptables rule:

iptables -I FORWARD -s 192.168.1.0/24 -d 173.194.53.0/24 -j REJECT
iptables -I FORWARD -s 192.168.1.0/24 -d 206.111.0.0/16 -j REJECT

and to delete them later if necessary I documented the following,

iptables -D FORWARD -s 192.168.1.0/24 -d 173.194.53.0/24 -j REJECT
iptables -D FORWARD -s 192.168.1.0/24 -d 206.111.0.0/16 -j REJECT

in case I need to remove the block. I know it blocks about 65K of address space , but I'll see how it goes. Hopefully there aren't any websites in that range that I want to use. Or, I could get lucky and block a lot of malware sites!

[wizard10000]

I'm using pepperflash with FF. Seems to work pretty okay, although I do use chromium as my primary browser. Debian and Kubuntu both have browser-plugin-freshplayer-pepperflash in their repos and that's all that's needed to use pepperflash in FF if you're interested - easy peasy

edit: I got you now. Things perked up as soon as you changed the user agent string back to chromium. Might still be interesting to see if pepperflash clears things up.

[Goeroeboeroe]

That's strange. I tried that dr dowd video and it plays well for me in Firefox, with the default userstring. Even in full screen (though quality is a bit less, of course). It buffers the whole video in about three minutes, and since the video is over 13 minutes that's fast enough.
Could it be you force Firefox in some way to use Flash instead of a <video>-format?

[GreyGeek]

That's strange. I tried that dr dowd video and it plays well for me in Firefox, with the default userstring. Even in full screen (though quality is a bit less, of course). It buffers the whole video in about three minutes, and since the video is over 13 minutes that's fast enough.
Could it be you force Firefox in some way to use Flash instead of a <video>-format?

Nope. Don't have flashplayer installed. HTML5 is being used. With those two websites blocked I get excellent speed and no stuttering or lagging.

BTW, ufw and gufw on the advanced tab work well to set up those rules.

[dequire]

I have a similar, possibly related issue in that I watch my local news on Livestream.com. Firefox will not play the stream after about 30 seconds, without fail. When streamed in Chrome it works like a charm. When I first read your post I was thinking maybe Google intentionally makes it's Youtube streams less optimized for Firefox (whether intentional or not), but then I remembered my Livestream.com issue. I'll try later tonight using FF with UA-switcher set to Chrome and see if there's any difference.

[Goeroeboeroe]

That's very strange. I don't see why Google would intentionally slow down YouTube, because they live on advertisements.

It's not that I trust Google about that, because when I go to their webmaster tools in Firefox it takes about half a minute to load them. Per page, and I have to see five pages. In Chrome that takes just a few seconds. But that doesn't cost them money, Delaying YouTube cost them money.
If you're still interested, you could ask on the youtube forum. If it's intentional, more people must have noticed this.

It can't have to do with some crazy routing on the internet, because Chrome should have the same issue too, if that's the reason.
If more sites have this issue, like liverstream.com, it could have something to do with some kind of encoding Firefox has problems with. Maybe on YouTube not every html5-video has the exact same encoding.
Maybe a question for the Mozilla-forum?

[GreyGeek]

That's very strange. I don't see why Google would intentionally slow down YouTube, because they live on advertisements.

It's not that I trust Google about that, because when I go to their webmaster tools in Firefox it takes about half a minute to load them. Per page, and I have to see five pages. In Chrome that takes just a few seconds. But that doesn't cost them money, Delaying YouTube cost them money.
If you're still interested, you could ask on the youtube forum. If it's intentional, more people must have noticed this.

It can't have to do with some crazy routing on the internet, because Chrome should have the same issue too, if that's the reason.
If more sites have this issue, like liverstream.com, it could have something to do with some kind of encoding Firefox has problems with. Maybe on YouTube not every html5-video has the exact same encoding.
Maybe a question for the Mozilla-forum?

My thoughts as well. But then, even with my firewall setting my videos started lagging. I checked my firefox plugins (aboutlugins) and noticed that I only have the openH264 codec installed.

So, I installed Etherape and noticed that my IPV6 tunnel was being hammered. I stopped my aiccu service and that killed my tunnel, and IPV6 connectivity. Suddenly, Etherape's node display (and graphic) was filled with tons of connections carrying lables that began with dfw25s07-*****-1e100.net where the asterisks are a series of letters and numbers. Researching that I found these addresses are from Google! What is 1e100.net?

My TWC bandwidth is supposed to be 20Mbps. Several of those connections, not related to the actual YouTube videos, were sucking down 4 to 6 Mbps each! It was then that something which happened a lot and give rise to these postings occurred-- the youtube video was replaced by a lot of snow and a link suggesting solutions for my "slow" connection. Etherape's display went blank. I had my network manager displaying at the same time. All of its connections went blank, as if the network manager stopped working! After about 20-30 seconds they all came back and I could restart the video.

I began searching for more info about dfw***.1e100.net connections I discovered "Google DoS attacks!". Spiders, crawlers, Image scrapers, etc..., i.e., Google bots searching the Internet. IF I sent out that many bots I'd have FBI and FCC swat teams at my door with guns drawn, after TWC canceled my service.

Google uses that naming system for all of its connections so I can't just filter out ".1e100.net" sources.

Etherape also showed that videos aren't just being filtered by 173.194.53.0/24 and 206.111.0.0/24 sites. In Etherape's node display I saw other filtering by these sites: 173.194.141.232, *.143.248, *.57.80, *.141.168, *.141.153, 74.125.1.111 and others (with the dfw*.1e100.net naming).

So, I am going to delete those two rules from my firewall and start logging .1e100.net connections to see how many are made in a day.

[Goeroeboeroe]

I've read the article you linked to. But that's about 'attacking' a server, not just playing back a youtube video. (Typically Google to give one reaction, promise to get back and never return with some kind of answer, or more questions, or whatever...)

Since you get the question to solve a slow connection, just guessing, but could it be some kind of rogue add-on? I myself had once installed an add-on that secretly inserted an iframe with advertisements in every site I visited. But it was a pretty clever add-on, because you only got it sometimes, so it just looked like some advertisement on some sites. I warned Mozilla about it (very good documented what happened) and not even got a simple confirmation they received my mail. And when I see what's now happening with Ghostery, I can't say I have much trust left in how Mozilla handles security and privacy issues with add-ons.

Does this happen also if you start Firefox in the console with firefox --safe-mode (without add-ons etc.)?

[GreyGeek]

Even in the safe-mode with FF I was hit with over a dozen dfw google bots. All of them were coming through my single IPv6 tunnel IP address, as EtherApe showed. When I disconnected the IPv6 tunnel connection the dfw IP addresses showed up individually as IPv4 sources,l allowing me to count them. Google apparently shifts the dfw (and other prefixes) IP addresses (even though they all end with .1e100.net) around randomly so that at one moment a dfw is streaming an ad and another moment a YT video. Makes it impossible to block specific ports with the expectation of bypassing the stream filtering to avoid lagging. And, I haven't ruled out the possibility that TWC may be doing this through their servers because they oversubscribe trunk lines to maximize profits, and to do that they have to throttle some connections to give room for the over subscriptions.