926701 - Force http/non-SSL for OSX/Linux visitors to mozilla.org and/or Firefox download page

Status: RESOLVED FIXED

(www.mozilla.org :: Bedrock, defect)

Description

[Chris More [:cmore]]

Per bug 925121, visiting browsers with mixed content blocking will have their downloads prevented due to OSX and Linux downloads being hosted on non-SSL CDNs. We are investigating how much it would cost to serve up everything via SSL, but it could be very expensive.

Why does this only affect OSX and Linux? Because the stub installer needs to be served over SSL  and it is now, but OSX and Linux users don't have a stub installer.

To make this work, we would have to force http on mozilla.org for only Linux and OSX platforms. That would mean that we would have to change references to download.mozilla.org to be conditional to either http or https depending on platform. Windows should always get https given they have stub installer.

https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/firefox_details.py#L9

https://github.com/mozilla/bedrock/blob/master/bedrock/mozorg/helpers/download_buttons.py#L29

Then we would have to redirect https > http on the Apache side so that a OSX/Linux visitor views http://www.mozilla.org/foo, clicks a download button, and is directed to http://download.mozilla.org/?product=foo, and gets a download file from a non-SSL CDN.

If we didn't want to do this site-wide, we could just force /firefox/new/, but there are plenty of places to download Firefox including the homepage and /firefox/all/.

Comment 1

[Chris More [:cmore]]

Attachment: Mixed content warning in Chrome on /firefox/new/

This happens when requesting https://www.mozilla.org/en-US/firefox/new/#download-fx

Comment 2

[Chris More [:cmore]]

The mixed content error seems to be only happening on /firefox/new/ where common-resp-min.js is making the request to an insecure CDN. All other download pages and buttons on mozilla.org have download.mozilla.org making the request to the HTTP CDN and Chrome will download. Could we improve /firefox/new/ to get around this problem even though it seems it shouldn't work on other mozilla.org pages.

Comment 3

[Alex Gibson [:agibson]]

I believe the reason this happens on /new is because the page initiates the download using an iframe, hence why it gets classed as a page resource and the mixed content blocker kicks in.

To fix this on /new without fixing the http redirect issue, an alternative download method would need to be used. I believe the iframe was introduced to prevent the images in scene 2 from being cut off when navigating directly to that scene. Perhaps using a delay before the download begins would be an option.

Comment 4

[Chris More [:cmore]]

Search engines are pointing to http://www.mozilla.org/[locale]/firefox/new/ and not the SSL one so for the most part, people are downloading from the non-SSL one now. The easiest way to resolve this is to just not use SSL on mozilla.org until downloads are served up by SSL, but that doesn't sound very security-friendly.

We would need to set a custom Google Analytics variable to measure http vs https traffic to mozilla.org as it is not available by default. My guess is that 90%+ is to http given that SEO points to http. While Google Chrome's search link is http, they redirect and force https on their website. 

The iframe is used because "dowload is initiated in an iframe so current page CSS images don't get cancelled before loading."

The download was unloading the page and we discussed a delay for all browsers instead of using an iframe. We picked and iframe so to keep the page more responsive, but maybe we have to go back to a delay with no iframe.

Mike: any thoughts here?

Comment 5

[Michael Gauthier [:gauthierm]]

Are you sure a delay will work? It might still give a security warning initiating a http download via JavaScript. I'll try it out and report here.

Comment 6

[Michael Gauthier [:gauthierm]]

I tried testing HTTPS with a 2 second delay and it works. No blocked download on OS X.

Comment 7

[Michael Gauthier [:gauthierm]]

PR at https://github.com/mozilla/bedrock/pull/1319

Comment 8

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/fc11a9f4855f1d361ecf6e23667d01c504ffd897
Merge pull request #1319 from gauthierm/fix-blocked-download-iframe-chrome

Bug 926701, 924824: Use window.location instead of iframe to trigger download.

Comment 9

[raymond [:retornam] (inactive)]

Tried in Chrome and Safari on OSX and Chromium on Linux

https://www.allizom.org/en-US/firefox/new/#download-fx
https://www.allizom.org/en-US/firefox/new/

both have no mixed-content blocking errors.