Closed Bug 504804 Opened 10 years ago Closed 10 years ago

prefs cleanup and smarter integration with win policy settings

Categories

(Toolkit :: Downloads API, defect)

x86
Windows Vista
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: jimm, Assigned: jimm)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

We need to better respect various system level security and attachment handling policies on windows for downloading and scanning content. Some sort of nsIDownloadSystemSettings interface that handles querying the system and mozilla prefs would help isolate these decisions in a single location.

Prefs in this area can be confusing and in some cases have mixed meaning. Scrapping existing prefs for a new set that more clearly defines usage would help make this area of the code simpler to configure. Pushing some of these settings up to UI level may also be warranted. (virus scanning for example, should probably be an application level pref.)
Blocks: 499448
Blocks: 443215
It is important in particular that a user have the option of handling anything through the browser UI rather than system UI if that is their choice. Microsoft's system UI for dealing with these issues is difficult to work with and somewhat confusing. The choice should not be between using the system security or no security at all; a third choice to rely on the browser to handle these things is crucial.
(In reply to comment #1)
> It is important in particular that a user have the option of handling anything
> through the browser UI rather than system UI if that is their choice.
> Microsoft's system UI for dealing with these issues is difficult to work with
> and somewhat confusing. The choice should not be between using the system
> security or no security at all; a third choice to rely on the browser to handle
> these things is crucial.

If your suggesting that the browser ui control system settings, I disagree. But prefs will control how we interact with system resources, which is what we do now, we're just in need of some better organization on how we do it.
(In reply to comment #2)
> If your suggesting that the browser ui control system settings, I disagree. But
> prefs will control how we interact with system resources, which is what we do
> now, we're just in need of some better organization on how we do it.
I agree with this as well.
I don't mean the browser should control system settings, no, only that the user should have the option of using the browser UI instead of the system settings if they so choose. That is, if the user wants to rely on the group policy settings to set zone identifier information on downloaded files, that's fine, but if they want to simply be prompted at download time and not have zone identifier info set, that should be an option too. I don't mean to imply though that Firefox should have some sort of control over what the system's policy settings and such are, merely that power users should have the option of bypassing those settings completely.

My preferred behavior for a download for example is to warn me if it's going to open an .exe file directly after download, but otherwise to follow normal download behavior and never set zone identifier information at all. I've already changed my group policy settings so once the current bug regarding those is fixed that won't be such a big deal, but zone info is something I simply don't want to have to ever worry about period. So for me the choice is simple: Use the browser for security questions, skip the system UI.
This is how things stack up currently:

--

When a download completes:

if scanWhenDone=true or not present (default), call the scanner.

if scanWhenDone=false, skip scanning. (1)

state=DOWNLOAD_SCANNING:

if skipWinSecurityPolicyChecks=false or not present (default), call windows attachment manager. (group policy settings respected.) (2)

if skipWinSecurityPolicyChecks=true, do not call attachment manager. (group policy settings not applied.) (3)

state=DOWNLOAD_FINISHED:

if alertOnEXEOpen=true or not present (default) -> set security internet zone information on all downloads. (group policy settings related to prompting respected, attachment zone policy data rules not respected.) (4)

if alertOnEXEOpen=false -> do not modify zone information in downloads. (5)

downloads manager -> open file UI option:

if os is xpsp2 or greater, do not prompt natively. (group policy settings related to prompting respected.) (6)

if os is xpsp1 or less, and alertOnEXEOpen=true or not present (default), prompt natively. (ok)

if os is xpsp1 or less, and alertOnEXEOpen=false, do not prompt. (ok)

--

(1) is an issue in that applying group policy settings doesn't occur. We would have to manually parse policy settings and apply them on our own. I am not a huge fan of implementing this because it's such a nightmare. (http://support.microsoft.com/kb/883260)

(2) is the right config for most users, and the safest path through the code.

(4) Issue: applying zone info on all files.

(6) Some power users may want to force native prompting. 

--

I'm inclined to fix this by simplifying things, rather than making things more complex:

1) eliminate the skipWinSecurityPolicyChecks pref, and eliminate the use of the older virus scanning interface. Tie "scanWhenDone" to virus scanning and applying group policy settings through the windows attachment interface. We no longer support os <= XPSP1, so the new attachment interface can take complete responsibility for scanning/policy settings on downloaded content. (That's what it's there for.)

2) Remove alertOnEXEOpen checking in DOWNLOAD_FINISHED, and don't apply zone info to downloaded content.

3) In the download UI open attachment option:

a) if alertOnEXEOpen=false, don't prompt.

b) if alertOnEXEOpen=true, prompt.

c) if alertOnEXEOpen=not set (default) && scanWhenDone=false, prompt.

d) if alertOnEXEOpen=not set (default) && scanWhenDone=not set (default),
os>=xpsp2: don't prompt*
os<=xpsp1: prompt

*Most of our normal users who use the download manager to open content.

User's who download content to the desktop will by default get policy checks and virus scanning through the windows attachment manager, unless they disable it with scanWhenDone. In which case they are taking security matters into their own hands.

Pre xpsp2 this would turn off internal virus scanning, but generally scanners these days do network level / file level scans, so I'm thinking the risks there are small.
(In reply to comment #5)
> 1) eliminate the skipWinSecurityPolicyChecks pref, and eliminate the use of the
> older virus scanning interface. Tie "scanWhenDone" to virus scanning and
> applying group policy settings through the windows attachment interface. We no
> longer support os <= XPSP1, so the new attachment interface can take complete
> responsibility for scanning/policy settings on downloaded content. (That's what
> it's there for.)
agree

> 2) Remove alertOnEXEOpen checking in DOWNLOAD_FINISHED, and don't apply zone
> info to downloaded content.
Would we never apply zone info then?

When you say native prompt, do you mean Firefox is doing the prompting?
(In reply to comment #6)
> (In reply to comment #5)
> > 1) eliminate the skipWinSecurityPolicyChecks pref, and eliminate the use of the
> > older virus scanning interface. Tie "scanWhenDone" to virus scanning and
> > applying group policy settings through the windows attachment interface. We no
> > longer support os <= XPSP1, so the new attachment interface can take complete
> > responsibility for scanning/policy settings on downloaded content. (That's what
> > it's there for.)
> agree
> 
> > 2) Remove alertOnEXEOpen checking in DOWNLOAD_FINISHED, and don't apply zone
> > info to downloaded content.
> Would we never apply zone info then?
> 
> When you say native prompt, do you mean Firefox is doing the prompting?

Yeah, native = internal. Sorry for the confusion.

I've run into one minor problem, alertOnExeOpen is set for every download when the user selects open. So there's no "not set" default, so I need to come up with something else there.
Ok, this actually works out pretty well. Once we remove the old virus scanner interface, scanWhenDone ties directly to enabling / disabling windows prompting. So - 

os >= xpsp2:
a) scanWhenDone=true, don't prompt.
b) scanWhenDone=false, fall back on alertOnExeOpen 

os <= xpsp1:
fall back on alertOnExeOpen

and skipWinSecurityPolicyChecks goes away completely.
Attachment #392306 - Flags: review?(tellrob)
> os >= xpsp2:
> a) scanWhenDone=true, don't prompt.
> b) scanWhenDone=false, fall back on alertOnExeOpen 
> 
> os <= xpsp1:
> fall back on alertOnExeOpen
> 
> and skipWinSecurityPolicyChecks goes away completely.

One update, since our system info property bag doesn't have minor version info, this is split between vista and xp rather than the service packs.
Comment on attachment 392306 [details] [diff] [review]
scanner changes v.1

