544970 - Blocking .google-analytics.com prevents me from using some SSL sites

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Ben Bucksch (:BenB)]

For privacy reasons, because I don't want to be tracked across the whole Web, I block .google-analytics.com. I do that in my HTTP proxy.

On at least 2 websites, I cannot log in to my account using SSL. The page is loading forever, old page still displaying, not even a partial display of the requested page, and I see "Waiting for ssl.google-analytics.com..." in the status bar - forever, until I hit Stop or go elsewhere.

I cannot log in to these websites.

Affected:
https://sourceforge.net/account/login.php
http://www.sipgate.de
Probably others, too

Comment 1

[Ben Bucksch (:BenB)]

I file this as Tech Ev bug, but this should probably be fixes as Gecko bug. Gecko shouldn't block on non-critical parts of the page, including external JS files.

Comment 2

[Ben Bucksch (:BenB)]

Compare bug 544979

Comment 3

[Bryan]

Hmm, I block google-analytics.com using Adblock Plus 1.1.3 and have no issues with SSL sites at all!

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100208 Minefield/3.7a2pre (.NET CLR 3.5.30729) ID:20100208095921

~B

Comment 4

[Carlos Alén Silva]

According to http://osdir.com/ml/debian-bugs-dist/2010-04/msg05582.html Privoxy 3.0.16 should fix this problem.

"Please package 3.0.16 as it fixes SF#2790091 "Firefox fails to render
if https request for js is blocked"[1]. This bug/missing feature hinders
rendering of websites like sourceforge.net, ubuntu.com, etc., because of
privacyless trackers like google-analytics.com."

Comment 5

[Konstantin]

I may have a hint on the source of the problem, which I can clearly confirm with firefox-3.6.4, seamonkey-2.x on Linux and Windows.

Since my upgrade to seamonkey-2 some time ago I noticed that some web pages
stopped to load - a blank page was displayed (or old contents remains), the
progress indicator is showing that the browser is waiting but nothing happens,
there is no network traffic and there are no open network connections.
Sometimes the last information on the status bar is something like "waiting for
ssl.googlesyndication.com" and similar.

Tracking this revealed that because my squid proxy setup blocks some sites like
googlesyndication.com, doubleclick.net etc. by acls, when they are accessed by
https instead of http, mozilla browsers (tried seamonkey and firefox) got stuck
and there is no way loading a (SSL) web page referring to one of the blocked
sites. Only removing the block or using another browser (Konqueror and IE work
OK) allows to view the page.

The problem may be caused by the error message squid sends over the line when a
blocked page is requested which probably is not SSL encrypted. So the SSL code
gots stuck, it even does not recognize that the TCP connection has been
terminated and is waiting forever without a timeout for something.

With seamonkey-1 this problem did not show up but latest versions had other
encryption issues so I didn't try them lately.

It may be a squid bug as well that the error message is encoded wrong but the
browser should not get confused. My attempt to generate the bug by trying to
load an non-ssl-page over https results in an ssl_error_rx_record_too_long
error message so can't provide any other way to trigger the error except to use
squid (currently 3.0.19 but this didn't make a difference) with an http_access
deny acl to some ssl site.

Accessing the blocked sites over http does not make any trouble. Seems to be same or similar issue as bugs #493704, #512374 and #544979.

Comment 6

[Karl Dubost💡 :karlcow]

I propose to close this meta bug. 
It is either a non Tech Evangelism bug due to a different behavior in Firefox (and if it's still the case, let's open a proper bug in the right component.)

Or an evangelism bug for each individual site: If there are **still** any issues related to blocking related to contacting a Web site to fix an issue, please open a separate issue for each of them.  

If someone decides to reopen this specific bug, please provide HTTP traces with a detailed description and/or the exact setup to replicate the issue. 

Thanks.