I think that request makes sense. This could be useful in EDU and regulated industries.

For setting 2, how do we determine what dangerous filetypes are? Some are easy, such as exe or bat, but others like scr or java files can be dangerous as well. I'm wondering if there's a list that already exists for such types.

Assigning to mad@ who's looking for a new FR to tackle.

Feel free to assign back to me if you change your mind.

Maybe we could resolve  Issue 331057  as a duplicate of this? WDYT?

I think we should keep them separate. Issues  331057  & 616135 deal with the DownloadDirectory policy, which already exists and is well documented.

I think it's better to introduce a new policy specifically for disabling downloads.

+Julian for his input on policies.

Agree, I think we should keep the two bugs separate even if we get them fixed in the same effort.

As for this particular request there are few open questions though - what about the "Save As..." context menus. Are those going to be disabled too in the most strict setting. Also what about printing to PDF?

I think we should start with only the first three options first and then if ever needed look how we get to the last one. It has the potential to be a can of worms that we might never get 100% covered.

The feature requests that we've considered for downloads in the past:

* Override auto-open / danger level -- possibly per origin.

  We disallow opening some file types automatically. Folks have asked for overrides for enterprises in the past for file types like .jnlp and even .exes.

* Disable SB pings for downloads from private networks.

  Some known private networks should already be excluded from some SafeBrowsing pings due to privacy / confidentiality reasons. Orgs can't currently control these via policy. The SafeBrowsing pings contain a lot of details including redirect chains, IP addresses, filenames, and digests of downloads.

  This ties into the previous FR on controlling the danger level of files downloaded from private networks. Once SB is disabled for a download, it automatically falls back on the dangerous file list for deciding when to prompt users for dangerous downloads. Admins want to be able to disable prompting for executables and other files that are deployed via their intranets.

Both of these options will likely rely on some concept of a 'private' or 'safe' network with additional restrictions. E.g. foo.example.com is safe iff when talking over https. 

On Windows we could potentially derive this concept from IE's 'Intranet' zone settings. Doing so has the advantage that the mark-of-the-web annotation for executables and other file types would be consistent with Chrome's dangerous file handling. Without this, we could end up in situations where Chrome doesn't prompt for a whitelisted download, but Windows does. Thus forcing admins to keep two sets of settings in sync.

#3: The list of dangerous file types as understood by Chrome can be found at https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/safe_browsing/download_file_types.asciipb

See the README in that folder for how this information is used.

Would these two (i.e., Override auto-open & Disable SB pings) be included as different settings of the same policy described in the first comment above, or should these be separate policies?

If separate policies, we should add separate crbug issues for them.

If we want them to be extra settings, I need more information on how we would want them to work and how to describe them in the policy template.

@mad: Those look like separate policies to me. 

I don't have a strong opinion on auto-open overrides, beyond that it seems separate and is probably a bad idea to offer. 

Disabling SB pings, seems like a privacy option, unrelated to the intent here which is to restrict downloads.

+nparker for SafeBrowsing.

I think the settings mentioned in #9 should be separate policies as #12 points out.

But they'd probably need to be considered together with the policy mentioned in #0 either way. It would be difficult to communicate the effect of one policy without also describing the other due to how much these settings interact with each other.

