Closed Bug 345675 Opened 19 years ago Closed 19 years ago

unwanted connection to www.google.com at startup with Safe Browsing disabled

Categories

(Toolkit :: Safe Browsing, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2 beta2

People

(Reporter: bugsy, Assigned: tony)

Details

(Keywords: fixed1.8.1, privacy)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721 BonEcho/2.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721 BonEcho/2.0b1 Bon Echo creates connections to www.google.com despite Safe Browsing being switched off. Reproducible: Always Steps to Reproduce: 1. Switch off /everything/ in Bon Echo that could possibly have a valid reason for creating a connection to www.google.com, such as various updates and Safe Browsing 2. Start sniffing outgoing packets 3. Start Bon Echo Actual Results: Bon Echo creates connections to www.google.com Expected Results: Nothing http://forums.mozillazine.org/viewtopic.php?t=442207
Flags: blocking-firefox2?
As the forum mentions, this is from getting keys (the keyURL in prefs). Yeah, this is a bug. It shouldn't request the key unless we actually need it.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: nobody → tony
Status: ASSIGNED → NEW
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: --- → Firefox 2 beta2
Keywords: privacy
Disables all table updates in advanced mode since other providers shouldn't be using google's tables (doesn't really make sense).
Attachment #230470 - Flags: review?(mmchew)
These changes look fine to me. Would it make more sense to remove the side-effects of getKeyURL so that it doesn't make a getkey request? Getting rid of the whitelist optimization is a little unfortunate -- I wish we had numbers on how often that optimization got triggered.
(In reply to comment #3) > Would it make more sense to remove the > side-effects of getKeyURL so that it doesn't make a getkey request? We could, but it's unclear to me when the right time is to get the key. If we wait until we need it (i.e., to encrypt a url before doing a remote lookup), then there's going to be a lag as we wait for the key to arrive. That's the only reason to prefer the eager fetch. Suggestions? > Getting rid of the whitelist optimization is a little unfortunate -- I wish we > had numbers on how often that optimization got triggered. Yeah, this may come back if support for other data providers with local list checking comes back.
Attachment #230470 - Flags: review?(mmchew) → review+
(In reply to comment #4) > (In reply to comment #3) > > Would it make more sense to remove the > > side-effects of getKeyURL so that it doesn't make a getkey request? > > We could, but it's unclear to me when the right time is to get the key. If we > wait until we need it (i.e., to encrypt a url before doing a remote lookup), > then there's going to be a lag as we wait for the key to arrive. That's the > only reason to prefer the eager fetch. > > Suggestions? The eager fetch is fine -- I was just thinking it might be easier to read if the getkey request were a separate call from setKeyURL.
Attachment #230470 - Flags: superreview?(bryner)
Attachment #230470 - Flags: superreview?(bryner) → superreview+
on trunk
Attachment #230470 - Flags: approval1.8.1?
Comment on attachment 230470 [details] [diff] [review] v1: don't get key if off, don't get whitelist tables if enhanced a=drivers. Please land this on the MOZILLA_1_8_BRANCH.
Attachment #230470 - Flags: approval1.8.1? → approval1.8.1+
on branch
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: