SSL Google Search by Default
For users that have logged into their Google account, Google is planning to secure their web search requests and search results pages by encrypting their transmission.
http://googleblog.blogspot.com/2011/10/making-search-more-secure.html
http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=173733&topic=1678515
The url www.google.com (http://www.google.com) should soon redirect to encrypted.google.com (https://encrypted.google.com). To obtain unencrypted access, you may use the url nosslsearch.google.com (http://nosslsearch.google.com).
Accessing a site from an unsecured Google results page can reveal your search query. Accessing a site from an organic search result on a secured Google results page should not reveal your search query. Accessing a site from an advertisement on a secured Google results page may reveal your search query.
Isn't this hypocritical? |
It's ALL stupid because when you click on a link in the SERPs, you don't go directly to the website, you do a hit on a HTTP Google page that redirects you to the final page. A *HTTP GOOGLE PAGE", so anyone sniffing the packets in the network will know what was your query, your parameters and the page you will visit.
===> STUPID. |
Hey Tom, browsers don't pass referrers for links that go from HTTPS to HTTP, so going from a HTTPS search result to a HTTP interstitial would not forward the referrer.
"Clients SHOULD NOT include a Referer[sic] header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol." – http://tools.ietf.org/html/rfc2616#section-15.1.3
One way to test this is to use a tool like Wireshark to monitor your traffic while you use https-enabled web-search. |
John, I know all about that. Anyway, there is a HUGE difference here:
Google HTTPS->Google HTTPS->example.com in HTTP.
==> that's the way Google do with https://encrypted.google.com, here there is NO referrer between Google and example.com. (There are two "Google HTTPS" because the link in the SERP is not directly a link to the result, because Google has to track each click).
But in https://WWW.google.com this behaviour has changed:
Google HTTPS->Google HTTP->example.com in HTTP.
==> Google redirection page is in HTTP. It's where they remove the "q=" parameter, then it redirects to the result page. Anyway, this page is in HTTP so everyone sniffing the traffic in HTTP can discover a lot of information in the redirection page. Except the query, which was removed recently, my bad for previous comment.
Anyway, if Google removes the query it's entirely because they want, not because of any technical constraint. And it's a bad thing, according to me. |
(both links in previous comment are prefixed by "httpS ://", be careful!) |
Hi Tom
Yes, this change is not being done for technical reasons. The http-interstitial is primarily there so that at least a Google-referrer (showing that the user came from our site). I don't think there's much in that interstitial URL that could be of interest for people sniffing the traffic – or is there a part in the interstitial URL which you're worried about which we could change?
|
You are right, I thought there was some user ID in the interstitial page, but there is not (except ?ei= and ?usg= that I don't know what they are for, perhaps they are hash to protect malicious usages of 'google.com/url?url='). By the way, as the referer is still passed between two HTTP sites, you can set the interstitial page in HTTPS. In that way, the user never leaves the secured mode.
Anyway, I still don't understand why you remove the "q=" parameter. There are 4 categories of people:
- People who don't even know they can be "tracked", so the "q=" is not a real problem
- People who don't care about being tracked, so the "q=" is OK for them
- People who don't want to be tracked, but they are tracked anyway because we can know they come from google.com thanks to the referrer, Google Analytics give us more data and server logs can even give us the public IP of the user.
- People who only care about DPI: I understand why they feel happy with Google HTTPS but are they afraid with the "q=" parameter? I don't think so.
So, I don't understand Google's policy here. And I'm not the lone. |
