I also tried the PoC on Firefox 52 and Edge 15. Firefox has exactly the same behavior as Chrome (i.e. insecure images are loaded but not displayed), and in Edge 15, insecure images are loaded and displayed.

So I wonder if this is by design. But if you confirm this is a bug, I will report it to Mozilla and Microsoft as well.

I just realized my Chrome was outdated. After updating, it is still reproducible on Chrome 58.0.3029.81 stable.

estark or mkwst: Can you please take a look? 

I wonder if the preload scanner is doing the wrong thing here. Yoav, can you take a look to determine whether we're setting the request context correctly? If so, assign it back to me, please. :)

The behavior here is certainly against spec, but the severity is pretty low: we allow would allow the same request through `<img>`.

Currently OOO (on vacation). I can take a look at this in a couple of weeks, or if by odd chance one of the evenings here is sangria-free. How urgent is this issue?

As noted in #4, this is not very exciting from a security POV because it reflects a web developer mistake that is more easily made with a plain img.

Live demo: https://bayden.com/test/MixedContent/picture.html. 

Re #4: I think you're right; the context isn't set correctly. By the time we get to preloadrequest.cpp's PreloadRequest::Start, we have an Resource Type of kImage, an initiator_info.name of "img", a URL of "http://www.opera.com/favicon.ico", and critically, we've SetRequestContext with kRequestContextImage. So the WebMixedContent::ContextTypeFromRequestContext function that determines blockability picks kOptionallyBlockable instead of kBlockable.

Prior to that: HandlePictureSourceURL sets picture_data.source_url to "http://www.opera.com/favicon.ico" on its first path, then calls SetUrlToLoad to the same URL the second time it's called. In CreatePreloadRequest, InitiatorFor(tag_impl_) passed into PreloadRequest::CreateIfNeeded is "img". HTMLPreloadScanner.cpp doesn't seem to propagate the in_picture_ flag out to anywhere that the rest of the system would see it. Our <source SrcSet=> request flows through the rest of the preload system as an "img" request. 

Other interesting findings: 

- In the repro case, Chrome also shows the "This page is trying to load scripts from unauthenticated sources" which I assume is just bad UI text we use for all the "Blockable Content" mixed content warnings?

- We don't attempt to block <img crossorigin /> at all (even post-network) either (nor does any other browser, in apparent violation of the mixed content spec).

I can confirm that with the correct kRequestContextImageSet request context, the preload request is properly blocked by MixedContentChecker::ShouldBlockFetch in FrameFetchContext::CanRequestInternal.

Assigning that correct context inside PreloadRequest::Start is non-trivial; ResourceFetcher::DetermineRequestContext uses only the inbound resource_type and DetermineRequestContext doesn't support returning WebURLRequest::kRequestContextImageSet. Beyond that, there's blink::Resource::Type doesn't include an ImageSet type either).

Introducing and bubbling a new resource_type through the whole of the system seems quite complicated, so maybe it makes the most sense to have an new preassignedContext member on PreloadRequest that it prefers, falling back to DetermineRequestContext if not set?

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tentative fix at https://codereview.chromium.org/2855163002/

Also, is that actually a security issue? The resources in question are just being downloaded, not used in any way

Re #15: I think it is a security issue. Even if the images are not used, their content may be leaked to MITM, which may be a privacy issue. The key difference between this and <img> is that web developers may rely on browsers' mixed content blocker to block HTTP images in <picture>. But Chrome doesn't block them correctly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/babb7e6d7db134dab30bfa1419fc0b45744a2645

commit babb7e6d7db134dab30bfa1419fc0b45744a2645
Author: yoav <yoav@yoav.ws>
Date: Thu May 04 12:09:58 2017

Avoid sending mixed-content requests for ImageSet contexts

ImageSet context resources, namely <picture> and srcset based images,
are blockable mixed-content, yet we were sending out such requests, even
if not displaying them, due to the preloadScanner ignoring the difference
between them and `<img src>` based images

This CL fixes that, by blocking such images.

BUG= 713440 

Review-Url: https://codereview.chromium.org/2855163002
Cr-Commit-Position: refs/heads/master@{#469314}

[add] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/LayoutTests/external/wpt/mixed-content/imageset.https.sub.html
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/CSSPreloadScanner.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/HTMLResourcePreloaderTest.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/PreloadRequest.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/html/parser/PreloadRequest.h
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/loader/LinkLoader.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/core/loader/resource/LinkFetchResource.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/babb7e6d7db134dab30bfa1419fc0b45744a2645/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.h

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot