If in chrome settings, you untick "Protect you and your device from dangerous sites" in Privacy settings, the problem goes away.

Proof of bug at:

http://www.findmaps.co.uk/chrometest/

I have the same problem. 
- The bug is due to PepperFlash version or last Chrome version ?
- Do we know when this problem will be resolved ?
Thanks,

The same problem. I noticed the problem with the last update.

I confirm that disabling the "Protect you and your device from dangerous sites" options resolves the issue... but it should work even with that enabled.

@ian.marett.find: Your proof of bug appears to require flash and not reference www.example.com/test.zip anywhere; is this specifically a problem with downloading from inside flash?

As the title says: "Unable to download .zip,.exe,.com,.bat files through flash/flex", so yes, flash is required.

example.com/test.zip was just a simple example to show the process. The same code (when compiled into swf) works on all other browsers, but fails to open the "Save As" dialogue in Chrome 47.0.2526.106.

I tried to download with a diferent file name, by example... a "filename" test.zip and thes "savename" test.doc and works, the problen is the extension in de "savename". Not the real file name, is the file name that we can assign to the file.

var f:URLRequest = new URLRequest("http://www.example.com/test.zip"); //NO PROBLEM
var fr:FileReference = new FileReference();
fr.save(f, "test.zip"); //THE PROBLEM

if you try this "fr.save(f, "test.csv");"  its works.
Hope that this problem can be resolve

.xml is also not working. 

I too am having this issue.  I can save the zip content if we don't use the .zip extension in the filename.  This will break for our customers that use Chrome as their browser.

I also have pre-downloaded generated content from the server that I received in a previous request and i'm attempting to use the FileReference.save function to attempt to save the zip content with a filename ending in ".zip"

you do not need to actually have zip content.  The below line of code also does not generate the expected Save As dialog.

var saveFile:FileReference = new FileReference();
saveFile.save("just good ole string content","notazip.zip");

Could we adjust the console to use an externalinterface call that invoked a piece of javascript in the parent console page's html...which then to the URI passed to the externalinterface call like so:

function launchURL(url) {
window.open(url,'_blank');
window.open(url);
}

?

e.g. flash

ExternalInterface.call("launchURL", URL); 

parent HTML page javascript:

function launchURL(url) {
window.open(url,'_blank');
window.open(url);
}

       

Maybe this isn't relevant...if flash itself is actually creating/delivering the contents of the file... disregard..

.gzip extension also fails the in the same way as .zip, .exe, .com, .bat, .xml

Experiencing same issue for .gzip, .zip, .exe, .com, .bat, .xml

mmenke: Why the PDF label? Isn't this a Flash bug?

I do not believe this is specifically tied to a version of flash. I have been able to reproduce regardless of the flash version I use, so long is the build is >=47.0.2526.106. I tested 47.0.2526.73 and it works fine, and it appears to use the same version of flash as 47.0.2526.106. (Flash 20.0.0.267)

Also, I am able to reproduce the issue on OSX as well as Windows. 

This is working-as-intended.
For security reasons, Chrome will now block dangerous (executable) file types from being downloaded via Flash since they bypass Chrome's Safe Browsing protection.  This bypass is being actively exploited MUCH more than it is used for legitimate reasons unfortunately, so for users' security it is blocked.

If you need to work around it: 1) download via javascript rather than within Flash, or 2) download to a different extension and ask the user to rename. If there is a domain where a large number of users are adversely affected (>1000 downloads/day), please let me know so we can look into it further.

A .zip,.xml,.gzip are executable files? I understand the .exe, .bat, etc. but .zip?

This also blocks Zip files *created* within Flash applications, which we need to do for exporting certain data. This is a very legitimate use which does not even involve network traffic. I'm not so sure it's even possible to serialize the data and save it somehow using Javascript, given that a very large amount of our users is still on old versions of IE. Also, using a different file extension and then requiring all our users to manually rename files is not a viable solution. Most of them are in corporate or governmental environments, and if the default Windows settings are used, file extensions are hidden in Windows explorer which complicates renaming the files (after they are saved). I suppose we could tell them to change the file extension upon saving but given the technological skill of many users I'm pretty sure this will trigger a lot of support tickets. As a bonus, especially this last one makes the whole "prevent zip from being downloaded" worthless as a security measure.

Now if this feature could be configured separately from "Protect you and your device from dangerous sites", we'd at least have a workaround which does not involve making the situation more dangerous than it was before. I hope you can come up with a better solution which does not involve crippling our perfectly legitimate application soon.

