disable SafeBrowsing in Firefox 2.0.0.19+, alert users

VERIFIED FIXED

Status

()

Toolkit
Safe Browsing
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: beltzner, Assigned: dcamp)

Tracking

({verified1.8.1.19})

2.0 Branch
x86
Mac OS X
verified1.8.1.19
Points:
---
Bug Flags:
blocking1.8.1.19 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

2.33 KB, patch
mconnor
: review+
Samuel Sidler (old account; do not CC)
: approval1.8.1.19+
Details | Diff | Splinter Review
Google will be discontinuing the SafeBrowsing v1 service that's used on the branch. We need to:

 - turn it off by default and make the pref immutable (disable the option)
 - inform users that we are doing so and that they will no longer receive phishing protection

We can do the latter through a one-time dialog that's presented to users (maybe using the old EULA checking code?) who accept the minor update. We should also let users know that one of the reasons to update to Firefox 3 is to continue getting the SafeBrowsing protection.
Flags: blocking1.8.1.19+
Why are we doing this before EOL?
2.0.0.19 will be the last version before EOL. Not sure when else we'd do it.
If we turn this off can we delete the sqlite file and reclaim a significant amount of space for our users? I wouldn't want flipping the pref to automatically clear the DB because some users might flip it on and off, like maybe as part of some private browsing mode. But since this is pretty final getting the space back might be nice.
(Assignee)

Comment 4

9 years ago
We could start deleting it in future 3.x releases..
Who can own this? Code freeze is in one week on November 17.
Whiteboard: [needs owner]
Dave, Johnath: can one of you guys take this?
(Assignee)

Updated

9 years ago
Assignee: nobody → dcamp
Whiteboard: [needs owner]
(Assignee)

Comment 7

9 years ago
Is a simple confirm dialog (header/description, similar to the "restore session" dialog but with just an "ok") at startup, shown right after when the EULA would be presented) be good enough here?

Cc'ing Axel, as whatever we end up with here will presumably need to be translated..
I'd prefer to have a webpage load instead that told users that safebrowsing was off. We have a not-as-good chance of getting in-product localization finished than we do of getting webpage localization finished by release time and after. (i.e., we can update the web page as localizations are finished.)
(Assignee)

Comment 9

9 years ago
So is this something we could just include in the "you've updated firefox" page?  Would that be noticable enough?
(Assignee)

Comment 10

9 years ago
Created attachment 348105 [details] [diff] [review]
lock prefs
Attachment #348105 - Flags: review?
(Assignee)

Updated

9 years ago
Attachment #348105 - Flags: review? → review?(mconnor)

Updated

9 years ago
Attachment #348105 - Flags: review?(mconnor) → review+
(Assignee)

Updated

9 years ago
Attachment #348105 - Flags: approval1.8.1.19?
(In reply to comment #9)
> So is this something we could just include in the "you've updated firefox"
> page?  Would that be noticable enough?

With appropriate styling it probably could be - and that certainly scopes down the code impact of this patch.  But it means we need to file the bug tracking the web site change as well, unless "you've upgraded" pages have their own, non-bug process?  Beltzner?
We talked online and that's what we're going to do: make changes to the "you've been updated" page. l10n will have to update as well.

bug 464927 filed.
Why aren't we instead turning off the list updates rather than turning off protection 100% in one go? The problem is that we don't want to ping Google anymore, right? If we left the feature enabled but not pinging (which could also be a simple pref change) then we could tell people safebrowsing is no longer supported, and will degrade just as Firefox itself will (in terms of security). Otherwise we're saying it's no longer supported so boom, we're taking it away.

Comment 14

9 years ago
No list updates in 45 minutes implies that the feature is turned off. So basically, it would degrade over a period of 45 minutes.
(In reply to comment #14)
> No list updates in 45 minutes implies that the feature is turned off. So
> basically, it would degrade over a period of 45 minutes.

Really? And there's no UI to warn the user when safebrowsing was turning itself off (and on?)? It seems pretty ballsy to design a feature that assumes the server will never ever be unreachable for whatever reason.
(Assignee)

Comment 16

9 years ago
I think he's thinking about the 3.x feature - after 45 minutes without being able to contact the list server, we require a pingback request to verify matches (to avoid stale data from blocking sites entirely).  The 3.x feature is kinda dead in the water without an available pingback server anyway.

I am not aware of any freshness guarantee in the 2.x code, which is what this bug is about.

But leaving the old phishing db in place without updates would prevent a site from EVER being removed from the list.  It seems like that could be problematic (in the worst case, a user might have a false positive in the list before upgrading from 2.0.0.18, and it'll never be cleaned up)
(In reply to comment #16)
> But leaving the old phishing db in place without updates would prevent a site
> from EVER being removed from the list.  It seems like that could be problematic
> (in the worst case, a user might have a false positive in the list before
> upgrading from 2.0.0.18, and it'll never be cleaned up)

Sure, but how likely is that compared to getting phished? In that case there's an easy workaround: upgrade to Firefox 3 or turn off the feature yourself. But users do have the choice to click-through to the page and mutter at us.

If _we_ turn off the feature people are going to get phished, because I don't believe for a minute people are going to notice whatever we put on the "What's new" page so they will continue on with a false sense of security. In a way they will with the database degrading, but that's true when we publish the first security exploits fixed in Firefox 3.0.6 and not 2.0-anything, and there will be news about that release.
Comment on attachment 348105 [details] [diff] [review]
lock prefs

Approved for 1.8.1.19. a=ss for release-drivers

Dave, can you land this as soon as possible?
Attachment #348105 - Flags: approval1.8.1.19? → approval1.8.1.19+
(Assignee)

Comment 19

9 years ago
Checking in app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.71.2.85; previous revision: 1.71.2.84
done
Checking in components/safebrowsing/content/globalstore.js;
/cvsroot/mozilla/browser/components/safebrowsing/content/globalstore.js,v  <--  globalstore.js
new revision: 1.1.2.12; previous revision: 1.1.2.11
done
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: fixed1.8.1.19
Keywords: fixed1.8.1.19
Whiteboard: fixed1.8.1.19
Verified the changes in config with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19pre) Gecko/2008120103 BonEcho/2.0.0.19pre.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.19 → verified1.8.1.19
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.