3 ms·

I wonder if the lack of HTTPS during normal browsing is a deliberate choice (one motivated by testing) or if it's only like that out of legacy (preservation of

I wonder if the lack of HTTPS during normal browsing is a deliberate choice (one motivated by testing) or if it's only like that out of legacy (preservation of URLs). It's difficult to imagine all of the possible issues they may know about that we don't, given their scale. The author mentions that removing the ref parameter would be a solution to one of the problems discussed in the article but I put forward that they could also just encrypt the value for transmission and store the information in plain on the backend. If they won't move to HTTPS then that should solve at least one of the issues.

diziet 12y ago
I would imagine they ran the A/B tests on 99th percentile metrics and also on consumer behavior and decided that having the HTTPS enabled by default would result in less revenue/growth/etc I'd imagine with the number of requests they make to various analytics, internal services etc it is not a super simple migration.
- tombrossman 12y ago
  Old discussion here on HN, but the claim is made that every 100ms latency cost 1% in profit: https://news.ycombinator.com/item?id=273900 https://news.ycombinator.com/item?id=273900 HTTPS is pretty fast now with SPDY (and soon HTTP/2) but there is no avoiding the fact that is slows down that first page load ever so slightly. No doubt they have studied this carefully and opted for maximum speed, as this maximizes income.
- yandie 12y ago
  No. The reason Amazon is not on HTTPS yet is because not all parts of the system are ready. I believe the company will finish the transition in June
- DeuceDaily 12y ago
  My wild guess is processing costs. With the amount of traffic they see, encrypting every page of every item someone looks at could potentially be very costly.
  - harshreality 12y ago
    Can that concern be quantified? Properly implemented (without extra-large DH parameters [no 3072 or 4096 bit params for EDH if your RSA key is 2048 bits], using ECDHE preferentially, and with a sufficient SSL session cache), extra processing should be minimal. Didn't Google quote something like low single digits? 3%? Of course, Google did a lot of work on optimizing their SSL layer, including pushing for higher initial window sizes in linux's tcp stack, and their work on SSL false start even though they later abandoned it. For organizations that are doing SSL termination on their frontend webservers, it depends on their traffic flow: what percentage of page hits are new vs already established ssl sessions that can hit the cache. Different kinds of sites are going to have different traffic mixes that will affect that cost. Does Amazon use the google strategy of software SSL termination, or do they use hardware like F5 terminators? Either way, they already have some ssl termination capability, since the secure parts of their website rely on it, so it's only a matter of beefing up existing capability rather than implementing it from zero. They may already have a lot of excess SSL termination capacity that they're not using. If SSL everywhere always costs a company money, why did Google switch so early? I think there are benefits that at least partially compensate for increased infrastructure costs. I think it's more likely that embedded resources from non-ssl external pages are blocking SSL deployment. Or Amazon has a bunch of hardcoded http://www.amazon.com http://www.amazon.com links in different parts of their codebase, that have to be tracked down and fixed. Mixed content is what I think is blocking ssl deployment on most sites. Small sites that have switched to SSL-everywhere often haven't spent the time to do it right, and whether because their software has hardcoded http embedded links, or they're linking content from other sites, mixed content warnings are common. (Protip: //domain/path [without the initial http or https] is a protocol-relative link, if you need to link to a different host but keep the protocol the same)
    - DeuceDaily 11y ago
      Low single digit could easily be viewed as significant. Given this scenario, it would be easy to guess google wasn't basing their decision entirely off cost. You'd have no real idea in either case unless you were involved in the decision making.

diziet 12y ago

I would imagine they ran the A/B tests on 99th percentile metrics and also on consumer behavior and decided that having the HTTPS enabled by default would result in less revenue/growth/etc I'd imagine with the number of requests they make to various analytics, internal services etc it is not a super simple migration.

tombrossman 12y ago
Old discussion here on HN, but the claim is made that every 100ms latency cost 1% in profit: https://news.ycombinator.com/item?id=273900 https://news.ycombinator.com/item?id=273900 HTTPS is pretty fast now with SPDY (and soon HTTP/2) but there is no avoiding the fact that is slows down that first page load ever so slightly. No doubt they have studied this carefully and opted for maximum speed, as this maximizes income.
yandie 12y ago
No. The reason Amazon is not on HTTPS yet is because not all parts of the system are ready. I believe the company will finish the transition in June
DeuceDaily 12y ago
My wild guess is processing costs. With the amount of traffic they see, encrypting every page of every item someone looks at could potentially be very costly.
- harshreality 12y ago
  Can that concern be quantified? Properly implemented (without extra-large DH parameters [no 3072 or 4096 bit params for EDH if your RSA key is 2048 bits], using ECDHE preferentially, and with a sufficient SSL session cache), extra processing should be minimal. Didn't Google quote something like low single digits? 3%? Of course, Google did a lot of work on optimizing their SSL layer, including pushing for higher initial window sizes in linux's tcp stack, and their work on SSL false start even though they later abandoned it. For organizations that are doing SSL termination on their frontend webservers, it depends on their traffic flow: what percentage of page hits are new vs already established ssl sessions that can hit the cache. Different kinds of sites are going to have different traffic mixes that will affect that cost. Does Amazon use the google strategy of software SSL termination, or do they use hardware like F5 terminators? Either way, they already have some ssl termination capability, since the secure parts of their website rely on it, so it's only a matter of beefing up existing capability rather than implementing it from zero. They may already have a lot of excess SSL termination capacity that they're not using. If SSL everywhere always costs a company money, why did Google switch so early? I think there are benefits that at least partially compensate for increased infrastructure costs. I think it's more likely that embedded resources from non-ssl external pages are blocking SSL deployment. Or Amazon has a bunch of hardcoded http://www.amazon.com http://www.amazon.com links in different parts of their codebase, that have to be tracked down and fixed. Mixed content is what I think is blocking ssl deployment on most sites. Small sites that have switched to SSL-everywhere often haven't spent the time to do it right, and whether because their software has hardcoded http embedded links, or they're linking content from other sites, mixed content warnings are common. (Protip: //domain/path [without the initial http or https] is a protocol-relative link, if you need to link to a different host but keep the protocol the same)
  - DeuceDaily 11y ago
    Low single digit could easily be viewed as significant. Given this scenario, it would be easy to guess google wasn't basing their decision entirely off cost. You'd have no real idea in either case unless you were involved in the decision making.