Wouldn't this suggestion make HTTPS search useless since the search term could then be sniffed from the GET request of the link the user clicks?
I think that Google should just track it internally and report it in Analytics. It would allow the publisher to do search analytics, and it would be good for the user too because it provides more privacy than the referrer field.
If somebody can sniff the HTTP traffic of a website you're visiting, that seems to be a much bigger issue than them being able to see what the search term you googled for was.
The ideal scenario would be for both google and the website you're visiting to be SSL protected. That way you can see the referer, but nobody can sniff any of the information.
It's usually pretty easy to see what website somebody is visiting over a HTTPS connection purely because you can only host one website per IP/Port combination (I'm ignoring SNI because pretty much nobody uses it yet)
HTTPS is slower, though; Google has been pounding into our heads for the past year that any milliseconds you can shave off your load time will result in significant improvements in page views and time spent on a site. I don't see this ever happening, although I do hope that the SPDY protocol (or something similar) becomes the standard one day, as it's both secure and fast.
The performance difference between https and http depends on a ton of factors. The reason you don't see a performance difference between these two requests is most likely because:
-Google's servers are big enough they can easily handle the extra load of encryption without breaking a sweat
-One of the many factors that makes SSL slower is that assets will not be cached in a shared cached (e.g. a proxy server), and will also not be cached in a browser beyond a single session (usually). So, stylesheets, javascripts, and images, must be downloaded to the browser much more often.
Note that your wget test completely ignores this last point, because it is not trying to cache anything for either https or http.
Regarding your second point. I'd be interested to see figures for how many web requests globally are fulfilled by a shared cache. My gut feeling is that it is a very small proportion of the total.
Yeah, I'd be interested too. Though, entire web requests wouldn't be fulfilled by a shared cache, just cached assets with proper Expires headers, such as javascripts, stylesheets, etc.
I actually wouldn't be incredibly surprised to learn that shared caches in proxy servers are quite efficient at serving cached content. If you think about it, it's in internet providers' best interest to make their proxy servers good at caching, because it would allow them to provide more content to their customers with less bandwidth, which of course affects their bottom-line.
SNI is currently supported by about 50% of browsers in the wild. The vast majority of the non-supporting population are IE users on XP or earlier.
Since there's almost no chance that Microsoft will ever update XP, we'll probably have to wait for years until we start hitting useful numbers like 90%+ :(
SSL is not the only way that by which google hides referer from google. For sometime I was seeing urls like http://www.google.com/#q=searchterm
Even this will hide queryTerm from websites.
As long SSL doesn't work with name based virtual hosting (another thing where IE6 is holding us back apparently), the authors wish of people switching to SSL all over the place is a pipe-dream - even more so now that we are really running out of IP addresses.
I don't know the completely accurate numbers, but I really doubt that there are still enough IP addresses left for all the Host:-header based sites to get their own IP to be able to use SSL
13 comments
[ 4.1 ms ] story [ 48.1 ms ] threadI think that Google should just track it internally and report it in Analytics. It would allow the publisher to do search analytics, and it would be good for the user too because it provides more privacy than the referrer field.
The ideal scenario would be for both google and the website you're visiting to be SSL protected. That way you can see the referer, but nobody can sniff any of the information.
It's usually pretty easy to see what website somebody is visiting over a HTTPS connection purely because you can only host one website per IP/Port combination (I'm ignoring SNI because pretty much nobody uses it yet)
time wget -q -O /dev/null http://www.google.com/
time wget -q -O /dev/null https://www.google.com/
There is no obvious difference in time taken to serve those requests.
Obviously there is an overhead, but to me it seems insignificantly small in comparison to the overall request.
I bet 99% of websites out there could convert to SSL, and then pull back the performance lost by just doing a little site optimisation.
-Google's servers are big enough they can easily handle the extra load of encryption without breaking a sweat
-One of the many factors that makes SSL slower is that assets will not be cached in a shared cached (e.g. a proxy server), and will also not be cached in a browser beyond a single session (usually). So, stylesheets, javascripts, and images, must be downloaded to the browser much more often.
Note that your wget test completely ignores this last point, because it is not trying to cache anything for either https or http.
I actually wouldn't be incredibly surprised to learn that shared caches in proxy servers are quite efficient at serving cached content. If you think about it, it's in internet providers' best interest to make their proxy servers good at caching, because it would allow them to provide more content to their customers with less bandwidth, which of course affects their bottom-line.
Since there's almost no chance that Microsoft will ever update XP, we'll probably have to wait for years until we start hitting useful numbers like 90%+ :(
I don't know the completely accurate numbers, but I really doubt that there are still enough IP addresses left for all the Host:-header based sites to get their own IP to be able to use SSL