For example, the download the policy evaluation could look something like this:

  Say we are downloading a file of type [TYPE] from [SOURCE].

  1. If download of [TYPE] from [SOURCE] are NOT allowed by policy in #0:
       Fail download with BLOCKED_BY_POLICY.

     # Note that if IE's security zones prohibit the download, then the download will be
     # silently removed when Chrome submits the download to the Windows Attachment Services
     # for scanning. We should probably check IE's policies in addition to Chrome's right
     # at the beginning instead of wasting time downloading something that will be discarded
     # later.
     # 
     # It's important to describe this interaction with IE Security Zones and Chrome's policy.

  2. If downloads of [TYPE] from [SOURCE] are allowed to be checked via SafeBrowsing:
       Go to INVOKE_SAFE_BROWSING
     Else:
       Go to FILE_TYPE_BASED_CHECKS

     # This check should be performed based on Chrome's policy described in #9.
     #
     # Some downloads that are from whitelisted domains are probabilistically sampled by
     # SafeBrowsing. The policy mentioned in #9 would be a "hard" whitelist in that
     # matching downloads will not be subject to any sampling.

  3. INVOKE_SAFE_BROWSING starts here:

     If ([TYPE], [SOURCE]) is NOT supported by SafeBrowsing:
       Go to FILE_TYPE_BASED_CHECKS

     # Note that SafeBrowsing may choose to sample the download even if it's not supported or even
     # if [SOURCE] is whitelisted.

     Submit [SOURCE], [TYPE] and other metadata to SafeBrowsing and request a server-side verdict.
     Let |verdict| be the verdict returned by the server.

     # |verdict| is one of { SAFE, DANGEROUS, UNCOMMON, POTENTIALLY_UNWANTED, DANGEROUS_HOST, UNKNOWN }

     If |verdict| is UNKNOWN:
       Go To FILE_TYPE_BASED_CHECKS

     Let |danger-level| be equal to |verdict|.
     Lookup |allow-auto-open| from download_file_types list.
     Go To EVALUATE_DANGER_LEVEL

  4. FILE_TYPE_BASED_CHECKS start here:

     Lookup |allow-auto-open|, |danger-level| from policy described in #9 for [TYPE], [SOURCE].
     If such a mapping is found:
       Go To EVALUATE_DANGER_LEVEL

     Lookup |allow-auto-open|, |danger-level| from download_file_types list.
     Go To EVALUATE_DANGER_LEVEL

     # |danger-level| as determined by lookup is one of the following { SAFE, DANGEROUS_TYPE, ALLOW_ON_USER_GESTURE }

  5. EVALUATE_DANGER_LEVEL starts here:

     If |danger-level| is SAFE OR
        |danger-level| is ALLOW_ON_USER_GESTURE and there is an associated user gesture:
         # Proceed with download. No prompting necessary.
         End

     If UX is allowed for |danger-level| based on policy described in #0:
        # Proceed with download. Follow default prompting guidelines.
        End

     Fail download with appropriate interrupt reason.

Note that the above isn't a specification. It's just a suggestion for how these policies could fit into the downloads flow. We should probably hash this out on a doc and try to come up with a simple model that can be clearly communicated to admins.

Also, I didn't wish to prescribe a set of policies in #9. I'm pointing out that folks have expressed a strong desire to control download related behaviors in enterprises. #9 is just one way that we could address some of this.

for my knowledge: when you say "folks", do we know that external enterprises want this? 

#14: See issue 92846, and  issue 518170  which primarily affect enterprises that use .jnlp. Also  issue 681702  is mitigated on the enterprise for IE via IE Security Zones.

nparker@ et. al. could likely comment on SafeBrowsing download protection needs in enterprise.

That's one awesome summary, Asanka! :)

When I am back in Munich next week I will try to summarize the list of possible policies that you describe in a doc and whatever else I can think of. We can continue the broad discussion there, file bugs for each one here and prioritize them.

Nice summary, Asanka.

I don't have  good data on feature requests from enterprises related to Safe Browsing. Emily -- we should talk to the Enterprise team to see how we'd learn of these.

I like robertsheild's suggested #0,1,3 -- I don't think we should do #2 until we have a well-curated list dangerous extensions, and can demonstrate that our settings match a published policy. Right now we have a small set of "DANGEROUS" files (~17 of ~200), and then a lot of types that will give a soft warning but won't if Safe Browsing thinks its safe.  These settings have evolved over time and some were adjusted in some cases to balance between likelihood-of-threat and the commonality of the file, so they don't define a clear security boundary. I'm wary of suggesting to Enterprises that we can "block all file types that might be dangerous to your OS," since that's impossible to determine.

So unless I missed something, I can go ahead and implement the behavior described in the initial comment, right?

The only thing missing is what kind of UI/messaging do we want to give the user when a download is rejected. Would it be enough to have a message in the download tray, as for virus detection, with a more info link, for which we would need a support page.

