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.
Why are we doing this before EOL?
126.96.36.199 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.
We could start deleting it in future 3.x releases..
Who can own this? Code freeze is in one week on November 17.
Dave, Johnath: can one of you guys take this?
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.)
So is this something we could just include in the "you've updated firefox" page? Would that be noticable enough?
(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.
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.
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 188.8.131.52, 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 184.108.40.206, 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 220.127.116.11. a=ss for release-drivers Dave, can you land this as soon as possible?
Checking in app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 18.104.22.168; previous revision: 22.214.171.124 done Checking in components/safebrowsing/content/globalstore.js; /cvsroot/mozilla/browser/components/safebrowsing/content/globalstore.js,v <-- globalstore.js new revision: 126.96.36.199; previous revision: 188.8.131.52 done
Verified the changes in config with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2008120103 BonEcho/220.127.116.11pre.