[Downloads] Gracefully handle SafeBrowsing check failures.

[Downloads] Gracefully handle SafeBrowsing check failures.

If the SafeBrowsing service couldn't come up with a definite verdict for
some reason (e.g. couldn't reach the backend or encountered some error)
it would default to a verdict of SAFE. This in turn could cause a
download that would've been considered dangerous due its file type to be
considered safe. This change introduces an UNKNOWN verdict that the
SafeBrowsing service can use to indicate that a verdict couldn't be
determined.

Downloads then uses that signal to revert to the old behavior of
displaying a dangerous downloads warning based on the file type.

BUG=269157
Committed: https://crrev.com/ae43e03978b7aa5ce03f0262d3ab6c5d2b0153c1
Cr-Commit-Position: refs/heads/master@{#295167}

[asanka, 2014-09-12 01:18:50]

asanka@chromium.org changed reviewers:
+ mattm@chromium.org

[asanka, 2014-09-12 01:19:31]

PTAL.

[mattm, 2014-09-12 02:52:40]

Thanks for doing these changes!

https://codereview.chromium.org/565053002/diff/1/chrome/browser/download/chro...
File chrome/browser/download/chrome_download_manager_delegate.cc (right):

https://codereview.chromium.org/565053002/diff/1/chrome/browser/download/chro...
chrome/browser/download/chrome_download_manager_delegate.cc:311: if (service) {
I think there may be a minor race here if the file danger_type is set to
DOWNLOAD_DANGER_TYPE_MAYBE_DANGEROUS_CONTENT and then the user disables
safebrowsing before the download completes, the case in CheckClientDownloadDone
that resets it to DOWNLOAD_DANGER_TYPE_DANGEROUS_FILE wouldn't happen.

Is that handled else where, or should it also check for
item.IsDangerousFileBasedOnType() if (!service)? Or is it too small an issue to
worry about?

https://codereview.chromium.org/565053002/diff/1/chrome/browser/safe_browsing...
File chrome/browser/safe_browsing/download_protection_service_unittest.cc
(right):

https://codereview.chromium.org/565053002/diff/1/chrome/browser/safe_browsing...
chrome/browser/safe_browsing/download_protection_service_unittest.cc:603: // On
!OS_WIN, no file types are currently supported. Hence all erquests to
requests

[mattm, 2014-09-12 03:05:35]

Oh, and even if that does sound true, we're still better with this CL than not.
So LGTM to land this and (maybe) fix that later if you want.

[asanka, 2014-09-16 21:29:18]

The CQ bit was checked by asanka@chromium.org

[commit-bot: I haz the power, 2014-09-16 21:31:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/565053002/100001

[commit-bot: I haz the power, 2014-09-16 22:56:01]

Committed patchset #6 (id:100001) as 8e8723954104c5a58689462daaaf94cb04eb103d

[commit-bot: I haz the power, 2014-09-16 22:57:00]

Patchset 6 (id:??) landed as
https://crrev.com/ae43e03978b7aa5ce03f0262d3ab6c5d2b0153c1
Cr-Commit-Position: refs/heads/master@{#295167}