"Insecure download blocked": I didn't ask Chromium/Chrome to block downloads and erroneously list a .deb file as "insecure""

[guest271314]

[guest271314]

I found this flag

--enable-download-warning-improvements ⊗
Enables a number of UI improvements to downloads, download scanning, and download warnings. ↪

here https://peter.sh/experiments/chromium-command-line-switches/.

I didn't ask Chromium/Chrome to for "download scanning" at all. How to turn off download scanning completely?

On Saturday, November 4, 2023 at 10:10:50 AM UTC-7 guest271314 wrote:

[Keith I Myers]

I often see this happen if it was downloaded from a insecure http location, it should be fine if you use https

On Sat, Nov 4, 2023, 10:10 AM guest271314 <guest...@gmail.com> wrote:

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/abe373a0-1cf8-464a-b227-91db91d7f610n%40chromium.org.

[guest271314]

> I often see this happen if it was downloaded from a insecure http location, it should be fine if you use https

That may be the case. The issues are 

- I deliberately turned off Google Safe Browsing, so no download scanning should be happening at all

- a .deb files should not be marked as "insecure"

- Whether the protocol is HTTP:, FILE:, ISOLATED-APP: or other should not impact whether the file is marked as "inscure", or not

- I didn't ask Chromium to scan my download files at all

- No way to turn off Chromium scanning the files I decide to download

[Daniel Cheng]

On Sat, 4 Nov 2023 at 10:34, guest271314 <guest...@gmail.com> wrote:

> I often see this happen if it was downloaded from a insecure http location, it should be fine if you use https

That may be the case. The issues are 

- I deliberately turned off Google Safe Browsing, so no download scanning should be happening at all

Seeing this error is not due to safe browsing.

 

- a .deb files should not be marked as "insecure"

The .deb file is not being labelled insecure; the download itself is labelled an "insecure download" because the download *is* over insecure transport if it's being downloaded over HTTP. There's an option to download anyway (i.e. the "Keep" button).

 

- Whether the protocol is HTTP:, FILE:, ISOLATED-APP: or other should not impact whether the file is marked as "inscure", or not

- I didn't ask Chromium to scan my download files at all

- No way to turn off Chromium scanning the files I decide to download

On Saturday, November 4, 2023 at 10:25:44 AM UTC-7 Keith I Myers wrote:

I often see this happen if it was downloaded from a insecure http location, it should be fine if you use https

On Sat, Nov 4, 2023, 10:10 AM guest271314 <guest...@gmail.com> wrote:

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/abe373a0-1cf8-464a-b227-91db91d7f610n%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/96474e2b-a3b7-403f-b971-3a342a08cbe9n%40chromium.org.

[guest271314]

> The .deb file is not being labelled insecure; the download itself is labelled an "insecure download" because the download *is* over insecure transport if it's being downloaded over HTTP. 

That is not clear at all in the text of the prompt. 

Just because the download occurs on HTTP: protocol does not make the download "insecure".

[guest271314]

Moreover, I didn't ask Chromium to block *any* downloads I decide to commence, under any circumstances.

On Sat, Nov 4, 2023 at 10:58 AM Daniel Cheng <dch...@chromium.org> wrote:

[guest271314]

Let's test this on file: protocol

<a download="test.deb" href="build-essential_11.6ubuntu6_amd64.deb">click</a>

Same erroneous prompt. 

 file: protocol is *not* "insecure" Is "file:" protocol considered a "secure context", if not why? #66. Nobody has claimed or asserted that file: protocol is "insecure".

I'm on my own machine downloading my own file.

[guest271314]

https://github.com/w3c/webappsec-secure-contexts/issues/66

[Mike Frysinger]

HTTP, by definition, is not secure.  hence, downloading over HTTP produces results that have not been secured.  a.k.a. the download is insecure.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BsyWAP_8rUw5j4jbqKD0Afs3zSyKW6DWd7UD5SvBpWnMykbXg%40mail.gmail.com.

[guest271314]

> HTTP, by definition, is not secure.  hence, downloading over HTTP produces results that have not been secured.  a.k.a. the download is insecure.

Well, no signal communications are "secure". 

It was pretty clear that we were building the most powerful analysis tool
that had been developed in history to monitor basically the entire world. 

