[Downloads] Allow acquiring dangerous download file.

[Downloads] Allow acquiring dangerous download file.

A dangerous download can be accepted by the user or rejected. If
rejected, the downloaded file used to be deleted. This change adds
DownloadItem::AcquireFileAndDeleteDownload() which allows the caller to
acquire the dangerous file.

The intended consumer of this feature is SafeBrowsing where the caller
may want to acquire a dangerous file that's being discarded for the
purpose of further analysis.

Also change the logic during shutdown to no longer delete dangerous
downloads, but to cancel them.

TBR=rdsmith
BUG=244604
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202925

[benjhayden, 2013-05-14 20:48:05]

https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
File content/public/browser/download_item.h (right):

https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
content/public/browser/download_item.h:151: virtual void
AcquireFileAndDeleteDownload(
Method names containing "And" generally signal to me that the interface might be
cleaner if they were split up. In this case, why not let the caller call
AcquireFile() then Delete()?
In order to enforce the invariant !!download_file_ <=> IsInProgress(),
AcquireFile might call Cancel() or require callers to ensure that the item is
not in progress and DCHECK(!IsInProgress()).

[asanka, 2013-05-14 21:14:34]

https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
File content/public/browser/download_item.h (right):

https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
content/public/browser/download_item.h:151: virtual void
AcquireFileAndDeleteDownload(
On 2013/05/14 20:48:05, benjhayden_chromium wrote:
> Method names containing "And" generally signal to me that the interface might
be
> cleaner if they were split up. In this case, why not let the caller call
> AcquireFile() then Delete()?
> In order to enforce the invariant !!download_file_ <=> IsInProgress(),
> AcquireFile might call Cancel() or require callers to ensure that the item is
> not in progress and DCHECK(!IsInProgress()).

The intention is for this operation to be atomic. This method would be called on
an IN_PROGRESS dangerous download to discard the DownloadItem but not the
download file.

Although, 'AcquireFileAndRemove' is probably a better name.

[Randy Smith (Not in Mondays), 2013-05-15 19:09:41]

On 2013/05/14 21:14:34, asanka wrote:
>
https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
> File content/public/browser/download_item.h (right):
> 
>
https://codereview.chromium.org/14947007/diff/1/content/public/browser/downlo...
> content/public/browser/download_item.h:151: virtual void
> AcquireFileAndDeleteDownload(
> On 2013/05/14 20:48:05, benjhayden_chromium wrote:
> > Method names containing "And" generally signal to me that the interface
might
> be
> > cleaner if they were split up. In this case, why not let the caller call
> > AcquireFile() then Delete()?
> > In order to enforce the invariant !!download_file_ <=> IsInProgress(),
> > AcquireFile might call Cancel() or require callers to ensure that the item
is
> > not in progress and DCHECK(!IsInProgress()).
> 
> The intention is for this operation to be atomic. This method would be called
on
> an IN_PROGRESS dangerous download to discard the DownloadItem but not the
> download file.
> 
> Although, 'AcquireFileAndRemove' is probably a better name.

As mentioned in a separate email, I'd like to find another way to do this. 
Holding off on reviewing the code until we resolve the "do we really need this
functionality?" question.

[asanka, 2013-05-22 19:33:10]

PTAL?

[benjhayden, 2013-05-22 19:43:26]

one fix then LGTM

https://codereview.chromium.org/14947007/diff/20006/content/browser/download/...
File content/browser/download/download_manager_impl_unittest.cc (right):

https://codereview.chromium.org/14947007/diff/20006/content/browser/download/...
content/browser/download/download_manager_impl_unittest.cc:110:
MOCK_METHOD1(Delete, void(DeleteReason));
Update.

[Randy Smith (Not in Mondays), 2013-05-22 21:34:31]

On 2013/05/22 19:33:10, asanka wrote:
> PTAL?

{Asked Asanka offline for yet another go-round on the interfaces :-{;
specifically, I don't like the overloading of a null callback with meaning
"don't delete the file; instead give me ownership" and suggested a third
interface that you use when you want ownership that gets the callback.]

[asanka, 2013-05-22 22:37:59]

PTAL?

This goes back to the addition of the AcquireFileAndDeleteDownload() API.

[Randy Smith (Not in Mondays), 2013-05-23 13:56:43]

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
content/browser/download/download_item_impl.cc:419: callback.Run(current_path_);
Under what circumstances will we take this path?  It seems like it would only
happen if downloads were complete; do we want to support that case?

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
content/browser/download/download_item_impl.cc:1423: // Will be deleted at end
of task execution.
Could you move this comment down a line to make clear what it's referring to?

https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
File content/public/browser/download_item.h (right):

https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
content/public/browser/download_item.h:147: virtual void
AcquireFileAndDeleteDownload(
What do you think of naming this in some fashion that makes it clear that it's
targeted at dangerous downloads?   

The vision I originally had was having three interfaces
"ValidateDangerousDownload()", "DiscardDangerousDownload()", and
"StealDangerousDownload()".  It's probaby not worthwhile wrapping Delete in
DiscardDangerousDownload, and changing DangerousDownloadValidate's name seems
excessive, but I'd like to nominally associate this with dangerous downloads,
maybe with a DCHECK, so it doesn't get used for other things and so we consider
removing it when/if danger is hoisted up into chrome.

[asanka, 2013-05-23 15:53:30]

https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
File content/public/browser/download_item.h (right):

https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
content/public/browser/download_item.h:147: virtual void
AcquireFileAndDeleteDownload(
On 2013/05/23 13:56:43, rdsmith wrote:
> What do you think of naming this in some fashion that makes it clear that it's
> targeted at dangerous downloads?   
> 
> The vision I originally had was having three interfaces
> "ValidateDangerousDownload()", "DiscardDangerousDownload()", and
> "StealDangerousDownload()".  It's probaby not worthwhile wrapping Delete in
> DiscardDangerousDownload, and changing DangerousDownloadValidate's name seems
> excessive, but I'd like to nominally associate this with dangerous downloads,
> maybe with a DCHECK, so it doesn't get used for other things and so we
consider
> removing it when/if danger is hoisted up into chrome.

How about this?:
- ValidateDangerousDownload()
- StealDangerousDownload()
- Cancel()/Remove()

There'll be no Delete(). It's currently used to discard dangerous downloads,
which could be done by Remove(). The other use is to discard dangerous downloads
during browser shutdown. That can be accomplished by Cancel() instead.

[Randy Smith (Not in Mondays), 2013-05-23 15:54:12]

On 2013/05/23 15:53:30, asanka wrote:
>
https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
> File content/public/browser/download_item.h (right):
> 
>
https://codereview.chromium.org/14947007/diff/32002/content/public/browser/do...
> content/public/browser/download_item.h:147: virtual void
> AcquireFileAndDeleteDownload(
> On 2013/05/23 13:56:43, rdsmith wrote:
> > What do you think of naming this in some fashion that makes it clear that
it's
> > targeted at dangerous downloads?   
> > 
> > The vision I originally had was having three interfaces
> > "ValidateDangerousDownload()", "DiscardDangerousDownload()", and
> > "StealDangerousDownload()".  It's probaby not worthwhile wrapping Delete in
> > DiscardDangerousDownload, and changing DangerousDownloadValidate's name
seems
> > excessive, but I'd like to nominally associate this with dangerous
downloads,
> > maybe with a DCHECK, so it doesn't get used for other things and so we
> consider
> > removing it when/if danger is hoisted up into chrome.
> 
> How about this?:
> - ValidateDangerousDownload()
> - StealDangerousDownload()
> - Cancel()/Remove()
> 
> There'll be no Delete(). It's currently used to discard dangerous downloads,
> which could be done by Remove(). The other use is to discard dangerous
downloads
> during browser shutdown. That can be accomplished by Cancel() instead.

SGTM.

[asanka, 2013-05-24 01:17:11]

PTAL?

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
content/browser/download/download_item_impl.cc:419: callback.Run(current_path_);
On 2013/05/23 13:56:43, rdsmith wrote:
> Under what circumstances will we take this path?  It seems like it would only
> happen if downloads were complete; do we want to support that case?

It could also be interrupted.

https://codereview.chromium.org/14947007/diff/32002/content/browser/download/...
content/browser/download/download_item_impl.cc:1423: // Will be deleted at end
of task execution.
On 2013/05/23 13:56:43, rdsmith wrote:
> Could you move this comment down a line to make clear what it's referring to?

Done.

[Randy Smith (Not in Mondays), 2013-05-24 02:06:15]

Only concern is around UMA semantics changing.

https://codereview.chromium.org/14947007/diff/46001/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/46001/content/browser/download/...
content/browser/download/download_item_impl.cc:373: user_cancel ?
DOWNLOAD_DISCARD_DUE_TO_USER_ACTION
Hmmm.  Is this changing the semantics of the UMA?  What happens if the user
cancels a dangerous download (rather than removes it)?  Do they ever have that
option?

[asanka, 2013-05-24 20:32:46]

There was a UMA glitch and I restored the ability to steal an interrupted
dangerous download.

https://codereview.chromium.org/14947007/diff/46001/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/46001/content/browser/download/...
content/browser/download/download_item_impl.cc:373: user_cancel ?
DOWNLOAD_DISCARD_DUE_TO_USER_ACTION
On 2013/05/24 02:06:16, rdsmith wrote:
> Hmmm.  Is this changing the semantics of the UMA?  What happens if the user
> cancels a dangerous download (rather than removes it)?  Do they ever have that
> option?

It's incorrect to do UMA in both Remove() and Cancel() since the former calls
the latter.

The UI we expose to the user doesn't allow canceling a download that's
dangerous. It's always either ValidateDangerousDownload() or Remove(). However,
it is possible for the extensions API to call Cancel().

[Randy Smith (Not in Mondays), 2013-05-28 17:29:40]

Basically nits.  I'll give you an LGTM now and let you decide how to deal with
the comments below--feel free to ask me for another round if you do changes
large enough to warrant it.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_browsertest.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_browsertest.cc:704:
downloads[0]->Cancel(true);
Not a blocking comment, just for my curiosity: Why change this to Cancel()
instead of Remove() as you do elsewhere?

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_item_impl.cc:304: void
DownloadItemImpl::StealDangerousDownload(
Given that this is one of the ways that we can transition out of the "dangerous"
state,  and we have UMA for the other two ways, shouldn't we have UMA here as
well?

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_item_impl_unittest.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_item_impl_unittest.cc:1157:
TEST_F(DownloadItemTest, StealInterruptedDangerousDownload) {
Do you want a version of this that steals an interrupted dangerous download for
which the file has already been deleted?

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_manager_impl.cc (left):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:356:
download->Delete(DownloadItem::DELETE_DUE_TO_BROWSER_SHUTDOWN);
There's a semantic difference we're putting in which I think I'm ok with but I
wanted to call out: It used to be that dangerous downloads cancelled due to
shutdown were removed from the history.  Now they're just cancelled and the
download file removed.  I think that's ok (heck, I think it's better).  But it
is a semantic change worth calling out.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_manager_impl.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:338: // remove on disk, and in
progress ones we need to cancel.
This comment seems obsolete.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:345: it++;
We're no longer removing downloads here, so would it be worthwhile rewriting
this loop to be a bit simpler?

[asanka, 2013-05-28 22:01:38]

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_browsertest.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_browsertest.cc:704:
downloads[0]->Cancel(true);
On 2013/05/28 17:29:40, rdsmith wrote:
> Not a blocking comment, just for my curiosity: Why change this to Cancel()
> instead of Remove() as you do elsewhere?  

I though that Cancel() is what agrees with the intention of the test. Both in
terms of the test name and comments, and also with the outcome being tested.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_item_impl.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_item_impl.cc:304: void
DownloadItemImpl::StealDangerousDownload(
On 2013/05/28 17:29:40, rdsmith wrote:
> Given that this is one of the ways that we can transition out of the
"dangerous"
> state,  and we have UMA for the other two ways, shouldn't we have UMA here as
> well?

The Steal() -> Remove() -> Cancel(true) call adds the UMA. A
StealDangerousDownload() is recorded as a UserDiscard event.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_item_impl_unittest.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_item_impl_unittest.cc:1157:
TEST_F(DownloadItemTest, StealInterruptedDangerousDownload) {
On 2013/05/28 17:29:40, rdsmith wrote:
> Do you want a version of this that steals an interrupted dangerous download
for
> which the file has already been deleted?

Yup. Thanks and done.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_manager_impl.cc (left):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:356:
download->Delete(DownloadItem::DELETE_DUE_TO_BROWSER_SHUTDOWN);
On 2013/05/28 17:29:40, rdsmith wrote:
> There's a semantic difference we're putting in which I think I'm ok with but I
> wanted to call out: It used to be that dangerous downloads cancelled due to
> shutdown were removed from the history.  Now they're just cancelled and the
> download file removed.  I think that's ok (heck, I think it's better).  But it
> is a semantic change worth calling out.

Yeah. I updated the CL description to mention this.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
File content/browser/download/download_manager_impl.cc (right):

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:338: // remove on disk, and in
progress ones we need to cancel.
On 2013/05/28 17:29:40, rdsmith wrote:
> This comment seems obsolete.

Done.

https://codereview.chromium.org/14947007/diff/72023/content/browser/download/...
content/browser/download/download_manager_impl.cc:345: it++;
On 2013/05/28 17:29:40, rdsmith wrote:
> We're no longer removing downloads here, so would it be worthwhile rewriting
> this loop to be a bit simpler?

Done.

[asanka, 2013-05-28 22:03:43]

+joi: Could you look at content/public?

[Jói, 2013-05-28 22:52:15]

LGTM for //content/public.  +jam as FYI on API change.

[asanka, 2013-05-29 16:23:32]

Thanks!

TBRing renames and conversions of Delete() => Remove().

[commit-bot: I haz the power, 2013-05-29 16:25:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/14947007/90001

[commit-bot: I haz the power, 2013-05-29 17:08:18]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2013-05-29 17:40:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/14947007/90001

[commit-bot: I haz the power, 2013-05-29 18:57:47]

Change committed as 202925