463347 - disable SafeBrowsing in Firefox 2.0.0.19+, alert users

Status: VERIFIED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 1

[Reed Loden [:reed]]

Why are we doing this before EOL?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

2.0.0.19 will be the last version before EOL. Not sure when else we'd do it.

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[Dave Camp (:dcamp)]

We could start deleting it in future 3.x releases..

Comment 5

[Samuel Sidler (old account; do not CC)]

Who can own this? Code freeze is in one week on November 17.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Dave, Johnath: can one of you guys take this?

Comment 7

[Dave Camp (:dcamp)]

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

Comment 8

[Samuel Sidler (old account; do not CC)]

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

Comment 9

[Dave Camp (:dcamp)]

So is this something we could just include in the "you've updated firefox" page?  Would that be noticable enough?

Comment 10

[Dave Camp (:dcamp)]

Attachment: lock prefs

Comment 11

[Johnathan Nightingale [:johnath]]

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

Comment 12

[Samuel Sidler (old account; do not CC)]

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.

Comment 13

[Daniel Veditz [:dveditz]]

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

[Ian Fette (Google)]

No list updates in 45 minutes implies that the feature is turned off. So basically, it would degrade over a period of 45 minutes.

Comment 15

[Daniel Veditz [:dveditz]]

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

Comment 16

[Dave Camp (:dcamp)]

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)

Comment 17

[Daniel Veditz [:dveditz]]

(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 18

[Samuel Sidler (old account; do not CC)]

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?

Comment 19

[Dave Camp (:dcamp)]

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

Comment 20

[Al Billings [:abillings - ex-MoCo]]

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.