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

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Hammer]

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

Comment 1

[Tony Chang (Google)]

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.

Comment 2

[Tony Chang (Google)]

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

Comment 3

[[:mmc] Monica Chew (no longer reading bugmail)]

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.

Comment 4

[Tony Chang (Google)]

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

Comment 5

[[:mmc] Monica Chew (no longer reading bugmail)]

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

Comment 6

[Tony Chang (Google)]

on trunk

Comment 7

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

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.

Comment 8

[Tony Chang (Google)]

on branch