dtrainor@, qinmin@,

This isn't an intended behavior, is it?

This is currently expected. i think we need to have a better understanding whether exiting the browser really means killing a download.  On android, browser process can easily get killed, but we shouldn't kill in progress download.
BTW, as long as the file is created, i think there is always trace on the disk (unless user formats the disk) to locate that file even if Chrome deletes the file. Additionally, if an incognito download completes, chrome will not delete that file when user exits incognito mode. So I don't know if this is really a serious privacy issue.

Thank you for the explanation. I agree that when download starts, we have something on disk and unless we wipe it (and maybe even so), a trace stays.

But I think when the user is shown a prompt that this action will stop downloads, then it means that the user does not want the download, and keeping the partial file is no more the correct action. In regular mode, the is just cluttering user's disk, but in incognito mode, it's leaking data that user has told us s/he does not want.

So I think deleting the partial file is a better approach.

We should clean these up if we are explicitly canceling the download based on user input.

qinmin@ can you take a look?

Min, just wanted to ping you on this.  We should try to do this on shutdown for incognito.  IIUC we can delay the shutdown (probably delay the dialog response) until the files are removed.

On Android it's slightly more difficult because shutdown isn't something we control.  We can probably prepend the package name to account for things like beta/dev/stable downloads and use that to auto-remove on restart or via some cleanup job?  wdyt

This is a duplicate of 901642. 

However, the android incognito issue is still there as we don't get a clean shutdown.