User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5 When downloading and saving files, in Firefox 3.5 builds, Zone.Identifier information is saved regardless of policy setting. It appears that the policy setting is not respected. This is new behavior in Firefox 3.5 as Firefox 3.0 did not save information when policy is configured not to. Reproducible: Always Steps to Reproduce: 1. Download and save any file. Does not need to be exe. (Save Page As... invokes behavior) Actual Results: In Windows Explorer, after browsing to download location (or choosing Open Containing Folder from context menu of downloaded item), check file properties. Has security notice saying file came from another computer and might be blocked to protect computer. Expected Results: No saved Zone.Identifier information. Information for system settings to not preserve information. Policy Location: User Configuration\Administrative Templates\Windows Components\Attachment Manager\Do not preserve zone information in file attachments Setting: Enabled Registry Location: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments\SaveZoneInformation Value: 1 Platform: Windows XP Service Pack 3

This has existed since at least 3.1b3 and I can confirm still exists in 3.5rc2, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 Any chance of this being fixed for the next release?

I am experiencing this problem as well, now in the official release of Firefox 3.5. Not only are executable files tagged with zone information, but low risk files such as .jpg images as well (not even IE does that). Is Mozilla addressing this issue?

There is a workaround for this issue that involves editing your preferences in about:config. First, change the value for browser.download.manager.scanWhenDone to false. Next, add a new boolean preference named browser.download.manager.skipWinSecurityPolicyChecks and set its value to true. Finally, create another boolean preference named browser.download.manager.alertOnEXEOpen and set it to false. These three need to be in effect before the Zone.Identifier information is no longer saved with the file.

Thanks for the workaround. In my testing only browser.download.manager.alertOnEXEOpen needs to be set to false to correct this issue. browser.download.manager.skipWinSecurityPolicyChecks overrides the "Launching applications and unsafe files" setting in Windows Internet Options, which is handy but does not appear necessary for preventing Zone.Identifier information from being saved. browser.download.manager.scanWhenDone also does not appear to affect Zone.Identifier information in Firefox 3.5. Since this setting disables antivirus scanning on downloaded files, I'm leaving it enabled. I'd still like to see Mozilla honor Windows' SaveZoneInformation setting, but this workaround appears effective.

True enough, I've downloaded a portable version of Firefox 3.5 from PortableApps.com and tried only modifying browser.download.manager.alertOnEXEOpen and the warnings disappeared, however if I revert browser.download.manager.scanWhenDone and browser.download.manager.skipWinSecurityPolicyChecks on my locally installed Firefox the Zone.Identifier information persisted on all other file types but EXE. To be fair I have heavily modified my about:config so I'm sure it's just an isolated incident. Thanks for checking it out, at least everyone can leave antivirus scanning turned on. (In reply to comment #5) > Thanks for the workaround. In my testing only > browser.download.manager.alertOnEXEOpen needs to be set to false to correct > this issue. browser.download.manager.skipWinSecurityPolicyChecks overrides the > "Launching applications and unsafe files" setting in Windows Internet Options, > which is handy but does not appear necessary for preventing Zone.Identifier > information from being saved. browser.download.manager.scanWhenDone also does > not appear to affect Zone.Identifier information in Firefox 3.5. Since this > setting disables antivirus scanning on downloaded files, I'm leaving it > enabled. > > I'd still like to see Mozilla honor Windows' SaveZoneInformation setting, but > this workaround appears effective.

How come this is still "unconfirmed"... there are loads of people complaining, just search the web for "Security warning firefox". In any case: I had never edited my about:config, and still, i had to change all three properties above to stop the saving of zone information.

Probably a lot of people are not finding this bug report when they come across the problem. I found it very difficult when I upgraded to Firefox 3.0 to find out why it was suddenly giving me "The publisher could not be verified" when it never did before. Through a lot of research I learned how to edit my group policy settings, but Firefox 3.5 now sets the zone information for every file no matter what the group policy says. Now every single file Firefox 3.5 downloads says the pubisher could not be verified. Because people don't know what to search for, they aren't finding this issue and voting it up. Until and unless they do, I think we'll be stuck with this bug for a while. I only found this issue myself by persistent searching. As far as I'm concerned though, this is two bugs. One is that Firefox should have an option to skip the group policy security checks entirely. I don't see why anyone other than a die-hard Explorer fan would want that check in the first place, and even so they're not the ones using Firefox. The other is that the browser should actually obey those settings if it uses them at all. This bug really needs to be fixed ASAP; the workaround is too detrimental to security.

This is still happening in firefox-3.6a1pre.en-US.win32.installer.

Ugh. This was apparently a "feature" put in place by another developer. https://bugzilla.mozilla.org/show_bug.cgi?id=426544 According to Jim Mathies, alertOnEXEOpen is now meant to control whether security zone info is added to files. Problems with this: 1) Nobody thought to include a setting to disable this behavior apart from alertOnEXEOpen; it seems like a bad idea to disable that particular setting. 2) Setting zone identifier information on all files rather than just ones Windows' group policy dictates is a very very bad idea.

