Unfortunately, there's little Chrome can do here to prevent elaborate social engineering. 

On top of that, these downloads should still be going through the Safe Browsing service.

I didn't realize chrome had data uris go through the safe browsing service, In my testing I did not get any messages from chrome blocking the .bat file.

Could you help me in triggering this feature so I can see if its possible to bypass?

Sure. There are instructions at https://www.google.com/about/appsecurity/chrome-rewards/ (ctrl+f for download protection bypass).

Adding the Safebrowsing VRP component in case anyone more familiar with it wants to chime in. I didn't specifically test this case to see if we were getting a ping, but I believe it's handled.

Thank you.

Yes I can confirm a ping was sent to the server (following instructions)
But cant this be circumvented by adding padding to the data uri? 

+jialiul who might be interested in download by data: URL aspect

This is also directly related to  bug 629637 : .bat files should display a "mark of the web" confirmation before running.

And another relevant bug: bug 63773

There is a bunch of bugs where the UI blindly accepts input without checking if it's possible for a human to acknowledge the contents of the dialog. It would be great if we could add some heuristics to all these UI surfaces to prevent this sort of clickjacking.

Agree with #7, mark of the web might be missing, though safe browsing did its job as long as:
(1) user enables safe browsing service on chrome
(2) bat file does not come from whitelisted domains or on private network or hosted as local file  (this is for privacy consideration). 

In your case, I guess safe browsing did not find any known badness in the bat file or you tested locally. 
To verify if safe browsing is kicked in:  goto chrome://histograms, look for "SBClientDownload.CheckDownloadStats"  and see if counter increases.

Reopening this bug and blocking it on bug 63773. There are things we can do to prevent this sort of social engineering that relies on how and where Chrome displays UI surfaces.

Not applicable for VRP since the ping is sent (as per #5).

Setting priority (low, unfortunately, as I don't think anyone is actively working on this right now).

SafeBrowsing seems to be working as intended. Perhaps we can remove the SafeBrowsing component from this issue?

Yeah, this isn't a SafeBrowsing issue at all, it's a clickjacking attack against Chrome's native UI.

The malicious site has to evade both SafeBrowsing and the OS' built-in checks for downloaded files in order for the dropped file to run.

To fix, we could consider a variety of approaches, including, as suggested in #1, a visibility timer. (Firefox does this for security surfaces like the download dialog).

Let's treat this as a security bug. Downloads UI should really not be clickjackable.

I think it's reasonable to add a small delay to the UI before accepting user interaction.  We can add it specifically to the download UI.  Is there another bug tracking adding this to all browser-related UI?

shaktisahu@ can you take a look when you get a chance?