See attached file for example.

Deleted: block by admin policy.png 2.2 KB

	block by admin policy.png 2.2 KB View Download

My general summary of this:

* I like the messaging in #18. 

* I reckon the comment in #17 about whether AllowDownloads policy level 2 - "Disable dangerous files and filetypes" - is useful or whether it offers a false sense of security is worth some discussion. 

The canonical list is here: https://codesearch.chromium.org/chromium/src/chrome/browser/resources/safe_browsing/download_file_types.asciipb

IMO anything marked as danger_level DANGEROUS or ALLOW_ON_USER_GESTURE should be disallowed at policy level 2, if we decide that policy level 2 is worthwhile.

* We should document for admins the download decision flow and how it is affected by various policies as laid out in #13 and #16.

* Julian describes edge cases involving Save As and Printing in #8 that need to be handled. 

The UI in #18 exists, except the wording on the shelf is just "Blocked". The shorter wording is due to space constraints.

The "More info" link takes them to https://support.google.com/chrome/?p=ui_download_errors where the "Download blocked" zippy shows a longer explanation.

This UI is shown when the Security Zones are configured to block the specific download.

Will there be an update to the blocked download article (https://support.google.com/chrome/answer/6261569) once we support the policy? Should we file a follow up bug about it?

About comment #17 and option 2, how about we don't rely on the file type, but instead state that we will block anything that safebrowsing would have given any warning?

#21: There should be an update to the HC article.

There will be five different concepts of "blocking" in Chrome as it pertains to downloads:

Downloads can be blocked by
1. OS policy.
2. AV / other products via Windows Attachment Services.
3. Safe Browsing.
4. Chrome downloads policy (being introduced in this issue)
5. Chrome Supervised user restrictions (on Chrome OS).

[There may be others. Those are just off the top of my head.]

Users will need to be able to tell these apart since the type determines how they should get their download unblocked if they believe it was blocked erroneously. The article we currently have focuses only on 3. :-(

I uploaded an initial INCOMPLETE CL here: https://codereview.chromium.org/2674973003/

As mentioned in the review request, I don't really like the way I implementd it, but that's the only way I found to make it work without adding a new API on the DownloadItem class (just added an argument to an existing one). I'm open to any counter proposal :-)...

How does the logic in this CL handle the edge case I mentioned above - "Save as..." links and printing to PDFs?

As I said, this is NOT a complete CL, it's the initial approach to confirm if I'm going in the right direction or not, for the interaction with the download item.

any update on when this might be put into place?

I've been reassigned to higher priority tasks. I should be back on this in a couple of weeks.

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

commit 4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c
Author: mad <mad@chromium.org>
Date: Wed Jun 14 19:27:08 2017

Adding a DownloadRestrictions group policy.

TBR=jochen@chromium.org
for trivial changes in:
chrome/browser/profiles/profile_impl.cc
content/public/browser/download_item.h
content/public/test/fake_download_item.h
content/public/test/fake_download_item.cc
content/public/test/mock_download_item.h

BUG= 683797 

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

[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/download/chrome_download_manager_delegate.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/download/chrome_download_manager_delegate.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/download/chrome_download_manager_delegate_unittest.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/download/download_prefs.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/download/download_prefs.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/browser/profiles/profile_impl.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/common/pref_names.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/common/pref_names.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/components/policy/resources/policy_templates.json
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/browser/download/download_item_impl.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/browser/download/download_item_impl.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/browser/download/download_item_impl_unittest.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/browser/download/download_manager_impl_unittest.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/browser/download/mock_download_item_impl.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/public/browser/download_item.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/public/test/fake_download_item.cc
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/public/test/fake_download_item.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/content/public/test/mock_download_item.h
[modify] https://crrev.com/4e9c44b9e4a05ba422bbe2f5d62b12d83071b94c/tools/metrics/histograms/enums.xml

Ths whitelist related stuff identified in #9 wasn't addressed by the committed CL, but will be in  issue 723658 .