Intent to Implement: High-risk insecure download blocking in secure contexts

[Joe DeBlasio]

Contact emails

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

Explainer

Please see the explainer (with relevant PR) for Chrome’s future goals for mixed content.

Design doc/Spec

Design doc

This change does not require a TAG review, as it is covered by the HTML standard in section 4.6.5.

Summary

Chrome intends to block insecurely-delivered downloads initiated from secure contexts if the download is for a high-risk file type. These high-risk file types are to be initially limited to desktop executables for the best trade-off of user protection and compatibility.

Motivation

Downloads over insecure contexts present a risk to users, and arguably the greatest risk comes from executables downloaded from secure contexts. Once downloaded, a malicious executable can circumvent any protections Chrome puts in place. Further, Chrome does not and can not warn users by downgrading security indicators on secure pages that initiate insecure downloads, as it does not reliably know whether an action will initiate an insecure download until the request is made.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Some public support

Safari: No signals

Web / Framework developers: Mixed. See discussion.

While we do not yet have precise metrics for impact of this limited blocking, our best estimate is that blocking would prevent less than 0.01% of downloads, and less than 0.00001% of navigations.

These numbers are based on Chrome’s presently limited ability to record initiating origin at download time. Chrome is limited to tracking initiating origin only when the download is initiated in the same tab as the previous page. Context is lost if the download occurs in a new tab (e.g. shift- or ctrl-click). Context may also be lost in additional scenarios that we have not yet determined.

We don't have any reason to believe that the loss of download initiator is biased towards or away from secure contexts, so we think the above is a reasonable estimate of the impact. We are implementing more precise metrics in M76. Insecure high-risk downloads (regardless of requester) account for approximately 0.1% (Windows) or 0.2% (Mac) of downloads, or about 0.001% of all Desktop navigations. This can act as a very conservative upper-bound since we will only be blocking the portion of these downloads that initiate from secure contexts.  

Ergonomics

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

Activation

This blocking will eventually occur automatically, and require no action from web developers.

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

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

Initially, this feature will be limited to desktop platforms as Android and iOS have robust mechanisms for preventing malicious file execution.

See the entry on the feature dashboard.

Requesting approval to ship?

No.

[Yoav Weiss]

On Wed, May 8, 2019 at 9:16 PM Joe DeBlasio <jdeb...@chromium.org> wrote:

Contact emails

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

Explainer

Please see the explainer (with relevant PR) for Chrome’s future goals for mixed content.

Design doc/Spec

Design doc

This change does not require a TAG review, as it is covered by the HTML standard in section 4.6.5.

I agree this doesn't require a TAG review, but not for that reason :)

This change seems like a user-agent intervention to protect users from potentially malicious downloads. It doesn't not seem particularly "web exposed" (e.g. there's no way for developers to know that a download was or wasn't successful, is there?), and therefore have little probability of interacting with the rest of the platform in unexpected ways.

 

Summary

Chrome intends to block insecurely-delivered downloads initiated from secure contexts if the download is for a high-risk file type. These high-risk file types are to be initially limited to desktop executables for the best trade-off of user protection and compatibility.

Motivation

Downloads over insecure contexts present a risk to users, and arguably the greatest risk comes from executables downloaded from secure contexts. Once downloaded, a malicious executable can circumvent any protections Chrome puts in place. Further, Chrome does not and can not warn users by downgrading security indicators on secure pages that initiate insecure downloads, as it does not reliably know whether an action will initiate an insecure download until the request is made.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Some public support

Safari: No signals

Web / Framework developers: Mixed. See discussion.

While we do not yet have precise metrics for impact of this limited blocking, our best estimate is that blocking would prevent less than 0.01% of downloads, and less than 0.00001% of navigations.

These numbers are based on Chrome’s presently limited ability to record initiating origin at download time. Chrome is limited to tracking initiating origin only when the download is initiated in the same tab as the previous page. Context is lost if the download occurs in a new tab (e.g. shift- or ctrl-click). Context may also be lost in additional scenarios that we have not yet determined.

We don't have any reason to believe that the loss of download initiator is biased towards or away from secure contexts, so we think the above is a reasonable estimate of the impact. We are implementing more precise metrics in M76. Insecure high-risk downloads (regardless of requester) account for approximately 0.1% (Windows) or 0.2% (Mac) of downloads, or about 0.001% of all Desktop navigations. This can act as a very conservative upper-bound since we will only be blocking the portion of these downloads that initiate from secure contexts.  

Ergonomics

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

Activation

This blocking will eventually occur automatically, and require no action from web developers.

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

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

Initially, this feature will be limited to desktop platforms as Android and iOS have robust mechanisms for preventing malicious file execution.

See the entry on the feature dashboard.

Requesting approval to ship?

No.

--
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/CAFZs0S6yf35Bgr_%3DjJBX7tgYEZjkvaXR9f_GAJ16vRVgLvcmwg%40mail.gmail.com.

[PhistucK]

Suggestion - what about automatically upgrading to HTTPS instead of blocking it, like you plan to do with videos and audio (also, why not with images, too?)?

☆PhistucK

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

[Joe DeBlasio]

In the passive mixed content case, Chrome can opportunistically upgrade as the requests are made.  That means that if the auto-upgrading works, Chrome's interventions are enough to keep users safe.

In the download case, things are slightly more complicated. Chrome doesn't know ahead of time that a request is a download. Since we don't want to preclude linking to insecure pages, Chrome has to let all insecure loads (including redirects) proceed, and if it turns out to be a download, take action.

We could have made Chrome block the download and retry the request chain, upgrading any insecure requests along the way. That approach could work as part of a gradual rollout of blocking, but it can't be a long-term solution: it still emits insecure requests. Those insecure requests would leak state about what the user is trying to do, even if Chrome blocked the actual download, and the request could also be turned into a non-download navigation by an active attacker. Only devs can fix it.

I also had concerns about implementation complexity, breakage from the side effects of doing every request twice, and latency. All of this summed up to the strategy we announced in the blogpost.

Good question (and impressive historical thread recall)!

Joe

[PhistucK]

That makes sense, I should have thought about the navigation-might-turn-into-download case after the recent thead Matt started. :(

☆PhistucK

[Joe DeBlasio]

Also, for those reading this thread now: this Intent was abandoned in favor of the more aggressive blocking plan announced here: https://blog.chromium.org/2020/02/protecting-users-from-insecure.html