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

RESOLVED FIXED in Firefox 2 beta2

Status

()

Toolkit
Safe Browsing
RESOLVED FIXED
12 years ago
4 years ago

People

(Reporter: Hammer, Assigned: Tony Chang (Google))

Tracking

({fixed1.8.1, privacy})

unspecified
Firefox 2 beta2
x86
Windows XP
fixed1.8.1, privacy
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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
(Reporter)

Updated

12 years ago
Flags: blocking-firefox2?
(Assignee)

Comment 1

12 years ago
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)

Updated

12 years ago
Assignee: nobody → tony
Status: ASSIGNED → NEW
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: --- → Firefox 2 beta2

Updated

12 years ago
Keywords: privacy
(Assignee)

Comment 2

12 years ago
Created attachment 230470 [details] [diff] [review]
v1: don't get key if off, don't get whitelist tables if enhanced

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

Comment 4

12 years ago
(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.
(Assignee)

Updated

12 years ago
Attachment #230470 - Flags: superreview?(bryner)
Attachment #230470 - Flags: superreview?(bryner) → superreview+
(Assignee)

Comment 6

12 years ago
on trunk
(Assignee)

Updated

12 years ago
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+
(Assignee)

Comment 8

12 years ago
on branch
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.