- Bill Binney, A Good American

file: protocol is secure and the prompt is still displayed.

How to get rid of that prompt?

[guest271314]

Ah, here's the link from "Learn more" in the prompt https://support.google.com/chrome/answer/6261569.

I want to turn that "block" off. 

No thank you, I'll pass.

I can decide for myself which origin and protocols I want to download files from/on.

Google Chrome blocks some downloads

Chrome automatically blocks dangerous downloads and protects your device and accounts from malware or viruses.

On Sat, Nov 4, 2023 at 12:23 PM Mike Frysinger <vap...@chromium.org> wrote:

[guest271314]

Some more information:

https://chromeenterprise.google/policies/?policy=DownloadRestrictions. I don't see a policy option to disable "Safe Browsing verdicts".

Which should not be applicable to me anyway because I deliberately disabled Google Safe Browsing. 

Seems that Google Safe Browsing is still on for Downloads...

> Description:
> 
> Setting the policy means users can't bypass download security decisions.
>
> There are many types of download warnings within Chrome, which roughly break down into these categories (learn more about Safe Browsing verdicts https://support.google.com/chrome/?p=ib_download_blocked):

[K. Moon]

Copying what I meant to post to this thread:

This discussion group is for discussing Chromium development, not for Google product decisions. If you have feedback about Google Chrome, you should report that feedback directly to the product feedback channels for Google Chrome.

Here's how you can report product feedback on Google Chrome:

https://support.google.com/chrome/answer/95315

As a rule of thumb, if the answer to a question could be, "Another Chromium-based browser could choose to do it differently," we're talking about a product question. I think whether HTTP is trusted falls squarely into that category.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c2926e2b-179a-4c5e-80f8-830abde2da21n%40chromium.org.

[guest271314]

There is no "Help" => "Report an issue" on Chrome-For-Testing Version 121.0.6103.0 (Official Build) (64-bit).

I'm not using Chrome browser.

I'm on Chromium, developing. 

I can't get a straight answer as to why Google Safe Browsing appears to be scanning files which I turned that off. 

I'm not asking about whether HTTP is trusted or not. I don't trust anybody. 

I do expect to make my own decisions about what files and/or protocols are blocked, or not. All roads keep leading back to Google Chrome Browsing, which I want no part of, and as a Chromium developer I turned that off. All of that should be turned off. I don't need a Big Brother to protect me from the evil Internet. I know the entirety of signal communications are susceptible to being intercepted, analyzed, stored in third-party data centers at any time - without notice, so you can't really verify if your communications are "secure".

My main point here is when developers turn something off by flag or in the Settings GUI it should be off, not really on when in any circumstances.

[Dave Tapuska]

If you are building your own chromium then just set 

safe_browsing_mode to 0 in your gn flags. (see 

https://source.chromium.org/chromium/chromium/src/+/main:components/safe_browsing/buildflags.gni;l=15?q=Safe_browsing%20gni&ss=chromium)

That way you won't even have the code in your binary instead of modifying the settings. 

Dave

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BsyWANa0St7aYW1bYMXHuAmniuh4NF0-jfhoVzwngUKFhkPhQ%40mail.gmail.com.

[Daniel Cheng]

On Sat, 4 Nov 2023 at 14:33, guest271314 <guest...@gmail.com> wrote:

There is no "Help" => "Report an issue" on Chrome-For-Testing Version 121.0.6103.0 (Official Build) (64-bit).

I'm not using Chrome browser.

I'm on Chromium, developing. 

I can't get a straight answer as to why Google Safe Browsing appears to be scanning files which I turned that off. 

You have been repeatedly told that this does not happen if safe browsing is disabled, and furthermore, if you do see concrete evidence of this happening, that is a bug that would be addressed and fixed. I would be happy to file that bug on your behalf if you have evidence of this happening.

Daniel

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BsyWANa0St7aYW1bYMXHuAmniuh4NF0-jfhoVzwngUKFhkPhQ%40mail.gmail.com.

[guest271314]

> You have been repeatedly told that this does not happen if safe browsing is disabled, and furthermore, if you do see concrete evidence of this happening, that is a bug that would be addressed and fixed. I would be happy to file that bug on your behalf if you have evidence of this happening.

I provided the evidence in this post.

I deliberately turned off Google Safe Browsing. When I do a cursory search, follow links to why the files I download are being blocked, all roads lead back to Google Safe Browsing. I'm not imagining the links I am following. I'm not sure why me following links and showing how Google Safe Browsing keeps getting mentioned in Google documentation is leading me to this conclusion. How could I logically conclude otherwise?

Whether Google Safe Browsing or not, something is blocking download files, and I suspect scanning files written to the local file system when using FileSystemWritableFileStream.

https://bugs.chromium.org/p/chromium/issues/detail?id=1168715#c17

> The problem here is indeed that our security team really wants us to perform safe browsing analysis of written files, before the files are available with their normal file name/extension (it is also for this reason that downloads are written to a temporary file, and only renamed once safe browsing checks pass).

https://support.google.com/chrome/answer/6261569

> You can always choose to download a file after you receive a warning from Chrome, but take download warnings seriously. Attackers may ask you to turn off or ignore warnings to avoid antivirus detections. Learn how Chrome and Safe Browsing keep your browsing data private.

https://chromeenterprise.google/policies/?policy=DownloadRestrictions

Description:

Setting the policy means users can't bypass download security decisions.

There are many types of download warnings within Chrome, which roughly break down into these categories (learn more about Safe Browsing verdicts https://support.google.com/chrome/?p=ib_download_blocked):

[guest271314]

Thanks. Unfortunately I'm running Linux on a live USB so I don't think I can build Chromium on this temp file system. 

I'll have to figure out a way to do that.

[Daniel Cheng]

On Sat, 4 Nov 2023 at 15:19, guest271314 <guest...@gmail.com> wrote:

> You have been repeatedly told that this does not happen if safe browsing is disabled, and furthermore, if you do see concrete evidence of this happening, that is a bug that would be addressed and fixed. I would be happy to file that bug on your behalf if you have evidence of this happening.

I provided the evidence in this post.

I deliberately turned off Google Safe Browsing. When I do a cursory search, follow links to why the files I download are being blocked, all roads lead back to Google Safe Browsing. I'm not imagining the links I am following. I'm not sure why me following links and showing how Google Safe Browsing keeps getting mentioned in Google documentation is leading me to this conclusion. How could I logically conclude otherwise?

Nothing in the warning says that it is being blocked due to file scanning. There *is* a warning to enable safe browsing if you download files with safe browsing wholly disabled. It is possible to trivially bypass that though, and it does not indicate safe browsing is enabled or scanning files.

Clicking on the arrow gives:

 

Whether Google Safe Browsing or not, something is blocking download files, and I suspect scanning files written to the local file system when using FileSystemWritableFileStream.

https://bugs.chromium.org/p/chromium/issues/detail?id=1168715#c17

That bug is unrelated, and I've confirmed that the test case in that bug doesn't get blocked by anything when Safe Browsing is disabled. FileSystemWritableFileStream is specific to the HTML filesystem API, and isn't related to 'regular' downloads at all.

Daniel

[guest271314]

How to disable that warning? I didn't ask for that. If Google Safe Browsing is not interrupting my ability to download files in Chromium, what is? 

The point is to get rid of that prompt. It's just in my way, does nothing. 

>  FileSystemWritableFileStream is specific to the HTML filesystem API, and isn't related to 'regular' downloads at all.

I'm talking about WICG File System Access API - not W3C File System API and not WHATWG File System API.

Chromium implements showOpenFilePicker() and handle.createWritable() whichs writes actual files to the users' local file system, not origin specific storage in Chromium user configuration folder. See https://gist.github.com/guest271314/59be7a5b7c56ce48edea8821010c9cd2.

You are missing the point with 

>  It is possible to trivially bypass that though,

I don't want that banner in the UI at all. Wherever it comes from. I know the Web site or local protocol I'm on and don't need that warning, which is completely wrong for FILE: protocol per the controlling specification because FILE: is a secure context,

[guest271314]

>> and not WHATWG File System API.

Well, it get's tricky there because much of what is now in https://fs.spec.whatwg.org/ was once in https://wicg.github.io/file-system-access/ though apply to both relevant to the classes that write to the origin private file system and the actual file system of the users OS outside of Chromium configuration folder. 

So, a crswap file is created then the regular file is written when close() of the FileSystemWritableFileStream is closed or pipeTo(writable) is used. 

That is what the original author of WICG Native File System (now called File System Access) is talking about re reading files.

[guest271314]

It appears --disable-download-warning-improvements even though the "disable" prefix is not documented here https://peter.sh/experiments/chromium-command-line-switches/ does stop the prompt on FILE: protocol. Not on HTTP: protocol. 

[guest271314]

I can't make sense of how to use this https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/about_flags.cc#2836

// The choices for --enable-download-warning-improvements. This really should // just be a SINGLE_VALUE_TYPE, but it is misleading to have the choices be // labeled "Disabled"/"Enabled". So instead this is made to be a // MULTI_VALUE_TYPE with choices "Default"/"Enabled". const FeatureEntry::Choice kDownloadWarningImprovementsChoices[] = { {flags_ui::kGenericExperimentChoiceDefault, "", ""}, {flags_ui::kGenericExperimentChoiceEnabled, switches::kEnableDownloadWarningImprovements, ""}, };

[guest271314]

Looks like I am not the only developer in the field that is encountering this UI issue. Downstream in Brave world: Add a flag to disable download warnings when Safe Browsing is OFF #28917

[guest271314]

Looks like the relevant flag to disable the insecure download flag on Chromium is 

  --disable-features=InsecureDownloadWarnings

I tried 

 --safebrowsing-disable-download-protection

had no effect.

[guest271314]

Alright, Chromium Version 121.0.6109.0 (Developer Build) (64-bit) downloaded this morning with 

--disable-features=InsecureDownloadWarnings

flag set and Google Safe Browsing turned OFF is now giving a different warning on HTTP: (http://archive.ubuntu.com/ubuntu/pool/main/b/build-essential/)

"Unverified download blocked".

This is insane.

[guest271314]

Looks like 

--disable-features=InsecureDownloadWarnings

only works when 

- "Ask where to save each file before downloading" is enabled

and

- Make sure the HTTP: URL is actually the HTTP: URL you intended to load because CHrome will try to upgrade the request to HTTPS:

What is certain is it is not clear at all how to disable download warnings in any documentation I've read. The user is literally on their own trying to figure this out.

When the user estimates all roads lead to Google Safe Browsing, other "features" are in play.

[Peter Boström]

I don't think you should see "disable download warnings" as a supported feature of the browser. "--disable-features=InsecureDownloadWarnings" to me looks like you're disabling a feature that hasn't fully launched yet but once it's fully launched you won't be left with a switch to turn it off. It's (probably, idk) not intended to be user-configurable.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BsyWAO6Zj77BcRzYH72xxqnM8pTsY%2BgLqgHSO-9xz%2BBSBLS2g%40mail.gmail.com.

[guest271314]

> It's (probably, idk) not intended to be user-configurable.

That "feature" has absolutely zero use to developers.

It better be configurable to be turned off.

[guest271314]

> you won't be left with a switch to turn it off.

To be clear the "warning" makes no sense anyway.

It doesn't matter if the protocol is FILE:, HTTP: HTTPS:, CHROME-EXTENSION:, IPFS:, ISOLATED-APP:, etc. and the download extension is .ZIP, .TAR.GZ, .GZ,, .SH, .JS, .SO, what have you, Chrome strips the executable permissions of the files and the files in the folders therein.

I have been working on downloading directly and extracting the archives to folders and files using (WICG) File System Access API Chromium and Chrome-For-Testing from Chromium browser to continually update with the latest developer and canary builds.

So what is the warning for? A folder containing flat files?

[guest271314]

Nobody can really be rationally claiming that the _protocol_ a file or folder is downloaded from matter in the least.

O.k. The user is on HTTP. Downloads a ZIP file. Let's say they download Chromium Developer build from a site that is publishing Chromium unmodified from the original download, they're just providing Chromium, the open source project.

The ZIP file ain't gonna unzip itself.

After downloading from non-HTTPS: protocol, for whatever reasons the ordinary user has, the user would have to then deliberately unzip the archive. Then deliberately run chrome or chrome-wrapper.

For an ordinary .js or .sh file the file retaining executable permissions just ain't happening. We have to do chmod +x or equivalent.

So we are logically left with the reason being somebody is just trying to control somebody else's browsing behaviour, and influence how they decide to download content from the Internet, just because.

There is no "security" issue at all, thus no warning warranted under the auspices of HTTP: or FILE: protocol alone being a real concern for a user.

The user would literally have to hack themselves after downloading the file from an HTTP: protocol, which they would have to do had they downloaded the file or archive from HTTPS: protocol.

So, the warning itself makes no sense.

To proffer the idea that the nonsensical warning shouldn't even be capable of being turned off is rather astonishing. It tells me people want to control how other people are use Chromium, for some control or some other undisclosed reason, 'cause I can't see a reason given the technical facts concerning what an ordinary Chrome user would have to do for a file or archive downloaded from any URL to impact their security such that they should be warned about downloading files from certain protocols.

I suggest re-reading the Brave issue to get a gist of the sentiment of developers in the field, and how far removed from their idea of developing on Chromium maintainers can be - due to upstream decision to bake this, and other "security" "features" in to Chromium, without also thinking about people who don't want to do on their machines what you do on your machine. The option should always be present for developers to turn features on and off.

[Peter Boström]

Re. above, features refer to our experiment framework. When certain things or features change we roll them out gradually. Once they are rolled out we generally clean up the experiment and remove dead code from the then-unused path. That's why I said that you'll unlikely be able to turn this off using flags.

On Tue, Nov 7, 2023 at 1:24 AM guest271314 <guest...@gmail.com> wrote:

Nobody can really be rationally claiming that the _protocol_ a file or folder is downloaded from matter in the least.

O.k. The user is on HTTP. Downloads a ZIP file. Let's say they download Chromium Developer build from a site that is publishing Chromium unmodified from the original download, they're just providing Chromium, the open source project.

The user being on HTTP and downloading a file is reasonable and sufficient to surface this warning imo. If it's restricted to archive files or "potentially-dangerous" files that's probably more pragmatic than always surfacing it due to warning fatigue.

 

The ZIP file ain't gonna unzip itself.

After downloading from non-HTTPS: protocol, for whatever reasons the ordinary user has, the user would have to then deliberately unzip the archive. Then deliberately run chrome or chrome-wrapper.

Right, this warning assumes that the user downloading a file will also presumably do something with it, and the warning tries to discourage the "doing something with it" as the content can't be trusted.

 

For an ordinary .js or .sh file the file retaining executable permissions just ain't happening. We have to do chmod +x or equivalent.

So we are logically left with the reason being somebody is just trying to control somebody else's browsing behaviour, and influence how they decide to download content from the Internet, just because.

There is no "security" issue at all, thus no warning warranted under the auspices of HTTP: or FILE: protocol alone being a real concern for a user.

The user would literally have to hack themselves after downloading the file from an HTTP: protocol, which they would have to do had they downloaded the file or archive from HTTPS: protocol.

So, the warning itself makes no sense.

It does because if a man-in-the-middle attacker can change the contents of any zip or deb file that you're downloading (thx HTTP) you are /very likely/ to end up executing malware on your computer, often even with root privileges. Hence the warning.

 

To proffer the idea that the nonsensical warning shouldn't even be capable of being turned off is rather astonishing. It tells me people want to control how other people are use Chromium, for some control or some other undisclosed reason, 'cause I can't see a reason given the technical facts concerning what an ordinary Chrome user would have to do for a file or archive downloaded from any URL to impact their security such that they should be warned about downloading files from certain protocols.

I suggest re-reading the Brave issue to get a gist of the sentiment of developers in the field, and how far removed from their idea of developing on Chromium maintainers can be - due to upstream decision to bake this, and other "security" "features" in to Chromium, without also thinking about people who don't want to do on their machines what you do on your machine. The option should always be present for developers to turn features on and off.

The option for developers to turn features on and off (and never cleaning up experiments) means that we have to maintain untested otherwise-dead code paths forever. You may absolutely maintain your own fork that gets rid of these warnings, but it does not need to be supported upstream.

[K. Moon]

Before anyone adds another 5 replies to this thread, I just want to repeat my earlier point that chromium-dev is for discussing Chromium development. The intent of this list is to help Chromium developers in their day-to-day work.

Some (non-exhaustive) examples of Chromium development would be writing changes to the Chromium code, writing new documentation, filing useful bug reports, and so on.

Discussing Chromium as a user (even if you're developing your own code on top of Chromium, but not modifying Chromium itself) is out of scope, and should be done on chromium-discuss, not on this list.

As a reminder, failing to respect the purpose of the mailing list would, in my opinion, count as unproductive discussion under the code of conduct, and grounds for further action if it continues.

[guest271314]

> The user being on HTTP and downloading a file is reasonable and sufficient to surface this warning imo. 

I don't. Developers in the field don't.

> Right, this warning assumes that the user downloading a file will also presumably do something with it, and the warning tries to discourage the "doing something with it" as the content can't be trusted.

So you confess this is a sociall engineering experiment trying to influence users in the UI based on your own on-house beliefs.

> It does because if a man-in-the-middle attacker can change the contents of any zip or deb file that you're downloading (thx HTTP) you are /very likely/ to end up executing malware on your computer, often even with root privileges. Hence the warning.

That can happen on any protocol and any Web page.

The Internet and all signal communications are insecure.

As of last century certain entities were intercepting and analyzing 20 TB per second in real-time. There is no such thing as "secure" signal communications, period.

If you are _starting_ an experiment you need to begin with the idea the you Chromium developers might be the only people who feel the way you do.

Do what you want on your own machine.

Don't try to engineer user behaviour based on erroneous fears _you_ have.

[guest271314]

K. Moon.

I don't use the term "respect" lightly. With all due respect this is about Chromium source code development. The psychology that CHromium developers have groomed for themselves and the apparent inability to listen to developer feedback from the wild.

I think you are in a cloistered hall where you tend to agree with each other in-house, ignore everything that is going on outside of between each other, which is a rather limited range of opinion, then release the limited opinions to millions in Chrmium. Now, it can be that only the author of the experiment finds the feature they have in their own heads useful, and nobody else.

I'm just saying your psychology needs to include the idea of options for developer to turn off whatever you think is good for you on your own machine.

I mean if we are talking about Chromium source code I've read the weakest excuse ever for not removing clearly racist language from Chromium source code in this discussion about Chromium source code. Something to the effect it would mean somebody would have to work to remove the color coding of "whitelisted" and "blacklisted" from Google Safe Browsing - even after you know the inclusive language bug is real. You say nothing about that. Go get that done. Warning users about a download ostensibly because of a protocol is nonsense. You might as well warn users not to download Chrome too. 

[Nick Harper]

On Tue, Nov 7, 2023 at 7:07 AM guest271314 <guest...@gmail.com> wrote:

> The user being on HTTP and downloading a file is reasonable and sufficient to surface this warning imo. 

I don't. Developers in the field don't.

> Right, this warning assumes that the user downloading a file will also presumably do something with it, and the warning tries to discourage the "doing something with it" as the content can't be trusted.

So you confess this is a sociall engineering experiment trying to influence users in the UI based on your own on-house beliefs.

> It does because if a man-in-the-middle attacker can change the contents of any zip or deb file that you're downloading (thx HTTP) you are /very likely/ to end up executing malware on your computer, often even with root privileges. Hence the warning.

That can happen on any protocol and any Web page.

The Internet and all signal communications are insecure.

There is a distinct difference between the security properties of HTTP and HTTPS. If a file is downloaded over HTTP, anyone on the network path between you and the server (e.g. the operator of the coffee shop wifi you connected to, or if you're using a VPN, someone between the VPN's exit node and the server) can modify the contents undetected. With HTTPS, an on-path network attacker can't modify the contents sent in the TLS connection. https://www.chromium.org/Home/chromium-security/education/tls/ covers more of the differences between plaintext HTTP and TLS.

If you download a file over HTTP, the browser has no way of knowing whether the bytes it received are the bytes the server sent, but if it's downloaded over HTTPS, the browser is able to authenticate that the bytes received are the bytes sent by the server. The insecure download warning is pointing out that the bytes received over HTTP might not be the bytes the server sent.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BsyWAPLQJ_EbEBULoe61k1s5TMRr-EMLOehs62hp70sea2FNw%40mail.gmail.com.

[guest271314]

Yes, I know that. 

I want to deliberately turn the warning notification off.