Intent to Ship: Insecure Download Blocking in Secure Contexts

[Joe DeBlasio]

Contact emails

jdeb...@chromium.org, est...@chromium.org

Explainer

Please see the explainer for Chrome’s future goals for mixed content. This intent covers only the restrictions on mixed downloads. The explainer also covers other mixed content more broadly, which are/will be covered by other Intents.

See also the design doc, and our public announcement for rationale.

Spec (N/A)

Design doc. No TAG review required.  We believe that this change constitutes a user-agent intervention as covered by "When a user agent is to handle a resource obtained from a fetch as a download, act in a user-agent-defined manner to safeguard the user from a potentially hostile download" from Section 4.6.5 of the HTML Standard. We also don't believe that this change constitutes "web exposed" and has little chance of interacting with the rest of the platform in unexpected ways.

Summary

Chrome will block insecurely-delivered downloads initiated from secure contexts. This blocking will gradually roll out to give developers time to adapt, focusing initially on high-risk file types like executables and ‘opaque’ files like disk images and compressed files.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/mALJa0JM13I/-jxMlOyrBAAJ

Demo

To try out blocking, enable chrome://flags/#treat-unsafe-downloads-as-active-content on Chrome Canary, then try downloading from the "Mixed" section of https://chromium.projekts.xyz/mix-dl/ .

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will gradually roll out to all blink platforms, with Android and WebView lagging slightly behind other platforms. Android has existing robust mechanisms for preventing malicious file execution.

Debuggability

This feature does not have explicit DevTools support, but blockable downloads will print a console message similar to that used by other mixed content blocking. See the design doc (or Chrome Canary) for details. During the phase-out, blocking will also generate a user-visible warning.

Risks

Interoperability and Compatibility

Edge: One cool Security PM said the plan was "exciting" on Twitter.

Firefox: Some public support

Safari: No signals

Web / Framework developers: Mixed. See discussion.

If blocked immediately, 3.4% of downloads would be impacted. This is approximately 0.06% of navigations. However, sites have a readily-available upgrade path to avoid impact. Our hope is that the gradual roll-out, with a preceding warning phase, will encourage developers to migrate to secure alternatives.

We believe that this change is an important security and privacy intervention justifying this impact. Insecure downloads give attackers opportunities to swap downloaded files for malware, or observe sensitive data such as bank statements or court documents. For insecurely-delivered downloads initiated from insecure contexts (not covered by this Intent), Chrome provides some warning that the user's visit is "not secure". However, in the "mixed" downloads case, Chrome cannot give even that limited warning to users about the privacy and security risks.

In a manual inspection of the top affected sites, most are actively maintained, serving first-party downloads. We believe that these sites will be able to prevent breakage by fully migrating to HTTPS.

Ergonomics

This feature should not interact with any other API, nor impact performance.

Activation

This blocking will occur automatically, and require no action from web developers. However, impacted web developers will need to migrate to secure downloads to avoid blocking.

When a download is blocked, it will print a message to the console explaining the reason for blocking and how to remediate it.

Is this feature fully tested by web-platform-tests? N/A

Link to entry on the feature dashboard.

[Yoav Weiss]

LGTM1

Overall the phased approach seems reasonable and the high compat risk is countered by the extremely high risk of clear-text binary downloads. The user's ability to opt-in (and to take on risk) in the initial phases can also help to calm the compatibility concerns.

A few questions below.

3.4% is a *lot*. Looking at the attached doc, I understand that the initial phase will be comprised just of executables, which are 0.77% of downloads. Is that correct?

Do we have a sense of how many sites are responsible for this number? Can UKM allow us to reach out to them?

How does the browser know that a certain download is an executable? Does it have to download some parts of the response in order to make that assessment?

If so, do we have reason to believe site operators will notice the decrease in actual downloads that we expect the user-facing warning to produce?

Might be worthwhile to break all mixed content downloads for some %age of users before anything is downloaded to get operators to dig into the decrease in conversion stats and find our user-facing and console warnings.

We believe that this change is an important security and privacy intervention justifying this impact. Insecure downloads give attackers opportunities to swap downloaded files for malware, or observe sensitive data such as bank statements or court documents. For insecurely-delivered downloads initiated from insecure contexts (not covered by this Intent), Chrome provides some warning that the user's visit is "not secure". However, in the "mixed" downloads case, Chrome cannot give even that limited warning to users about the privacy and security risks.

In a manual inspection of the top affected sites, most are actively maintained, serving first-party downloads. We believe that these sites will be able to prevent breakage by fully migrating to HTTPS.

Ergonomics

This feature should not interact with any other API, nor impact performance.

Activation

This blocking will occur automatically, and require no action from web developers. However, impacted web developers will need to migrate to secure downloads to avoid blocking.

When a download is blocked, it will print a message to the console explaining the reason for blocking and how to remediate it.

Is this feature fully tested by web-platform-tests? N/A

Link to entry on the feature dashboard.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFZs0S4cGzEsL8v6di8FB5gvpG7Z6MzDidzEx7hOA9CZd-jSKQ%40mail.gmail.com.

[Jochen Eisinger]

lgtm2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiyXNwJwfAAAtFdFTMOBs%3D-YLUrdzRufZigNbaR3UFrQw%40mail.gmail.com.

[Joe DeBlasio]

Thanks Yoav. Responses inline:

3.4% is a *lot*. Looking at the attached doc, I understand that the initial phase will be comprised just of executables, which are 0.77% of downloads. Is that correct?

Yes, and the vast majority are .exe's.

 

Do we have a sense of how many sites are responsible for this number? Can UKM allow us to reach out to them?

 

We did some investigation early on and found that the top sites weren't great outreach targets. I'm planning on working a bit more down the rankings to see if there are still important folks to reach out to.

How does the browser know that a certain download is an executable? Does it have to download some parts of the response in order to make that assessment?

For this, we're just relying on file extension. Sites can work around this easily, but doing so will only buy them a few releases. Chrome does support mime-sniffing, but it isn't comprehensive across all the file types we needed.

When blocking, Chrome still needs to make every request -- the browser usually doesn't know a download is about to occur until it receives the Content-Disposition header on a response. It doesn't need any of the response except for the headers.

 

If so, do we have reason to believe site operators will notice the decrease in actual downloads that we expect the user-facing warning to produce?

This is a good question, and our hope is that site operators will notice complaints from users or will test the sites themselves.

We are also exploring the possibility of sending an Intervention report via the Reporting API.

 

Might be worthwhile to break all mixed content downloads for some %age of users before anything is downloaded to get operators to dig into the decrease in conversion stats and find our user-facing and console warnings.

This sounds like a good idea, but I don't know what percentage would be needed. I'll explore this more and any tips are welcome.

 

Thanks!

Joe

[Mike West]

LGTM3.

-mike

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFZs0S7%3D%2BrWD7S7xgfNMmqZJuAJqTXAx2rs6nK1x_FeH5vy%3DNQ%40mail.gmail.com.