We haven't supported opening intermediate files or otherwise interfering with an ongoing download. This is especially the case where the download finalization steps include safe browsing checks. However, it seems users are doing so anyway. So we'll need to treat this as a valid use case and make it safer to do so.

We could (for a set of whitelisted file types which are known to be safe for streaming):

* Front load some of the SB checks are that currently put off until the download completes. URL and host based checks can be performed at the start of the download.

* Perform the final rename early.

* Avoid the download content check, which would be a no-op.

* Allow invoking 'Open' while the download is in progress instead of only allowing open after download completion.

This would effectively open up these file types for streaming safely.

+SafeBrowsing as well to evaluate this suggestion.

I moved the resumption behavior into another bug:  Issue 658412

For file types we think aren't dangerous, it seems reasonable to do url/host checks up front and call it safe.  But if we need the content digest to check its safety, we'd need to let it complete first.

#2: Yup. I was thinking something like the allow_auto_open setting which would whitelist a set of file types to be streamed.

We can even go to a point where the initial URL safety check can return something like "need-content-digest" that would block the file from being streamed. This can happen on a per file basis in case we want to look at the URL chain prior to making a call on whether the file is safe for streaming.

Perhaps we can chat about this later this week since it involves non-trivial backend work.

 Issue 660737  has been merged into this issue.

Ah. Merging with older issue.