(In reply to comment #10) > Ugh. This was apparently a "feature" put in place by another developer. > > https://bugzilla.mozilla.org/show_bug.cgi?id=426544 > > According to Jim Mathies, alertOnEXEOpen is now meant to control whether > security zone info is added to files. Problems with this: 1) Nobody thought to > include a setting to disable this behavior apart from alertOnEXEOpen; it seems > like a bad idea to disable that particular setting. alertOnEXEOpen is really obsolete since the native OS handles prompting when executing downloaded files which makes the Fx dialog redundant. If the os prompts, why is disabling this a "bad" idea? > 2) Setting zone identifier > information on all files rather than just ones Windows' group policy dictates > is a very very bad idea. If you think they way we choose which files to add zone information to is flawed, please post a new bug and cc me on it.

(In reply to comment #11) > > 2) Setting zone identifier > > information on all files rather than just ones Windows' group policy dictates > > is a very very bad idea. > > If you think they way we choose which files to add zone information to is > flawed, please post a new bug and cc me on it. Doh! This is the new bug! :)

So generally the complaint here is that we are not honoring the group policy settings related to inserting zone information on attachments - we do a blanket insert on downloaded content. This we can address. A little background, the Fx open content prompt is considered obsolete on windows version that support native prompting. The alertonexeopen pref was meant as an override of normal (safe) prompting for os's that support native prompting and those that don't. In download manager when files are saved out, alertonexeopen can disable prompting (zone info being written) on downloaded content. For the special case where the user tries to open content from the download manager UI, we shunt the native Fx dialog to off for win versions that support native prompting since the download manager code is handling the decision when saving out the content.

If the group policy settings are respected then at least that addresses the bug part. However I think getting rid of alertOnEXEOpen is a mistake, because native prompting is not something everybody wants. I'm only concerned about an EXE launching unbidden directly from the browser, not opening it myself manually by double-clicking it in the file folder where I downloaded it. When I upgraded to Firefox 3.0 I specifically altered my group policy settings to avoid having to "unblock" EXEs when I ran them manually after a download. If users want that feature, that's fine, but they should have an alternative if they don't. In short, the browser should not assume that zone identifier information is enough to keep an end user safe. Many Firefox 3.0 users altered their group policy settings to avoid this hassle. I think ideal behavior is that if a downloaded EXE is saved without such information (due to policy or browser settings) and does not trigger native prompting, the old alertOnEXEOpen behavior should be used. What I would like, and I think this sentiment is widely shared, is a way to turn off the zone identifier information entirely no matter what the group policy settings are. The browser.download.manager.skipWinSecurityChecks setting appears to not exist in Firefox 3.5 and has to be added manually. This bug seems to bypass it, but maybe once it's fixed that won't be an issue. If that setting is still used, though, it should be part of the standard config so users can find it.

(In reply to comment #14) > If the group policy settings are respected then at least that addresses the bug > In short, the browser should not assume that zone identifier information is > enough to keep an end user safe. This relates more to the judgment made related to relying on the OS vs. implementing features internally and the redundancy the internal feature would create. cc'ing dveditz for his opinion. > Many Firefox 3.0 users altered their group > policy settings to avoid this hassle. I think ideal behavior is that if a > downloaded EXE is saved without such information (due to policy or browser > settings) and does not trigger native prompting, the old alertOnEXEOpen > behavior should be used. In general, most users will want virus scanning, policy checks and zone meta data so the preferences are configured to support by default that type of configuration. (A configuration that we should consider as being the most secure.) Power users on the other hand can use these preferences to customize how downloads get handled. Modifying group policy settings is definitely a power user type thing to do IMHO. Better documentation on these prefs though might be a good idea. > What I would like, and I think this sentiment is widely shared, is a way to > turn off the zone identifier information entirely no matter what the group > policy settings are. The browser.download.manager.skipWinSecurityChecks setting > appears to not exist in Firefox 3.5 and has to be added manually. This bug > seems to bypass it, but maybe once it's fixed that won't be an issue. If that > setting is still used, though, it should be part of the standard config so > users can find it. The skipWinSecurityPolicyChecks does confuse the issue somewhat. It's a switch that controls what API we use to invoke 3rd party virus scanners. Without it, we fall back on an older interface. With it set to true (or without it being present) we use a newer api that handles policy checks, virus scanning, and adding zone meta data. The zone meta data code in download manager was fall back in cases where virus scanning was manually turned off but prompting was still desired. I will look into filtering different attachment types based on group policy settings. By default though we should be honoring any settings related to this since Windows is handling applying the meta data. I will have to do some testing to see if that is in fact the case.

Interesting, Chrome has an open bug that's identical to this one. I wonder if they are relying on the same attachment execute api or manually doing a blanket application of zone data. http://code.google.com/p/chromium/issues/detail?id=5719

> In general, most users will want virus scanning, policy checks and zone meta > data so the preferences are configured to support by default that type of > configuration. (A configuration that we should consider as being the most > secure.) Power users on the other hand can use these preferences to customize > how downloads get handled. Modifying group policy settings is definitely a > power user type thing to do IMHO. Better documentation on these prefs though > might be a good idea. Zone information has been nothing but a pain for me; Windows has no convenient mechanism for dealing with it such as removing it from several files at once. But I don't begrudge it to those who want it. My main concern is that the browser should be able to 1) not set zone information if that's what the user wants, and 2) offer the user some form of optional warning before launching an EXE in the event that zone info is not set for any reason (including group policy).

Until this is fixed, download "streams.exe" by Mark Russinovich http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx Run "streams -d *.*" against all downloads. Not sure how to automate this yet but it works.

fixed by the patch in bug 504804.