5 ms·

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 G

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.

mike-cardwell 16y ago
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)
- sounddust 16y ago
  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.
  - mike-cardwell 16y ago
    I've never found that argument very convincing. I just sat here and ran the following two commands a bunch of times: time wget -q -O /dev/null http://www.google.com/ http://www.google.com/ time wget -q -O /dev/null https://www.google.com/ 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.
    - JangoSteve 16y ago
      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.
      - mike-cardwell 16y ago
        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.
        JangoSteve 16y ago
        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.
  - agl 16y ago
    We (Google) are working hard to reduce the round trips needed for SSL/TLS. We hope to be publishing several draft specs in the next couple of months.
- agl 16y ago
  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%+ :(
  - mike-cardwell 16y ago
    Can you name any websites which have deployed SNI?
  - mike-cardwell 16y ago
    For that matter, does Googles bot support websites which use SNI?

mike-cardwell 16y ago

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)

sounddust 16y ago
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.
- mike-cardwell 16y ago
  I've never found that argument very convincing. I just sat here and ran the following two commands a bunch of times: time wget -q -O /dev/null http://www.google.com/ http://www.google.com/ time wget -q -O /dev/null https://www.google.com/ 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.
  - JangoSteve 16y ago
    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.
    - mike-cardwell 16y ago
      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.
      - JangoSteve 16y ago
        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.
- agl 16y ago
  We (Google) are working hard to reduce the round trips needed for SSL/TLS. We hope to be publishing several draft specs in the next couple of months.
agl 16y ago
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%+ :(
- mike-cardwell 16y ago
  Can you name any websites which have deployed SNI?
- mike-cardwell 16y ago
  For that matter, does Googles bot support websites which use SNI?