- From: Mike Belshe <mike@belshe.com>
- Date: Wed, 28 Mar 2012 15:30:29 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: patrick mcmanus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
- Message-ID: <CABaLYCvguj3oycrv7uGKnMK_3fUYBU02JA=eH_W_F-w=fH7Rqg@mail.gmail.com>
On Wed, Mar 28, 2012 at 3:14 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message <4F72FD22.3020106@mozilla.com>, patrick mcmanus writes: > > >I disagree pretty strongly that confidentiality is not a core desirable > >property for the web. > > As is kittens, pink ponies and world peace. > > However, in real life all things come at a price, and the price > of confidentiality is too high for certain classes of websites. > > >The notion that consumers of adult content don't care that their > >activities are broadcasts in detail to their friends and family is > >bizarre to me. > > I'm sure pornsites are willing to offer enhanced service for a > price, if there is a market, in fact I will absolutely guarantee > you that they will be the first to make money out of "nobody can > see you surf porn" if there is a market. > > > And just to be sure we're not talking past each other here: > > There are two costs of TLS: CPU cycles and latency. > Thats the whole point of SPDY - we just handed you a protocol which embeds SSL but is still has lower latency than HTTP. > Many sites will object to both of these, but most seem to focus > on the CPU cycles. > > These are cheap and getting cheaper every day. > Latency is much more damaging, not so much for big sites like > Google, Yahoo and FaceBook which have data centers through out > the world, but for sites with just one webserver somewhere on > the world, the difference between 1*RTT and 4*RTT is a lot of > latency to throw at the user. > The higher the RTT, the bigger the win for SPDY. So this claim is just false. Mike > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Received on Wednesday, 28 March 2012 13:31:01 UTC