Closed Bug 345675 Opened 17 years ago Closed 17 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: 17 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.