Need UI for Anti-Malware Settings

VERIFIED FIXED in Firefox 3 beta1

Status

()

VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: cbook, Assigned: johnath)

Tracking

Trunk
Firefox 3 beta1
Points:
---
Bug Flags:
blocking-firefox3 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
With the integration of the malware protection in Firefox 3, we need also a UI (maybe like the Phishing Protection in Firefox 2) to control the malware protection (like to disable the malware protection, etc).

Since the malware protection connects to sb.google.com it could cause without a UI a lot of user questions like in Bug 397360
Flags: in-litmus?
Flags: blocking-firefox3?
Component: Phishing Protection → Preferences
QA Contact: phishing.protection → preferences
Litmus triage team: juanb will add test case in Litmus
Flags: blocking-firefox3? → blocking-firefox3+
Hmm, I think this is a string change to the existing phishing prefs.. Johnath?  I don't know if there's much gain to not having a single pref controlling the site checking, unless there's a reason to segment the behaviours...
Assignee: nobody → johnath
Target Milestone: --- → Firefox 3 M9
(Assignee)

Comment 3

11 years ago
(In reply to comment #2)
> Hmm, I think this is a string change to the existing phishing prefs.. Johnath? 
> I don't know if there's much gain to not having a single pref controlling the
> site checking, unless there's a reason to segment the behaviours...

Dave implemented the malware pref as a separate pref, browser.safebrowsing.malware.enabled.  I can think of reasons to segment, most notably the fact that we support alternate phishing list providers, so someone who really didn't trust google, for instance, might change their phishing provider, but be out of luck with malware unless they have an independent way to disable it.  There's also the whole "these do different things and should have different prefs" argument.  

On the other hand, the malware/blacklist protocol changes also killed the "real-time checking" mode for anti-phishing, right?  Where google gets pinged every time?  Because if so, we might want to a) add the malware tickbox above/below phishing, and b) ditch/rework the radio buttons.  That's a net reduction in pref UI, if so.
(Assignee)

Comment 4

11 years ago
(In reply to comment #3)

> On the other hand, the malware/blacklist protocol changes also killed the
> "real-time checking" mode for anti-phishing, right?  Where google gets pinged
> every time?  Because if so, we might want to a) add the malware tickbox
> above/below phishing, and b) ditch/rework the radio buttons.  That's a net
> reduction in pref UI, if so.

Actually, bug 388652 tracks the removal of that code, so the removal of the pref code should be part of that.  This bug should just track the original issue - adding ability to switch malware checking on/off
(Assignee)

Comment 5

11 years ago
Created attachment 284350 [details] [diff] [review]
Add an "attack site" checkbox in Security prefs

Add a checkbox for malware checking ("Attack Sites") alongside phishing pref.  As mentioned above, this will not include removal of the radio buttons under phishing, but there is another bug tracking removal of "active checking mode" support in general, already nom'd for blocking, so while this temporarily grows the size of the preferences page, we should get smaller in the long run.  

Also, because the malware code doesn't have the same multi-provider, active-checking, EULAs-needed extensibility, the pref code here doesn't hook into the more complicated code around the phishing pref stack below it - this is a straight boolean toggle of browser.safebrowsing.malware.enabled.
Attachment #284350 - Flags: ui-review?(beltzner)
(Assignee)

Comment 6

11 years ago
Comment on attachment 284350 [details] [diff] [review]
Add an "attack site" checkbox in Security prefs

beltzner reserves the right to take another look, so I'm not clearing the ui-r flag, but he's ok'd it to go to gavin for review.
Attachment #284350 - Flags: review?(gavin.sharp)
Comment on attachment 284350 [details] [diff] [review]
Add an "attack site" checkbox in Security prefs

>Index: locales/en-US/chrome/browser/preferences/security.dtd

> <!-- LOCALIZATION NOTE (tellMaybeForgery.label):

>+<!ENTITY  tellMaybeAttackSite.label     "Tell me if the site I'm visiting is a suspected attack site">
>+<!ENTITY  tellMaybeAttackSite.accesskey "k">

nit: Adding this here moves the l10n note away from the string it refers to, please add it somewhere else :)
Attachment #284350 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 8

11 years ago
Created attachment 284359 [details] [diff] [review]
Change localization note to reflect both strings

Rather than moving the strings, I've changed the localization note to more clearly apply to both strings (since the caution to use "suspected" language, not "known" language does indeed apply to malware as well).
Attachment #284350 - Attachment is obsolete: true
Attachment #284350 - Flags: ui-review?(beltzner)
is this ready for checkin?
(Assignee)

Comment 10

11 years ago
beltzner reserved the right to gripe about it one more time so I'll ping him this morning and then flag it.
(Assignee)

Comment 11

11 years ago
Let's land it.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Checking in browser/components/preferences/security.xul;
/cvsroot/mozilla/browser/components/preferences/security.xul,v  <--  security.xul
new revision: 1.20; previous revision: 1.19
done
Checking in browser/locales/en-US/chrome/browser/preferences/security.dtd;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/preferences/security.dtd,v  <--  security.dtd
new revision: 1.6; previous revision: 1.5
done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Version: unspecified → Trunk

Updated

11 years ago
Blocks: 399656
(Reporter)

Comment 13

11 years ago
Testcase added in Litmus -> setting "+" Flag
Flags: in-litmus? → in-litmus+
v. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007110610 Minefield/3.0a9pre
Status: RESOLVED → VERIFIED

Comment 15

11 years ago
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007112604 Minefield/3.0b2pre

If “Tell me if the site is a suspected forgery” is unchecked, the list/everytime radio button group is disabled. That has confused me even more about the unspecified (there) way of how the anti-malware feature works.

Comment 16

11 years ago
(In reply to comment #15)
> Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007112604
> Minefield/3.0b2pre
> 
> If “Tell me if the site is a suspected forgery” is unchecked, the
> list/everytime radio button group is disabled. That has confused me even more
> about the unspecified (there) way of how the anti-malware feature works.

I don't get it; what's confusing? 'suspected forgery' is the phishing protection, and 'suspected attack site' is the malware protection :)
(Assignee)

Comment 17

11 years ago
(In reply to comment #16)
> (In reply to comment #15)
> > Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007112604
> > Minefield/3.0b2pre
> > 
> > If “Tell me if the site is a suspected forgery” is unchecked, the
> > list/everytime radio button group is disabled. That has confused me even more
> > about the unspecified (there) way of how the anti-malware feature works.
> 
> I don't get it; what's confusing? 'suspected forgery' is the phishing
> protection, and 'suspected attack site' is the malware protection :)

FWIW, bug 388652 will remove support for active-mode checking, and with it, one presumes, this UI.
> FWIW, bug 388652 will remove support for active-mode checking, and with it, one
> presumes, this UI.
> 

hope that my ids don't wake me up by trying to connect to giigle

You need to log in before you can comment on or make changes to this bug.