798611 - Remove hard http links on mozilla.org to eliminate mixed content warnings

Status: RESOLVED FIXED

(www.mozilla.org :: Pages & Content, defect, P2)

Description

[raymond [:retornam] (inactive)]

http://www.mozilla.org currently has
1) http://blog.mozilla.org
2) http://www.twitter.com
3) http://www.facebook.com 


links hardcoded. These links throw insecure content dialog messages in older versions of IE if you visit https://www.mozilla.org.

Comment 1

[Pascal Chevrel:pascalc]

there are thousands of pages on mozilla.org with http links, does it mean that mozilla.org can only have links to https external sites or did you mean only *.mozilla.org ?

Specifically, I don't expect community sites linked in mozilla.org pages such as http://www.mozilla.org/community/directory.html to switch to https.

Comment 2

[raymond [:retornam] (inactive)]

(In reply to Pascal Chevrel:pascalc from comment #1)
> there are thousands of pages on mozilla.org with http links, does it mean
> that mozilla.org can only have links to https external sites or did you mean
> only *.mozilla.org ?
> 
> Specifically, I don't expect community sites linked in mozilla.org pages
> such as http://www.mozilla.org/community/directory.html to switch to https.

Everypage on mozilla.org that has a download button should switch to https

Comment 3

[Chris More [:cmore]]

Here is a spreadsheet with src="http:// resources on Mozilla.org pages:

https://docs.google.com/spreadsheet/ccc?key=0AhRMMhzzlaRtdGFXazlkdE1VNHk3ZkVLVWZDaTFHWWc

We need to get the spreadsheet filled out as some are pretty easy changes.

Comment 4

[Kohei Yoshino]

I wrote a possible solution for this: Bug 638699 Comment 10

Comment 5

[Chris More [:cmore]]

(In reply to Kohei Yoshino from comment #4)
> I wrote a possible solution for this: Bug 638699 Comment 10

Yes, most will switch from http:// to just //, but we need to evaluate that the assets themselves can use HTTPS. Some domains are different from SSL vs non-SSL and thus we need to get the spreadsheet filled out completely before cutting over. I can re-run my shell script later to check mozilla.org for insecure content.

Thanks, Kohei for the help!

Comment 6

[Tanvi Vyas[:tanvi]]

There is a mixed content font on https://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/.  The ssl version is available though.

Can anyone make a quick change and switch
http://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,800,800italic,700italic

to 

https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,800,800italic,700italic

Comment 7

[Chris More [:cmore]]

(In reply to Tanvi Vyas [:tanvi] from comment #6)
> There is a mixed content font on
> https://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/.  The ssl version
> is available though.
> 
> Can anyone make a quick change and switch
> http://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,
> 600,600italic,700,800,800italic,700italic
> 
> to 
> 
> https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,
> 400italic,600,600italic,700,800,800italic,700italic

That content is here:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/firefox/23.0a2/auroranotes/index.html?revision=116266&view=markup

Lukas: Where do you get the source for these notes each release? Do you copy the previous files and make changes? Can you the the reference to the font in the head to https now and going forward?

Comment 8

[Tanvi Vyas[:tanvi]]

(In reply to Chris More [:cmore] from comment #7)
> That content is here:
> 
> http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/firefox/23.
> 0a2/auroranotes/index.html?revision=116266&view=markup
> 

Chris, can you or someone from your team update that content (for the aurora 23 notes).  I don't think I have access to change it.

Comment 9

[Craig Cook (:craigcook)]

(In reply to Tanvi Vyas [:tanvi] from comment #8)
> (In reply to Chris More [:cmore] from comment #7)
> > That content is here:
> > 
> > http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/firefox/23.
> > 0a2/auroranotes/index.html?revision=116266&view=markup
> > 
> 
> Chris, can you or someone from your team update that content (for the aurora
> 23 notes).  I don't think I have access to change it.

I can make this update. We have our own hosted copy of the Open Sans font and don't need to load it from Google at all, so I'll just remove that external reference.

Comment 10

[Craig Cook (:craigcook)]

After a quick search there are a LOT of individual files loading Open Sans from Google over http, mainly the release notes going way back. Should we update them all (about 130 pages) or are we only concerned with the latest? Do old release notes pages get enough traffic to worry about them?

Also note the pages render just fine even when that font is blocked because Open Sans is loaded with Tabzilla, but they'll still get a mixed content warning.

Comment 11

[Kohei Yoshino]

Here's a conversion list based on a research in the SVN repo (PHP site):

<img src> <source src> <script src> <iframe src>

* http://www.mozilla.org/ -> /
* http://videos.mozilla.org/,
  http://videos-cdn.mozilla.net/ -> //videos-cdn.mozilla.net/

* http://maps.google.com/ -> //maps.google.com/
* http://api.recaptcha.net/ -> //www.google.com/recaptcha/api/
* http://s3.amazonaws.com/ -> //s3.amazonaws.com/
* http://i.creativecommons.org/ -> //i.creativecommons.org/
* http://w.sharethis.com/ -> //ws.sharethis.com/
* http://www.surveygizmo.com/ -> //www.surveygizmo.com/
* http://app.sgizmo.com/ -> //app.sgizmo.com/

<link href>

* http://fonts.googleapis.com/ -> //fonts.googleapis.com/

<a href>

* http://www.mozilla.org/, https://www.mozilla.org/,
  http://www.mozilla.com/, https://www.mozilla.com/,
  http://europe.mozilla.org/, http://www.mozillamessaging.com/ -> /
* http://support.mozilla.com/, http://support.mozilla.org/,
  https://support.mozilla.com/, https://support.mozilla.org/,
  http://www.support.mozilla.com/, http://www.support.mozilla.org/,
  http://mobile.support.mozilla.com/,
  http://mobile.support.mozilla.org/ -> //support.mozilla.org/
* http://blog.mozilla.com/, http://blog.mozilla.org/, 
  https://blog.mozilla.com/, https://blog.mozilla.org/ -> //blog.mozilla.org/
* http://hacks.mozilla.org/ -> //hacks.mozilla.org/
* http://ftp.mozilla.org/ -> //ftp.mozilla.org/
* http://people.mozilla.com/ -> //people.mozilla.com/
* http://addons.mozilla.org/ -> https://addons.mozilla.org/ (SSL only)
* http://developer.mozilla.org/ -> https://developer.mozilla.org/ (SSL only)
* http://bugzilla.mozilla.org/ -> https://bugzilla.mozilla.org/ (SSL only)
* http://wiki.mozilla.org/ -> https://wiki.mozilla.org/ (SSL only)
* http://crash-stats.mozilla.com/ -> https://crash-stats.mozilla.com/ (SSL only)
* http://input.mozilla.com/, http://feedback.mozilla.org/,
  http://hendrix.mozilla.org/ -> https://input.mozilla.org/ (SSL only)

* http://www.google.com/ -> //www.google.com/
* http://code.google.com/ -> //code.google.com/
* http://www.linkedin.com/ -> //www.linkedin.com/
* http://docs.google.com/ -> https://docs.google.com/ (SSL only)
* http://groups.google.com/ -> https://groups.google.com/ (SSL only)
* http://www.facebook.com/,
  http://facebook.com/ -> https://www.facebook.com/ (SSL only)
* http://twitter.com/ -> https://twitter.com/ (SSL only)

# http://static.mozilla.com/ (non-SSL only, don't change)
# http://releases.mozilla.org/ (non-SSL only, don't change)

Note: There are links and iframes referring getpersonas.com.
      They also should be fixed.
      e.g. http://www.mozilla.org/en-US/firefox/3.6/firstrun/eu/

Comment 12

[Kohei Yoshino]

Bedrock pull request: https://github.com/mozilla/bedrock/pull/902

Comment 13

[Kohei Yoshino]

Attachment: Part 1: iframe, img, script, source, video src + link href

A patch for the traditional PHP site in the SVN repo.

Comment 14

[Craig Cook (:craigcook)]

(In reply to Kohei Yoshino from comment #13)
> Created attachment 752792 [details] [diff] [review]
> Part 1: iframe, img, script, source, video src + link href
> 
> A patch for the traditional PHP site in the SVN repo.

Applied patch to trunk in r116289

Comment 15

[Kohei Yoshino]

Attachment: Part 2: links

Comment 16

[Kohei Yoshino]

No more mixed content warning on the staging site:
https://www-dev.allizom.org/en-US/firefox/23.0a2/auroranotes/

Comment 18

[Craig Cook (:craigcook)]

(In reply to Kohei Yoshino from comment #15)
> Created attachment 753132 [details] [diff] [review]
> Part 2: links

Applied in r116307, should be testable on dev in a few minutes.

Comment 19

[Kohei Yoshino]

Attachment: Part 2.1: .htaccess fix

I have tested some pages and confirmed there were no mixed content warnings.

https://www-dev.allizom.org/en-US/firefox/uninstall/
https://www-dev.allizom.org/en-US/legal/fraud-report/
https://www-dev.allizom.org/en-US/firefox/video/
https://www-dev.allizom.org/en-US/firefox/20.0/releasenotes/
https://www-dev.allizom.org/fr/foundation/annualreport/2010/

But I found redirect issues. Here's a revised patch for .htaccess. Hope this works as expected.

Comment 20

[raymond [:retornam] (inactive)]

(In reply to Kohei Yoshino from comment #19)
> Created attachment 754116 [details] [diff] [review]
> Part 2.1: .htaccess fix
> 
> I have tested some pages and confirmed there were no mixed content warnings.
> 
> https://www-dev.allizom.org/en-US/firefox/uninstall/
> https://www-dev.allizom.org/en-US/legal/fraud-report/
> https://www-dev.allizom.org/en-US/firefox/video/
> https://www-dev.allizom.org/en-US/firefox/20.0/releasenotes/
> https://www-dev.allizom.org/fr/foundation/annualreport/2010/
> 
> But I found redirect issues. Here's a revised patch for .htaccess. Hope this
> works as expected.


Kohei, I think new .htaccess changes are made in https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf

Comment 21

[Kohei Yoshino]

(In reply to raymond [:retornam] from comment #20)
> Kohei, I think new .htaccess changes are made in
> https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf

Umm, but I cannot see redirects to blog or careers in that file.
And .htaccess in the PHP side is still maintained:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?limit_changes=0&view=log

Comment 23

[Kohei Yoshino]

Craig: could you apply my patch in Comment 19 to trunk? This will resolve Bug 876961. I know the following part is a bit hacky, but the SetEnvIf directive doesn't work to detect HTTPS. Or we can use https for all links...

> # Set the PROTOCOL variable (Bug 798611)
> RewriteRule .* - [E=PROTOCOL:http]
> RewriteCond %{HTTPS} on
> RewriteRule .* - [E=PROTOCOL:https]

Comment 24

[Paul [:pmac] McLanahan]

Comment on attachment 754116 [details] [diff] [review]
Part 2.1: .htaccess fix

Review of attachment 754116 [details] [diff] [review]:
-----------------------------------------------------------------

We should just always redirect to HTTPS when possible to avoid all these machinations as well as increase security for users when possible.

Comment 25

[Kohei Yoshino]

In my previous patch, normal links are HTTP if the page is loaded via HTTP. Is it OK? The HTTPS policy is only for redirects?

Comment 26

[Kohei Yoshino]

I cannot understand why protocol relative redirects are not allowed. I have learned that it complicates .htaccess but still makes sense if protocol relative links are allowed.

Comment 27

[Paul [:pmac] McLanahan]

There is no reason to only redirect to https if the user is already on https. The user gets a benefit from https regardless of the current page, and our .htaccess file is simpler because we can just hard-code https in the links. This is the direction all mozilla properties should be moving, and all of the broken redirects have valid certs and no mixed content warnings. Just make them all HTTPS. Similar work has happened in bug 813692, so I believe all of these broken redirects should be fixed on dev now. We just need to roll all of this out at the same time.

Comment 28

[Paul [:pmac] McLanahan]

(In reply to Kohei Yoshino from comment #26)

"not allowed" is a bit to strong. We could do it, but it's just pointless. HTTPS is better and we should use it when possible. It's possible in all these cases, so we should use it. That's my only point.

Comment 29

[Kohei Yoshino]

I totally agree with "HTTPS is better and we should use it when possible" but my question is why redirects are absolute while but links are relative. It lacks consistency.

Comment 30

[Paul [:pmac] McLanahan]

(In reply to Kohei Yoshino from comment #29)

I agree. I'd like external links to be absolute as well. The only URLs that should be protocol relative are those for loading resources in the page (e.g. scripts, images, and css).

Comment 31

[Kohei Yoshino]

Then I'll update my patch in comment 15 and pull request for Bedrock. Thanks for the clarification.

Comment 32

[Paul [:pmac] McLanahan]

(In reply to Kohei Yoshino from comment #31)

Thanks Kohei. I don't mean to seem unappreciative of the work you've done. I hope it hasn't come across that way. I very much appreciate the help. Thanks for getting all of these redirect and mixed-content bugs going.

Comment 33

[Kohei Yoshino]

Attachment: Use HTTPS for links when possible

Comment 34

[Kohei Yoshino]

I must have gained consensus within the bug before making patches. Sorry for the confusion...

Comment 35

[Kohei Yoshino]

(In reply to Chris More [:cmore] from comment #7)
> Lukas: Where do you get the source for these notes each release? Do you copy
> the previous files and make changes? Can you the the reference to the font
> in the head to https now and going forward?

Looks like the templates of the release notes are located at
https://github.com/mozilla/relnotes/tree/master/templates

I sent pull request to remove hard http links:
https://github.com/mozilla/relnotes/pull/1

Comment 36

[Reed Loden [:reed]]

https://www.mozilla.org/en-US/about/contact.html has mixed-content from remote JS

Comment 37

[Kohei Yoshino]

(In reply to Reed Loden [:reed] from comment #36)
> https://www.mozilla.org/en-US/about/contact.html has mixed-content from
> remote JS

It has been fixed on trunk at r116289.
https://www-dev.allizom.org/en-US/about/contact.html

Comment 38

[Adam Muntner [:adamm] (use NEEDINFO)]

 Your comment was:

    I'm tracking the blockers for mixed content bug 843977 for the web security team. I'm happy to see all the progress on this bug, it's a big one. 

    A couple questions so i can better understand and track the current status of this bug:

    1. What if anything is left after the discussed patches are applied? 

    2. When will the changes happen on the public web?

Comment 39

[Kohei Yoshino]

I just updated, tested and re-sent my pull request for Bedrock:
https://github.com/mozilla/bedrock/pull/966

Comment 40

[Kohei Yoshino]

(In reply to Kohei Yoshino [:kohei] from comment #35)
> (In reply to Chris More [:cmore] from comment #7)
> > Lukas: Where do you get the source for these notes each release? Do you copy
> > the previous files and make changes? Can you the the reference to the font
> > in the head to https now and going forward?
> 
> Looks like the templates of the release notes are located at
> https://github.com/mozilla/relnotes/tree/master/templates
> 
> I sent pull request to remove hard http links:
> https://github.com/mozilla/relnotes/pull/1

This PR has been merged to master.

Comment 41

[Tanvi Vyas[:tanvi]]

Do you have a timeline for when this will be resolved?  Thanks!

Comment 42

[Chris More [:cmore]]

(In reply to Kohei Yoshino [:kohei] from comment #40)
> (In reply to Kohei Yoshino [:kohei] from comment #35)
> > (In reply to Chris More [:cmore] from comment #7)
> > > Lukas: Where do you get the source for these notes each release? Do you copy
> > > the previous files and make changes? Can you the the reference to the font
> > > in the head to https now and going forward?
> > 
> > Looks like the templates of the release notes are located at
> > https://github.com/mozilla/relnotes/tree/master/templates
> > 
> > I sent pull request to remove hard http links:
> > https://github.com/mozilla/relnotes/pull/1
> 
> This PR has been merged to master.

Has this PR been pushed? Can we test on -dev?

Comment 43

[Kohei Yoshino]

(In reply to Chris More [:cmore] from comment #42)
> (In reply to Kohei Yoshino [:kohei] from comment #40)
> > (In reply to Kohei Yoshino [:kohei] from comment #35)
> > > (In reply to Chris More [:cmore] from comment #7)
> > > > Lukas: Where do you get the source for these notes each release? Do you copy
> > > > the previous files and make changes? Can you the the reference to the font
> > > > in the head to https now and going forward?
> > > 
> > > Looks like the templates of the release notes are located at
> > > https://github.com/mozilla/relnotes/tree/master/templates
> > > 
> > > I sent pull request to remove hard http links:
> > > https://github.com/mozilla/relnotes/pull/1
> > 
> > This PR has been merged to master.
> 
> Has this PR been pushed? Can we test on -dev?

I guess so. The latest relnotes have no problem:
http://www.mozilla.org/en-US/firefox/22.0/releasenotes/
http://www.mozilla.org/en-US/firefox/23.0beta/releasenotes/

Comment 44

[Tanvi Vyas[:tanvi]]

Is there a way you could just fix the mixed content font on https://www.mozilla.org/en-US/firefox/beta/ sooner than the rest of this? Or is it an all or nothing kind of thing?

Comment 45

[Tanvi Vyas[:tanvi]]

(In reply to Tanvi Vyas [:tanvi] from comment #44)
> Is there a way you could just fix the mixed content font on
> https://www.mozilla.org/en-US/firefox/beta/ sooner than the rest of this? Or
> is it an all or nothing kind of thing?

Nevermind, I think this is part of bug 791681.  I'm having trouble determining the differences in these two bugs.  Sorry!

Comment 46

[Kohei Yoshino]

Can someone review my pull request on GitHub and patches on this bug? Firefox 23 is on the way.

Comment 47

[Adam Muntner [:adamm] (use NEEDINFO)]

FF23 hits stable on Aug 6th. Who can review these changes?

Comment 48

[Chris More [:cmore]]

I've pinged Alex in the PR (https://github.com/mozilla/bedrock/pull/966) to review.

Comment 49

[[github robot]]

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

https://github.com/mozilla/bedrock/commit/9541c25969edebb07641dda174eef3485ca8fc40
Bug 798611

https://github.com/mozilla/bedrock/commit/b94db574ca45858ea17a996c5673c2fc1140b9f6
Merge pull request #966 from kyoshino/bug-798611-mixed-content

Bug 798611 - Remove hard http links on mozilla.org to eliminate mixed content warnings

Comment 50

[Kohei Yoshino]

The Bedrock changes have been pushed production. My PHP patch still needs review and merge.

Comment 51

[Adam Muntner [:adamm] (use NEEDINFO)]

Kohei,

do you know who will be reviewing that?

Comment 52

[Chris More [:cmore]]

(In reply to Adam Muntner :adamm from comment #51)
> Kohei,
> 
> do you know who will be reviewing that?

Tomorrow the mozill.org team has a pull request triage meeting. This is one of a number of high priority pull requests to review.

Comment 53

[Tanvi Vyas[:tanvi]]

Did this get triaged?  Any update here?  6 days to go!

Comment 54

[Ben (:bensternthal)]

Kohei:

Many thanks for your help with this. In the future please have each testable feature in a separate bug with a separate code commit.

This bug has a bunch of php and bedrock commits tracked in it and a bunch of bugs being fixed and we are not sure what the status of each is and what is left to review.

Sancus has volunteered to help push through this review but we are confused as to what exactly needs to be done.

Can you add a comment with the exact items (revisions or commits) that Sancus should review and what each of those fixes? Also feel free to reach out to him on IRC for discussion.

Comment 55

[Kohei Yoshino]

Sorry for the confusion. The current status is:

[Bedrock/Python]

Done, https://github.com/mozilla/bedrock/pull/966 has been merged and pushed to production.

[Legacy PHP site]

attachment 752792 [details] [diff] [review] has been committed to trunk at r116289, which should be reviewed and merged into stage/prod, hopefully this morning. This will accomplish the main goal of this bug to eliminate mixed content.

I'm also confused by the subsequent commit and attached patches... Will revise them later today after 2pm PDT.

Comment 56

[Paul [:pmac] McLanahan]

Pushed to stage in r118715.

Comment 57

[Andrei Hajdukewycz [:sancus]]

So, it seems like r116289 and r116307 are the two patches and they were both committed. There were some issues with the .htaccess in r116307 that pmac fixed in r116718.

So the question is whether the stuff in r116307 is valid minus the .htaccess which would you'd need to supercede with the production one when merging up anyway because there will be a ton of conflicts.

It seems to me that it is, but 1904 changed paths is a lot of changed paths...

Comment 58

[Ben (:bensternthal)]

Kohei adding you back as need info as we are waiting for your feedback.

Comment 59

[Kohei Yoshino]

As Sancus said, there was issues in the .htaccess file. To avoid further confusion and conflict of patches, I'm going to

1. backout r116307 except the .htaccess
2. file a new bug
3. create new divided, revised patches for easier review

This bug is almost done. r118715 needs to be merged into production.

Comment 60

[Chris More [:cmore]]

Should I re-run my script to update the pages in the spreadsheet in comment 3?

Comment 61

[Andrei Hajdukewycz [:sancus]]

r118715 is in production in r118841.

cmore you can re-run your script, yeah, but I think this bug is done. We'll be doing stuff in a new bug for the links.

Comment 62

[Kohei Yoshino]

Thanks! Next, I'll file a new bug for general links, as I noted in my comment 59.

Comment 63

[Kohei Yoshino]

(In reply to Kohei Yoshino [:kohei] from comment #59)
> 1. backout r116307 except the .htaccess

Backed out r116307 at r118844 with conflict resolved.

> 2. file a new bug

Filed Bug 903222.

Comment 64

[Chris More [:cmore]]

I can my scanner and I found these hard coded http embedded objects.

www.mozilla.org/MPL/2.0/index.html 
www.mozilla.org/security/known-vulnerabilities/firefox30.html 
www.mozilla.org/security/known-vulnerabilities/seamonkey11.html 
www.mozilla.org/security/known-vulnerabilities/thunderbird30.html 
www.mozilla.org/security/known-vulnerabilities/thunderbird15.html 
www.mozilla.org/security/known-vulnerabilities/seamonkey10.html 
www.mozilla.org/security/known-vulnerabilities/thunderbird10.html 
www.mozilla.org/security/known-vulnerabilities/firefox15.html 
www.mozilla.org/security/known-vulnerabilities/firefox20.html 
www.mozilla.org/security/known-vulnerabilities/seamonkey20.html 
www.mozilla.org/security/known-vulnerabilities/firefox10.html 
www.mozilla.org/security/known-vulnerabilities/suite17.html 
www.mozilla.org/security/known-vulnerabilities/thunderbird20.html 
www.mozilla.org/security/known-vulnerabilities/firefox35.html

All of the known-vulnerabilities references are to a image:

<img class="logo" width="60" height="60" alt="Mozilla Suite logo"
  src="http://www.mozilla.org/images/product-firefox.png">

The MPL one is to an IE6-8 hack:

<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

Comment 65

[sjw]

(In reply to Chris More [:cmore] from comment #64)
> 
> The MPL one is to an IE6-8 hack:
> 
> <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

There are some fonts too (L 11-13):

  <link href='http://fonts.googleapis.com/css?family=Crimson+Text' rel='stylesheet' type='text/css'>
  <link href='http://fonts.googleapis.com/css?family=Lora' rel='stylesheet' type='text/css'>
  <link href='http://fonts.googleapis.com/css?family=Droid+Sans+Mono' rel='stylesheet' type='text/css'>

Comment 66

[sjw]

Do not forgot the following links:

http://careers.mozilla.org -> https://careers.mozilla.org
http://www.adobe.com/go/getflashplayer -> https://www.adobe.com/go/getflashplayer
http://support.mozillamessaging.com -> https://support.mozillamessaging.com
http://join.mozilla.org -> https://join.mozilla.org
http://sendto.mozilla.org -> https://sendto.mozilla.org
http://fonts.googleapis.com -> https://fonts.googleapis.com
...


It seems to me that this bug isn't fixed everywhere, because on some sites there are still a lot of hard coded http links which should be already fixed (like http://www.mozilla.org):

https://www.mozilla.org/en-US/products/
https://www.mozilla.org/en-US/thunderbird/
https://developer.mozilla.org/en-US/
...


And there is a google analytics script which check if the connection is https:

    var prefix = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www');
    ga.src = prefix + '.google-analytics.com/ga.js';

I think we can made this to use force https.

Comment 67

[Chris More [:cmore]]

(In reply to sjw from comment #66)
> Do not forgot the following links:
> 
> http://careers.mozilla.org -> https://careers.mozilla.org
> http://www.adobe.com/go/getflashplayer ->
> https://www.adobe.com/go/getflashplayer
> http://support.mozillamessaging.com -> https://support.mozillamessaging.com
> http://join.mozilla.org -> https://join.mozilla.org
> http://sendto.mozilla.org -> https://sendto.mozilla.org
> http://fonts.googleapis.com -> https://fonts.googleapis.com
> ...
> 
> 
> It seems to me that this bug isn't fixed everywhere, because on some sites
> there are still a lot of hard coded http links which should be already fixed
> (like http://www.mozilla.org):
> 
> https://www.mozilla.org/en-US/products/
> https://www.mozilla.org/en-US/thunderbird/
> https://developer.mozilla.org/en-US/
> ...
> 
> 
> And there is a google analytics script which check if the connection is
> https:
> 
>     var prefix = ('https:' == document.location.protocol ? 'https://ssl' :
> 'http://www');
>     ga.src = prefix + '.google-analytics.com/ga.js';
> 
> I think we can made this to use force https.

I am only checking for embedded content that is http on an https page. Links to http websites is not really the embedded mixed content issue I was scanning for.

Comment 68

[Kohei Yoshino]

We can take care of the rest of the http links in Bug 903222.

Comment 69

[Tanvi Vyas[:tanvi]]

(In reply to sjw from comment #65)
> (In reply to Chris More [:cmore] from comment #64)
> > 
> > The MPL one is to an IE6-8 hack:
> > 
> > <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
> 
> There are some fonts too (L 11-13):
> 
>   <link href='http://fonts.googleapis.com/css?family=Crimson+Text'
> rel='stylesheet' type='text/css'>
>   <link href='http://fonts.googleapis.com/css?family=Lora' rel='stylesheet'
> type='text/css'>
>   <link href='http://fonts.googleapis.com/css?family=Droid+Sans+Mono'
> rel='stylesheet' type='text/css'>

These two are actual embeds of mixed active content. The mixed content blocker is invoked here: https://www.mozilla.org/MPL/2.0/index.html.