New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 150 users

Issue metadata

Status: Fixed
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 576708: Unable to download .zip,.exe,.com,.bat files through flash/flex using, defaultFilename)

Reported by, Jan 12 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Example URL:

Steps to reproduce the problem:
var f:URLRequest = new URLRequest("");
var fr:FileReference = new FileReference();, "");

What is the expected behavior?
File dialog should open to save file

What went wrong?
File dialog fails to open for files with extension of .zip, .exe, .com, .bat. All other tested extensions (.pdf, .txt, .htm etc) are fine.

Did this work before? Yes Previous version of Pepperflash

Chrome version: 47.0.2526.106  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 20.0 r0

Comment 1 by, Jan 12 2016

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

Comment 2 by, Jan 12 2016

Comment 3 by, Jan 12 2016

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 ?

Comment 4 by, Jan 12 2016

Labels: Cr-UI-Browser-Downloads

Comment 5 by, Jan 12 2016

Labels: Cr-UI-Browser-SafeBrowsing

Comment 6 by, Jan 12 2016

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

Comment 7 by, Jan 12 2016

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.

Comment 8 by, Jan 12 2016

Labels: Needs-Feedback
@ian.marett.find: Your proof of bug appears to require flash and not reference anywhere; is this specifically a problem with downloading from inside flash?

Comment 9 by, Jan 13 2016

As the title says: "Unable to download .zip,.exe,.com,.bat files through flash/flex", so yes, flash is required. 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.

Comment 10 by, Jan 13 2016

I tried to download with a diferent file name, by example... a "filename" 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(""); //NO PROBLEM
var fr:FileReference = new FileReference();, ""); //THE PROBLEM

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

Comment 11 by, Jan 13 2016

.xml is also not working.

Comment 12 by, Jan 13 2016

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.

Comment 13 by, Jan 13 2016

I also have pre-downloaded generated content from the server that I received in a previous request and i'm attempting to use the 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();"just good ole string content","");

Comment 14 by, Jan 14 2016

Labels: -Cr-Internals-Network

Comment 15 by, Jan 14 2016

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) {,'_blank');;


Comment 16 by, Jan 14 2016

e.g. flash"launchURL", URL); 

parent HTML page javascript:

function launchURL(url) {,'_blank');;

Comment 17 by, Jan 14 2016

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

Comment 18 by, Jan 14 2016

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

Comment 19 by, Jan 14 2016

Labels: Cr-Internals-Plugins-PDF

Comment 20 by, Jan 14 2016

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

Comment 21 by, Jan 14 2016

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

Comment 22 by, Jan 14 2016

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

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

Comment 23 by, Jan 14 2016

Status: Available

Comment 24 by, Jan 14 2016

Labels: -OS-Windows -Cr-UI-Browser-Downloads -Needs-Feedback -Cr-Internals-Plugins-PDF OS-All

Comment 25 by, Jan 15 2016

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.

Comment 26 by, Jan 15 2016

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

Comment 27 by, Jan 15 2016

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)?

Comment 28 by, Jan 15 2016

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.

Comment 29 by, Jan 15 2016

Our domain is 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.

Comment 30 by, Jan 15 2016

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.

Comment 31 by, Jan 15 2016

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.

Comment 32 by, Jan 15 2016

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

Comment 33 by, Jan 18 2016

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

Comment 34 by, Jan 19 2016

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. 

Comment 35 by, Jan 19 2016

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.

Comment 36 by, Jan 19 2016

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:

Comment 37 by, Jan 19 2016


Comment 38 by, Jan 20 2016

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)...

Comment 39 by, Jan 20 2016

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.

Comment 40 by, Jan 20 2016

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());
        throw new Error("Don't know how to save this kind of data!");"hst_saveFile", b64e.toString(), filename, mimetype);
    // workaround not required, proceed as usual
    // optionally, add action listeners here (or use a predefined FileReference instance)
    var fr:FileReference = new FileReference();, 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);;

Comment 41 Deleted

Comment 42 by, Jan 20 2016

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

Comment 43 Deleted

Comment 44 by, Jan 20 2016

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.)

Comment 45 Deleted

Comment 46 Deleted

Comment 47 by, Jan 21 2016

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;

Comment 48 by, Jan 21 2016

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.

Comment 49 by, Jan 21 2016

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.

Comment 50 by, Jan 25 2016

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.

Comment 51 by, Jan 26 2016

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

Comment 52 by, Jan 26 2016

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

Comment 53 by, Jan 27 2016

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

Comment 54 by, Jan 28 2016

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.

Comment 55 by, Jan 28 2016

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.

Comment 56 by, Jan 29 2016

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.

Comment 57 by, Feb 11 2016

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.

Comment 58 by, Apr 1 2016

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?

Comment 59 by, May 6 2016

Status: Assigned (was: Available)

Comment 60 by, May 6 2016

Labels: SafeBrowsing-Triaged

Comment 61 by, Jun 8 2016

Status: Fixed (was: Assigned)
This is fixed in M52.

Sign in to add a comment