474876 - Failure to load <script src> should result in error console messages

Status: NEW

(Core :: General, enhancement)

Description

[Simon Waters]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008122011 Firefox/2.0.0.12 (Debian-3.0.5-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) 

On learning of the issues with MD5 I removed certificate authorities that were using the MD5 algorithm in their procedures, and have added certificates of interest manually, mostly so I could understand how widely used they are, and flag any of my own certificates affected.

Doing this I discovered that on loading Google Adwords (over HTTPS - https://adwords.google.com) and attempting to run their "Campaign Optimiser", nothing happens.

On inspection this is because the "urchinTracker" function is defined at https://ssl.google-analytics.com/urchin.js, and used to launch the "Campaign Optimiser", and that the certificate authority for the certificate used by ssl.google-analytics.com was untrusted, which results in a silent failure. 

Firebug or other debugging quickly shows that the "urchinTracker" is not defined.

Explicitly visiting "https://ssl.google-analytics.com/urchin.js" and confirming the certificate fixes the problem, as does trusting the CA.

I'd have expected some sort of warning that some objects on the page were not trusted.

Reproducible: Always

Steps to Reproduce:
1. Disable CA used for ssl.google-analytics.com (Thwarte Premium Service CA)
2. Visit Google Adwords
3. Click the "Go" button to optimise a campaign.
Actual Results:  
The Campaign Optimiser silently fails

Expected Results:  
The page load should flag an error.

The is Iceweasel 3.0.5 on Debian.

I usually run with NoScript enabled, but disabled this during testing to ensure it wasn't NoScript breaking the site.

The behaviour when objects are retrieved over untrusted HTTPS is a policy decision, and the current behaviour would appear to be secure, if unhelpful to the user who experiences it.

Clearly the specific case (Adwords) is irrelevant, since people probably shouldn't (and won't) be removing CAs at random, but not complaining about the content that is ignored seems inconsistent with the vocal complaints when other aspects of a page loaded over HTTPS is incorrect, or element aren't from a trusted provider. It is plausible other browsers might have different trusted CA lists, and so this situation could arise in future and prevent sites working in Firefox that work in other browsers with no indication as to why it failed.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Actually causing the page load to fail or prompting the user actively is tricky, because there are likely pages that rely on invalid connections being ignored.

We could certainly add an error console message that the connection failed, though - I thought we already did that, in fact.

Comment 2

[Jesse Ruderman]

We don't log errors to the console for <script src> :(  This is true for non-SSL connection errors, too:

data:text/html,<script src="http://no.such.host.squarefree.com/"></script>

Comment 3

[Jesse Ruderman]

Having an error console message for <script src> load failures would have saved me several minutes throughout the years.  I think this is worth fixing.

Comment 4

[Simon Waters]

I'm intrigued at Gavin's comment about pages relying on invalid connections being ignored. Is this a case of pages being "broken" and no one noticing because nothing warns them? Or is there a case where this behaviour is actively utilized?

I'm not sure end users check the "error console", even when things don't work, so I'm not sure logging there would help that much more than the current behaviour, since the non-existence of the relevant function should be listed as a javascript exception, although it would be useful to have the cause of the issue reported before the error, since in this specific case the Javascript exists it just isn't trusted.