> extensions run with higher privileges 
> than normal webpages

Extensions do have higher privileges, but a Web iframe in an extension popup should not. Are you asserting otherwise?

Because extensions are subject to strict CSP requirements, I don't believe they can load an insecure remote script at all (see https://developer.chrome.com/extensions/contentSecurityPolicy#relaxing-remote-script). A quick test tweaking the test case extension verifies that this is the case.

I've confirmed that the insecure iframe does load in the browser action popup (and can run javascript). I'm not sure what the security consequences of this are exactly -- I don't believe the iframe would have any special access, but it might expose the extension to a renderer exploit from a network attacker.

Tentatively setting Severity-Low and impact on all OSes with extensions support.

Re: Renderer exploit, extensions run their IFrames out-of-process for this reason. 

Similar discussions in Issue 451656.

It does indeed appear that the iframe to http://www.example.com is run out-of-process, meaning that there is a much lower risk after all of a modified resource being able to run at a higher privilege than a normal webpage. 

On the other hand, if active mixed content is going to be blocked on HTTPS-main-origin webpages, it really should be blocked in extension popups. I suspect that it isn't blocked in extension popups because HTTP is the main origin for the subframe that's running out-of-process, as active mixed content is only blocked (and, really, is only "mixed") on HTTPS-main-origin pages.

Extension popups should also not be allowed to submit form fields to HTTP.

Ah, I wasn't sure if OOPIF was the case here. Then I'm not sure if there's any remaining security risk (maybe at most a phishing risk via network attackers?).

I would be generally fine with us aligning the default extension CSP to block this (e.g., `frame-src: https://*`?), but I think we'd want to do some measurement first.

That change, however, feels more like a security feature rather than a bug fix. Do we have reason to think this would be abusable in a particular way? cc'ing some relevant folks to weigh in (meacer@ for extensions security, andypaicu@ for CSP and mkwst@ for mixed content).

I've wanted to block mixed content in extension pages for a while, but the usage is an order of magnitude above where we've had successful deprecation/removal in the past: https://www.chromestatus.com/metrics/feature/timeline/popularity/662 (and since that's counting all pageviews, and not just extensions, the percentage of extension pageviews that would be affected is somewhat higher). I wouldn't be at all surprised if this boiled down to a handful of extensions with large numbers of users, but I haven't looked into any of it in detail.

+Devlin, as this is certainly something to look at in v3, and if we could get rid of it in v2, I'd be even happier.

This isn't a security bug, and is more-or-less working-as-intended.  As mentioned, the http frame runs out-of-process from the extension, and does not have any elevated privileges.

I agree with the sentiment here that it would be nice to be stricter about what extensions can include, and tighten the default CSP.  I think that we can probably pursue that in manifest v3.  Likely, it will not be worth the effort to try and deprecate it and migrate existing extensions over.

I don't think there's any security risk here, or reason to keep this restricted.  My proposal would be to rename this to be "Block http content by CSP in extensions" and unrestrict.  Any objections?

Re #8: making public SGTM. 

Adding Security component and removing from the Security bug queue based on consensus around #8 (and updating title to match).