Looks good. My only question is why we predicate the native security prompt on Vista or above? Doesn't XP SP2 have the prompt too?
Attachment #392306 - Flags: review?(tellrob) → review+
(In reply to comment #12)
> (From update of attachment 392306 [details] [diff] [review])
> Looks good. My only question is why we predicate the native security prompt on
> Vista or above? Doesn't XP SP2 have the prompt too?

Our system info property bag which relies on nspr for information can't differentiate between the two. I suppose we could try and add support for that, but I'd rather split that off as another bug and not hold this.
Attachment #392306 - Flags: superreview?(sdwilsh)
Comment on attachment 392306 [details] [diff] [review]
scanner changes v.1

r=sdwilsh
Attachment #392306 - Flags: superreview?(sdwilsh) → review+
Blocks: 509713
http://hg.mozilla.org/mozilla-central/rev/7124d9e94924
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: dev-doc-needed
Resolution: --- → FIXED
Fixed it might be - but not for me. I tried various combinations of registry and Firefox settings, but see absolutely no way to get rid of the 100% useless security warnings. A proper "how to", please?

Best
Otto
Are you running the latest development build, Otto, or just an official release? I'm still on release 3.5.2 and this bug fix came after that, so I'm sure we should see the change in 3.5.3. I agree a full how-to document on these settings would be helpful though.
I have 3.5.2, too, LummoxJR. So I'll wait for 3.5.3 and hope that I don't miss a necessary setting. I think exactly the same about warnings as you: Warn before immediate start of an exe, but no zone identifiers.
Target Milestone: --- → mozilla1.9.2a1
After reading the patch and comparing stuff against the docs we already have here:

https://developer.mozilla.org/en/Download_Manager_preferences

I see nothing in this patch that actually requires any changes to developer documentation whatsoever. Can someone elaborate on what might have changed that needs to be written about here?

Also, I'm told there are currently no plans to take this for any 1.9.1 release, so you guys hoping to see this in 3.5.3 need to talk to someone. :)
(In reply to comment #19)
> After reading the patch and comparing stuff against the docs we already have
> here:
> 
> https://developer.mozilla.org/en/Download_Manager_preferences
> 
> I see nothing in this patch that actually requires any changes to developer
> documentation whatsoever. Can someone elaborate on what might have changed that
> needs to be written about here?
> 
> Also, I'm told there are currently no plans to take this for any 1.9.1 release,
> so you guys hoping to see this in 3.5.3 need to talk to someone. :)

Those docs look good, although you can remove 

browser.download.antivirus.dontclean

which was depreciated in 3.5.
Of course the description of the DM-parameters is fine. What I think would be useful for many people are step by step instructions to get rid of warning messages that were not there a few monthos ago, do only two things: Annoy, and teach us to click them away as quickly as possible. Without reading. That does not increase security, just as too many traffic signs don't help to drive safely. I am just a user, and I am really really unhappy if I have to search the internet for an hour to find experimantal receipes just to get back to the state where we were before making everything ..."better". I's not about experts, it is about users with little to no knowledge of firefox details, who otherwise know what they are doing.

Cheers
Otto
OK, that kind of how-to guide is not developer documentation, so I'm removing the dev-doc-needed keyword from this and adding user-doc-needed instead.
(In reply to comment #19)
> Also, I'm told there are currently no plans to take this for any 1.9.1 release,
> so you guys hoping to see this in 3.5.3 need to talk to someone. :)

We need this in 3.5.3 because of the fix to bug 499448, in which all downloads are erroneously tagged with zone.identifier information regardless of policy settings or file extension. If the fix to 499448 can go into 3.5.3 alone, that's fine too, but having all downloads so tagged has been a nightmare.
(In reply to comment #23)
> (In reply to comment #19)
> > Also, I'm told there are currently no plans to take this for any 1.9.1 release,
> > so you guys hoping to see this in 3.5.3 need to talk to someone. :)
> 
> We need this in 3.5.3 because of the fix to bug 499448, in which all downloads
> are erroneously tagged with zone.identifier information regardless of policy
> settings or file extension. If the fix to 499448 can go into 3.5.3 alone,
> that's fine too, but having all downloads so tagged has been a nightmare.

I really do not feel comfortable pushing this patch out to 3.5. There are other factors here behind the scenes that must be considered, specifically the anti-virus vendors who come to understand what interfaces our software makes use of in major releases. Changing that type of functionality in a point release is not a good idea. However I'd be ok with a patch for a point release of 3.5.3 that addresses the specific problem of applying zone-info to non-executable content.
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #19)
> > > Also, I'm told there are currently no plans to take this for any 1.9.1 release,
> > > so you guys hoping to see this in 3.5.3 need to talk to someone. :)
> > 
> > We need this in 3.5.3 because of the fix to bug 499448, in which all downloads
> > are erroneously tagged with zone.identifier information regardless of policy
> > settings or file extension. If the fix to 499448 can go into 3.5.3 alone,
> > that's fine too, but having all downloads so tagged has been a nightmare.
> 
> I really do not feel comfortable pushing this patch out to 3.5. There are other
> factors here behind the scenes that must be considered, specifically the
> anti-virus vendors who come to understand what interfaces our software makes
> use of in major releases. Changing that type of functionality in a point
> release is not a good idea. However I'd be ok with a patch for a point release
> of 3.5.3 that addresses the specific problem of applying zone-info to
> non-executable content.

err - "a point release of 3.5" not 3.5.3.

We should probably move the discussion into a new bug.  499448 deals with applying zone settings independent of policy settings, that is in fact fixed and we are not going to get a full fix for that into 3.5. So maybe addressing the zone info on non-exe content might suffice for those having issues with it?
(In reply to comment #25)
> We should probably move the discussion into a new bug.  499448 deals with
> applying zone settings independent of policy settings, that is in fact fixed
> and we are not going to get a full fix for that into 3.5. So maybe addressing
> the zone info on non-exe content might suffice for those having issues with it?

I'm not sure I understand what you mean. It isn't really just a matter of exe vs. non-exe, since if zone.identifier information is used at all it should be looking at the policy settings, which was the behavior in 3.0 that worked. Since my policy settings say not to apply this tag on any downloads, that's what should be happening. Going back to that correct behavior should be a simple matter, independent of any of these preference settings that, understandably, can wait for a future release. I could live with a patch that looked at exe vs. non-exe, though.
I'm just going through user-doc-needed bugs. What exactly is the how-to guide for?
(In reply to comment #27)
> I'm just going through user-doc-needed bugs. What exactly is the how-to guide
> for?

There's not much to it really.

To enable prompting and to scan, you set the following pref:

browser.download.manager.scanWhenDone = true

Power users and admins can set this and leverage group policy settings for fine grained control over prompting behavior. (this addresses bug 499448) Average users get typical windows security prompts. This is the default.

Power users who want to disable all prompting for downloads (and by default, disable virus scanning) should set scanWhenDone to false.

The "browser.download.manager.alertOnEXEOpen" pref is largely obsolete, although it still controls Fx internal prompting for exes that are opened through the download manager, on older operating systems (os < xpsp2) that don't support the windows attachment manager.
The aforementioned patch to address bug 499448 did not make it into the 3.5.4 release. Is there any status update on that?
Okay, then I'm removing user-doc-needed.
In general, we don't instruct users to use about:config, unless its for troubleshooting. For more info, see <https://support.mozilla.com/en-US/kb/Knowledge+Base+Policies>.
Keywords: user-doc-needed
Blocks: 531234
I can not believe it, you did it again!!! 

This totally spoils Firefox for me and a lot of other users. It was already a pain in the *** the set the "skipWinSecurityPolicyChecks" Parameter, because it was default that FF honors those Windows-Security-Zones ****, but now you just removed it and there is no choice any more. The only solution for FF 3.6 according to the Knowledge Base is to set the Internet Zone Security slider from "High" to "Medium High"! Heelllooo, is there anybody home? There were reasons (which i will not explain over and over again) why i set it to "High" and setting it to a lower level is definitely not acceptable!!!

In the end here is whats happening: I do not trust IE so i set Internet Zone to "High", but since FF also honors that setting and i HAVE to set it to "medium" i can not trust FF also any more. And yes, i know that this may not be a totally convincing line of reasoning, that is to what it boils down to for me any many of my friends.

If this procedure stays in its bye bye to FF.
(In reply to comment #31)
> This totally spoils Firefox for me and a lot of other users. It was already a
> pain in the *** the set the "skipWinSecurityPolicyChecks" Parameter, because it
> was default that FF honors those Windows-Security-Zones Crap, but now you just
> removed it and there is no choice any more. The only solution for FF 3.6
> according to the Knowledge Base is to set the Internet Zone Security slider
> from "High" to "Medium High"

(For the record)
The KB article that mentions that solution is:
http://kb.mozillazine.org/Unable_to_save_or_download_files#Bypass_Windows_Security_Policy_check

The corresponding SUMO article and section is:
http://support.mozilla.com/en-US/kb/Unable+to+download+or+save+files#Bypass_Windows_Security_Policy_check
(In reply to comment #32)
> (In reply to comment #31)
> > This totally spoils Firefox for me and a lot of other users. It was already a
> > pain in the *** the set the "skipWinSecurityPolicyChecks" Parameter, because it
> > was default that FF honors those Windows-Security-Zones Crap, but now you just
> > removed it and there is no choice any more. The only solution for FF 3.6
> > according to the Knowledge Base is to set the Internet Zone Security slider
> > from "High" to "Medium High"
> 
> (For the record)
> The KB article that mentions that solution is:
> http://kb.mozillazine.org/Unable_to_save_or_download_files#Bypass_Windows_Security_Policy_check
> 
> The corresponding SUMO article and section is:
> http://support.mozilla.com/en-US/kb/Unable+to+download+or+save+files#Bypass_Windows_Security_Policy_check

(In reply to comment #31)
> I can not believe it, you did it again!!! 
> 
> This totally spoils Firefox for me and a lot of other users. It was already a
> pain in the *** the set the "skipWinSecurityPolicyChecks" Parameter, because it
> was default that FF honors those Windows-Security-Zones Crap, but now you just
> removed it and there is no choice any more. The only solution for FF 3.6
> according to the Knowledge Base is to set the Internet Zone Security slider
> from "High" to "Medium High"! Heelllooo, is there anybody home? There were
> reasons (which i will not explain over and over again) why i set it to "High"
> and setting it to a lower level is definitely not acceptable!!!
> 
> In the end here is whats happening: I do not trust IE so i set Internet Zone to
> "High", but since FF also honors that setting and i HAVE to set it to "medium"
> i can not trust FF also any more. And yes, i know that this may not be a
> totally convincing line of reasoning, that is to what it boils down to for me
> any many of my friends.
> 
> If this procedure stays in its bye bye to FF.

Disable scanning, and Fx should behave the way you want it to. See comment 28.
Ok, tracked this down. See bug 445158. The original goal was to turn off all the prompting, which we did. But we still check local security policy when the download starts. So to address, even if you have security policy on ie set to high, would be to enable the download pref in internet security options. We still honor that.
I think it would be ok to tie the security policy check to the scanWhenDone pref. Since corp environs have the ability to lock prefs if they want to, we might as well give users the ability to override all download security settings on the local machine. scanWhenDone isn't a perfectly named pref for doing this, but since windows only provides us with a single all-in-one api call, which includes scanning and policy enforcement, we might as well tie policy settings checks to that as well. I'll post a patch here.
Attachment #430318 - Flags: review?(sdwilsh)
(In reply to comment #31)
> The only solution for FF 3.6
> according to the Knowledge Base is to set the Internet Zone Security slider
> from "High" to "Medium High"! Heelllooo, is there anybody home? There were
> reasons (which i will not explain over and over again) why i set it to "High"
> and setting it to a lower level is definitely not acceptable!!!
> If this procedure stays in its bye bye to FF.

(In reply to comment #34)
> Ok, tracked this down. See bug 445158. The original goal was to turn off all
> the prompting, which we did. But we still check local security policy when the
> download starts. So to address, even if you have security policy on ie set to
> high, would be to enable the download pref in internet security options. We
> still honor that.

If Internet zone security is set to 'High', you can customize those settings by changing the single option,  "Launching Applications and Unsafe Files" from 'Disable' to 'Prompt (recommended)' and this will enable executable file downloads in Firefox.  I've edited http://kb.mozillazine.org/Unable_to_save_or_download_files#Reset_system_Internet_security_settings_-_Windows to add that method.
Comment on attachment 430318 [details] [diff] [review]
check policy patch

nit: brace the one line if please

r=sdwilsh
Attachment #430318 - Flags: review?(sdwilsh) → review+
Comment on attachment 430318 [details] [diff] [review]
check policy patch

requesting point release approval - it'd be nice if we could get this in so users who want to disable all windows security zone related settings for downloads can do so in 3.6.
Attachment #430318 - Flags: approval1.9.2.2?
(In reply to comment #38)
> (From update of attachment 430318 [details] [diff] [review])
> nit: brace the one line if please
> 
> r=sdwilsh

http://hg.mozilla.org/mozilla-central/rev/28e3a378126d
Attachment #430318 - Flags: approval1.9.2.2? → approval1.9.2.3?
> If Internet zone security is set to 'High', you can customize those settings by
> changing the single option,  "Launching Applications and Unsafe Files" from
> 'Disable' to 'Prompt (recommended)' and this will enable executable file
> downloads in Firefox.  I've edited
> http://kb.mozillazine.org/Unable_to_save_or_download_files#Reset_system_Internet_security_settings_-_Windows
> to add that method.

I appreciate trying to help, but the point is that i am sick of setting single options here and other options there. The problem with it is that after some time one can not reliably track those changes in the system any more. You end up with a 40 pages document where you record all the nifty little changes to a dozen or more programs in your system, which effectively you have to check from time to time. For example, in the Windows Zone Info Dialog it will only say "Custom" Level, but you never know if is only the setting i have changed some time ago, or if some **** other software messed with the settings. Sorry, but this is absolutely no way to go!

Please make an option within FF where i can decide if i want to honor the Windows Security Zones or not. There is no other way!
(In reply to comment #41)
> Please make an option within FF where i can decide if i want to honor the
> Windows Security Zones or not. There is no other way!
We've already made this decision, and the answer is no.
(In reply to comment #42)
> (In reply to comment #41)
> > Please make an option within FF where i can decide if i want to honor the
> > Windows Security Zones or not. There is no other way!
> We've already made this decision, and the answer is no.

Related bug:
Bug 509713 -  Add a UI pref tied to vista attachment manager use (virus scanning, zone policy)
Blocks: 569204
Comment on attachment 430318 [details] [diff] [review]
check policy patch

Clearing old approval requests now that 1.9.2.4 has shipped. If you believe this patch is still necessary on the 1.9.2 branch please re-request approval along with a risk/benefit analysis explaining why we need it.
Attachment #430318 - Flags: approval1.9.2.4?
Depends on: 760889
You need to log in before you can comment on or make changes to this bug.