Third-party HTTP images on HTTPS site don't get upgraded to HTTPS

[dentistformyeye]

Description

Third-party HTTP images embedded on an HTTPS site don't get upgraded, even though mixed content should be upgraded automatically.

Steps to Reproduce

1. Check brave://settings/content/insecureContent and verify that insecure content should be blocked.
   

2. Visit the website https://www.eff.org/awards/pioneer/2008

3. Observe and click the location where a padlock should be in the omnibox.

4. Hover the mouse cursor over an HTTP image displayed on the site and observe the lower left corner of the browser window. Click the image with shields off to confirm that visiting the image directly will happen through HTTPS.

5. Click back to the first website. Turn shields back on. Click the Brave icon in the omnibox and click "Connections upgraded to HTTPS".

Actual result:

Instead of a padlock, the browser displays a warning symbol and indicates that the page has HTTP images.

The images are linked as HTTP, but clicking one with shields down shows that they can be directly accessed using HTTPS.

Brave still thinks the images have been upgraded to HTTPS.

Expected result:

The images are loaded through HTTPS. The omnibox displays the padlock. Clicking the padlock brings up the "Connection is secure" message.

Reproduces how often:

Easily reproduced

Brave version (brave://version info)

Brave	1.17.73 Chromium: 87.0.4280.67 (Official Build) (x86_64)
Revision	0e5d92df40086cf0050c00f87b11da1b14580930-refs/branch-heads/4280@{#1441}
OS	macOS Version 10.15.7 (Build 19H2)

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes
• Can you reproduce this issue with the beta channel? Haven't tried
• Can you reproduce this issue with the nightly channel? Haven't tried

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? No
• Does the issue resolve itself when disabling Brave Rewards? Already disabled
• Is the issue reproducible on the latest version of Chrome? Haven't tried

Miscellaneous Information:

I first encountered this on Brave version 1.15.76.

[ryanbr]

Nothing specific for eff.org in the https everywhere rules, going by the folder "2008" I suspect its quite old and hasn't been upgraded. The reason why it's not showing as secure is due to the use of http:// url's still in use on this specific page.

http://w2.eff.org/awards/pioneer/images/2008/pioneer08.gif
http://w2.eff.org/awards/pioneer/images/2008/tcho.gif
http://w2.eff.org/awards/pioneer/images/2008/mog.png
http://w2.eff.org/awards/pioneer/images/2008/threerings.png
http://w2.eff.org/awards/pioneer/images/2008/jibjab.png
http://eff.org/files/barracuda_logo.png
http://eff.org/files/atomic.logo_.jpg

I'll investigate with EFF, see if they're aware of it.

[dentistformyeye]

My bad, I'd assumed that eff.org would be in the HTTPS Everywhere rules, but I should have checked. I've filed EFForg/https-everywhere#19798.

Since Brave accesses eff.org through HTTPS even with HTTPS Everywhere (both the Brave component and the extension) disabled, I'd expected mixed content to be automatically upgraded. Is this a Chromium issue, then?

[diracdeltas]

cc @fmarier on the mixed content upgrade issue

[bsclifton]

I think this is a duplicate of #10190

[dentistformyeye]

My bad, this does seem to be a duplicate.