By the way, can the complete list of blocked extensions be found somewhere (aside from having to dig around in the source code)?

The .zip and .gzip block are ridiculous since those aren't executable in the first place. We now have to tell our users to either make their Chrome less secure so they can download a harmless zip file or force them into another browser. 
As mentioned, either please allow zip, gzip, etc. or create a separate setting for the flash block. 

Our domain is noteflight.com. We run a music notation site with almost 2M users who routinely export music files to an XML interchange format.  How can you classify .xml, a text file format, as a dangerous file type but allow .txt? This makes no sense.

Our users are very upset. Please change this policy for .xml files immediately.

We have many customers that use this feature regularly in our product. Specifically downloading and saving files with the .zip extension. We don't meet the required prerequisite of >1000 downloads/day to help push for a fix for this issue; however, this change in the browser immediately impacts our entire customer base.

I'd like to still push to have this issue looked at.

Modern operating systems already have systems in place to help protect users from automatically executing things that are downloaded from the internet.

Just one that immediately comes to mind is that all "unknown" zip archives downloaded from the internet are flagged in Windows.  To be able to properly extract things like js files contained in the zip, the user must first unblock the zip archive before extracting it's contents. If they do not,  then js files are not extracted from the zip.

Please reconsider this issue.

I'm also concerned that not addressing this issue will lead to more users of Chrome to disabled the "Protect you and your device from dangerous sites" in the privacy settings to work around this issue. Toggling that option off will have a greater impact on end users than just allowing them to download zip files through corporate Flash/Flex applications. The intention of this "expected behavior" is to protect users, but it can actually have the exact opposite effect.

Experiencing same issue for .xml, .xls, .cvs

Our clients can't download .zip and .xml files. Are you kidding? Please fix asap.

We use the FileReference API to provide export options to our users in our SaaS product. Ever since Chrome had this 'security feature' introduced , our users cannot export content as .svg. Can you guys please confirm if .svg as a file type is also blocked? Our product has more than a million users. 
Thanks.

We have thousands of customer using our interface with 100's if not 1000's downloaded per day for .zip extension and this update has caused an increase in work

It is also making people move away from chrome to other browsers.

The set of files that are blocked includes those that are executable, can contain dangerous executables, or have known exploits in their default handlers.  This does include .svg and .xml at the moment.

To help measure the number of users and sites affected, please fill out this form if your users are experiencing issues due to blocked files:  http://goo.gl/forms/PA17hKYJG4

It's nice that Chrome makes the web more secure every day. Maybe, the best way to make the web more secure is by turning it off (or disable essential functionality).

As #31 mentioned, the only solution for this issue is to disable "Protect you and your device from dangerous sites". but in the end this makes the internet less secure for those who need the functionality to download zip / xml / and other files from specific sites.

To make this for all more user-friendly why don't you add a button "Manage exceptions" next to  "Protect you and your device from dangerous sites"? And with this button, the user can allow specific sites (for example large enterprise applications / internal project sites) which are allowed for downloading all the "insecure" file types (zip / xml)...

And a better solution would be:

- user try to download a zip file (or other type of the "insecure" files) from the specific project site
- Chrome shows a pop-up where all the security stuff is mentioned and asks the user if this page should be added to the whitelist (for allowed sites where users can download all the "insecure" file types) 
- if the user click "yes", the file will be downloaded and added to the whitelist (download is possible next time without any question)
- if the user click "only this time", the file will be downloaded and the user will be asked next time again
- if the user click "no", the file download is not possible

Of course, the user can always manage the allowed sites under "Manage exceptions" next to "Protect you and your device from dangerous sites".

But thinking about this issue brings me to my question:

Why is a zip file downloaded via flash more insecure as a zip file downloaded via HTML / javascript?

In the end the user is responsible for which files he is actively (!) downloading. And from which source. Not the browser.

For those of you who are desperate for a workaround, I've created one which basically nullifies the whole "security improvement", but there you go. Of course in our application we've wrapped it in a nice static helper function, but I'll leave that up to you.


