803970 - No packets should be sent to search providers when search suggestions are disabled, not even to establish a connection

Status: RESOLVED WONTFIX

(Firefox :: Search, defect)

Description

[FireFoxF4n]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010144125

Steps to reproduce:

I type in the search box at the top right.


Actual results:

Data is send to Google servers, for instance to muc03s01-in-f18.1e100.net.


Expected results:

No connection to Google servers should be established UNTIL the search is submitted with ENTER key because "search suggestions" is turned off.

If I switch to Bing as search provider no data is send while typing so it seems that only the search with Google ignores the "Show search suggestions" checkbox....

This is IMHO a privacy issue since the user expects that nothing is send until he submits the query. For example sometimes you accidentally copy something from the clipboard into that field and while you recognize the error the possible sensitive data is already sent to Google server.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

It's possible that you're seeing the effect of bug 735543? In that case, though, it should also affect Bing equally.

Comment 2

[FireFoxF4n]

I don't think this ticket is related because when I switch to Bing then
no connection is opened while (starting) typing.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Bug 735543 only causes a connection to be created when the search bar is focused. After switching to bing, did you refocus the search bar?

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Drew, can you investigate?

Comment 5

[Drew Willcoxon :adw]

I can't reproduce.  I:

1. Created a new Firefox profile.
2. Started Firefox, clicked the search box dropdown, clicked Manage Search
   Engines, unchecked Show search suggestions.
3. Restarted Firefox.
4. Started Wireshark.
5. Focused the Firefox search box by hitting Cmd+K.  (Google is the selected
   engine.)
6. Typed some characters.

On step 5, I did see a TLS handshake (with www.google.com, not one of their 1e100.net servers), which is the expected behavior due to the aforementioned bug 735543.

And as expected I did see traffic after I checked Show search suggestions and repeated the process (but again with www.google.com).

I also tried with Bing selected, and on step 5 I saw an http connection opened to a weirdo akamai.net server.

FireFoxF4n, are you sure you aren't just seeing the TLS handshake?  If so, what method are you using to watch the traffic?  Could you describe the nature of the packets you're seeing?  Are you using an add-on that might be causing the problem?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/19.0 Firefox/19.0
19.0a1 (2012-10-31)

Comment 6

[Drew Willcoxon :adw]

I should have read comment 0 more closely.

(In reply to FireFoxF4n from comment #0)
> Actual results:
> 
> Data is send to Google servers, for instance to muc03s01-in-f18.1e100.net.
> 
> Expected results:
> 
> No connection to Google servers should be established...

FireFoxF4n, it sounds like you're saying two different things: (1) "data" (by which you mean the characters you type in the search box, I presume) is sent, which shouldn't happen, and (2) a connection is established, which also shouldn't happen.

#1 shouldn't happen, right.  #2 should happen -- at least it's by design.  If by "data" you mean the packets that are sent to establish the connection, then you're only saying #2.

Comment 7

[FireFoxF4n]

@DrewWillcoxon

Ok so I actually don't know if only a connection is established without
sending something while typing. But if #2 should happen by design,
why does it not happen when Bing is used?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to FireFoxF4n from comment #7)
> But if #2 should happen by design, why does it not happen when Bing is used?

One possibility is that Google uses https://, while Bing uses http://. Our "speculative connect" code does different things in those two scenarios, which might explain why you see different network traffic.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Patrick McManus also points out that state matters: if there is already an open connection for a host, the speculative connection won't occur. So that's something to keep in mind when testing this.

Comment 10

[Drew Willcoxon :adw]

Like I said in comment 5, it does happen with Bing.

I'm changing the bug summary to better reflect the problem.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(In reply to Drew Willcoxon :adw from comment #10)
> Like I said in comment 5, it does happen with Bing.

But not for FireFoxF4n, apparently, so I was just trying to enumerate the reasons he might see different behavior (I don't know how he's monitoring network traffic exactly).

As newly summarized, I think this bug is probably WONTFIX. There are performance benefits to pre-connecting that aren't really related to search suggestions. That being said, the privacy implications are real, so it would make sense to hook this into the pref that I suggested creating in bug 790882 comment 22.

Comment 12

[FireFoxF4n]

I used the Resourcemonitor which is part of Windows 7/8.

Resourcemonitor can be launched via the Task-Manager
and then there is a section for Network Connections
which you can filter by Application.

I reproduced this behavior several times.
Bing: No connection
Google: Connection when I start typing

Thanks for investigating and changing to a proper bug title!

Comment 13

[:Gavin Sharp [email: [e-mail]]]

As summarized, I'm going to WONTFIX this. We are not sending any data to the search providers when suggestions are disabled, we're merely establishing a speculative connection to reduce latency, on the possibility that we eventually will be connecting to them (once you perform the search). See bug 814169 for a related discussion.

Comment 14

[Sid]

FWIW Chrome has an option to disable TCP pre-connections. If this is the case, we should have such an option too.

http://code.google.com/p/chromium/issues/detail?id=116982#c4

Comment 15

[Sid]

Sorry, missed the bug. :(

Comment 18

[Bruno Prémont]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #13)
> As summarized, I'm going to WONTFIX this. We are not sending any
> data to the search providers when suggestions are disabled, we're
> merely establishing a speculative connection to reduce latency, on
> the possibility that we eventually will be connecting to them (once
> you perform the search). See bug 814169 for a related discussion.

The mere fact of moving focus from one input field to the next one using keyboard (tab or shift+tab) will trigger the speculative connection.

A 5 seconds lifetime of the speculative connection is rather short for the case of search with suggestions disabled.

For the fact of not sending any data, with TLS and SNI this might be circumventable with placeholders in the engine URL's hostname (not tested).

So speculation should only happen on first character input, if at all or when suggestions are to be requested.

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Waiting for the first character negates the performance benefit entirely - at that point we're sending the actual request.

We connect to the same host name as the engine's main search URL, and search engines cannot specify separate URLs to preload, so apart from doing sophisticated (and likely unreliable) traffic analysis, search providers can't distinguish these pre-requests from normal requests. Not to mention that the "user typing in the search bar with search suggestions disabled and without then triggering a search" is an incredibly rare edge case, and detecting it doesn't really have any value to anyone.