[Nottingham] How ISP shenanigans hampers your browsing experience.

[Michael Quaintance]

On Tue, Jan 6, 2015 at 1:51 AM, Mike Cardwell <nlug at lists.grepular.com> wrote:
> My understanding is that HTTP/2 is basically going to be what SPDY is
> and that SPDY is simply a transitional protocol whilst people figure out
> what works in the real World. Is that wrong?

I don't think that's wrong and I'm only in favour of HTTP/2 ahead of
SPDY because I prefer a protocol maintained by an independent body to
one maintained by a corporation. There's a lot to be said in favour of
Google proving that it works and ironing out the major kinks to speed
adoption, but with Google controlling some of the biggest web
properties, and browser, and OS, and mobile ecosystem, etc... we're
actually much more at risk of the antitrust stuff that got Microsoft
in trouble in the 90s. Having the standard in the hands of the IETF
(despite their faults) is an improvement in my eyes.

> If a website is slow, it is almost always because of the application, not
> the encryption.

Absolutely 100% agree. It's even almost as true to say "if a website
is insecure, it is almost always because of the application, not the
encryption." (with a few notable counter-examples)

> I think the point is that in the not too distant future, if you visit a
> website over HTTPS, then you'll probably be using SPDY/HTTPv2, but if
> you visit one over HTTP you'll be stuck on HTTPv1, without all the nice
> pipelining and compression stuff [1]. So, although it is not strictly a
> "HTTP vs HTTPS" test, it *is* a test comparing what you will see in the
> real World when visiting a HTTP website vs what you will see when visiting
> an average HTTPS website once SPDY/HTTPv2 gain traction [2].

Not really, simply because the sticking plasters that are used today
to improve performance of high-traffic HTTP/1.1 sites will likely
still work and still be used when SPDY or HTTP/2 are more prevalent.
The test ignores these which downplays the speed of the HTTP part of
the test. Certainly, HTTPS sites will not be significantly slower and
will likely be a little to a lot faster.

> [1] Although HTTPv2 is allowed to work over non-SSL connections, Mozilla
> and Google at least have said that they'll only do it over HTTPS. I assume
> because of compatibility problems with transparent proxies. Ultimately,
> HTTPS will be faster than HTTP because of this.

Yes, this a purely technical problem that will hopefully leave
HTTP/1.1 behind and boost HTTPS-everywhere. If you run SPDY with
unencrypted HTTP, you basically need a new port number and that's a
rabbit hole of a problem.

> [2] It shouldn't take long for SPDY/HTTPv2 to become the majority of
> HTTPS traffic. All it requires is for admins to upgrade their web servers
> and for people to upgrade their web browsers.

"People to upgrade their web browsers" was the fatal flaw in any web
innovation not so long ago, but with auto updates of Chrome, Firefox,
Safari, etc that's not such a problem any more.

What I'm not seeing in the real world but I did predict some time ago
(and could still happen) is traffic shaping to slow encrypted traffic
so as to hide the DPI on unencrypted traffic and possibly even to
hamper HTTPS solely to put people off using it.

-Michael