// actionscript
if (Capabilities.manufacturer == "Google Pepper") {
    // workaround for chromium  issue 576708 : save using javascript helper function
    var b64e:Base64Encoder = new Base64Encoder();

    if (data is ByteArray)
        b64e.encodeBytes(data as ByteArray);
    else if (data is String)
        b64e.encode(data as String);
    else if (data is XML)
        b64e.encode((data as XML).toXMLString());
    else
        throw new Error("Don't know how to save this kind of data!");

    ExternalInterface.call("hst_saveFile", b64e.toString(), filename, mimetype);
}
else
{
    // workaround not required, proceed as usual
    // optionally, add action listeners here (or use a predefined FileReference instance)
    var fr:FileReference = new FileReference();
    fr.save(data, filename);
}


// javascript
function hst_saveFile(data_b64, filename, mimetype) {
    // guess mime type if no explicit value was given
    if (!mimetype) {
        var split = filename.match(/^(.+)\.(\w+)$/i);
        var ext = split.length == 3 ? split[1].toLowerCase() : null;

        // map of extension => mime type
        mimetypes = {
            zip: "application/zip",
            xml: "application/xml",
            csv: "text/csv",
            txt: "text/plain",
            jpg: "image/jpeg",
            png: "image/png"
        };

        // use value from map, or default to arbitrary binary data
        mimetype =
            (ext && ext in mimetypes)
            ? mimetypes[ext]
            : "application/octet-stream";
    }

    // create link and simulate clicking it (this will trigger saving the file)
    var el = document.createElement("a");
    el.setAttribute("href", "data:" + mimetype + ";base64," + data_b64);
    el.setAttribute("download", filename);
    el.click();
}

#41 No, I can not confirm this. Download doesn't work with https (in your example and in my flex applications).

I can not see any "Save As" dialogue in your example. And no file is downloaded in your example.

(Make sure you have "Protect you and your device from dangerous sites" enabled in settings.)

Small issue with my workaround. In the javascript code, the "var ext = ..." line will crash if the file name does not match the pattern. Use this instead to handle this situation:

var ext = split ? split[2].toLowerCase() : null;

I agree with everyone else.  Why is it safer to download a zip file from HTML vs Flash?  Our clients are calling us now to find out why they can't download their zip files.  There definitely needs to be a way to make exclusions.

My biggest concern is how Google makes this change without any warning.  A warning would allow developers to prepare for when the change actually occurs.

We are now telling our clients to ditch Chrome.  I guess Google only cares about grandma and grandpa who don't know what they are doing and don't want to provide a great product for corporations.

Just wanted to add this note about workarounds. Workarounds will not resolve issues for our installations.  Various companies run our software on their servers so there is no "one website" to patch with a workaround.  Also customers generally are not quick to upgrade as they have to first qualify changes before making them in their environments.  This change is having an immediate and lasting impact on our customer base.

holzber, to answer your question.  When they announced the intended working behavior they said, 

"For security reasons, Chrome will now block dangerous (executable) file types from being downloaded via Flash since they bypass Chrome's Safe Browsing protection."

Key part of the statement there is that downloads via Flash bypasses Chrome's Safe Browsing protection. So from their stance, the same download via Flash is not as safe as the download being done via HTML.

I'd imagine they are working towards making an update to also bring downloads being done via their Pepper Flash, into their Chrome Safe Browsing protection. Like they've already done for HTML.

One of my users reported there are new versions of Chrome and Flash out.
48.0.2564.82 and flash 20.0.0.286
.ZIP files have mysteriously started downloading again.
Anyone want to comment/confirm?

Confirmed .zip are downloading again. Thanks for you message. I couldn't tested with other extensions.

I've been able to confirm as well.  Customers are now able to download zip files again if they are using the following versions of Chrome and Flash

Chrome: 48.0.2564.82 m
Flash: 20.0.0.286

It would be nice if Google would respond as to whether the change in the new version is intended or a fluke so that we can all plan ahead.

Yes, .zip was unblocked intentionally.  They may need to be blocked again if a large malware campaign starts using them and dwarfing the legitimate usage.  A more nuanced blocking mechanism is in the works that would alleviate the troubles you've been having. Until then you should anticipate that, unfortunately, these may need to be blocked again.

I'll ask again: is there a complete and up-to-date list of blocked extensions available somewhere? If a list like that is being maintained, like a status page, we can at least explain our customers what's going on.

Or if the blocking mechanism gave a message when activated, instead of ignoring the download silently, that would be of great help too.

The file reference cancel event is called right away when supplying a file name with the bad extension.  That is at least a hook to do something different for the case of the file extension that is bad.

Chrome in version "49.0.2623.110 m" is also blocking "SWF" files, which I find rather silly. Would it be possible to get this extension white-listed too?

This is fixed in M52.