Re: HTTP 2.0 mandatory security vs. Amateur Radio

Le Ven 15 novembre 2013 18:31, Roberto Peon a écrit :

> That leaves us with either using a new port (infeasible, failure rate
> still
> in high 10%s) or doing something else so as to be able to deploy.
> What is the something else would you suggest?

I'm not convinced at all using a new port is infeasible. Yes, it would be
devilishly hard for a new corner-case protocol. But the web as a whole is
something else entirely and a new way to access it won't be dismissed so
easily. Of course adoption would take years, you don't replace billions of
web equipments that easily, but it would happen anyway.

That is, provided the protocol actually brings enough on the table to
justify the pain.

For example bittorent provided value for pirates and Linux users and they
authorised in on their equipments. It didn't provide value to anyone else
and was blocked elsewhere.

Websocket, I'm sorry to say, does not bring any value. Its main purpose is
to help developers force the passage of protocols people already blocked,
so of course people will block websockets too (notwithstanding what
websocket developers wish)

So what does the http/2 draft propose today?

1. better latency: that will give you mobile users, gamers and traders
(through web services)

2. encryption: I'm sorry that's an antifeature for all average users.
Encryption is a PITA to use and deploy, it kills caching, it kills
interop, it doesn't remove monitoring by web giants or the NSA, CA
security is questioned, people by and large do not care if most of their
traffic is observed, and you're proposing tanks to access cardboard houses
(most web sites are not ironclad and won't be in the future). Case in
point: ipsec market failure, social network successes.

3. server push: again, an antifeature. People are already bombarded by
advertisements and other stuff they didn't request.

4. new web applications? Who cares, they don't exist now. By all means
enable them but the only thing that will sell your protocol is making
better what people already know and want

And that's all. That's pretty thin to justify the pain if you're not a
mobile operator or a privacy zealot. In fact I suspect it's a net loss so
far. So I'd suggest you need to work more on your sales argument instead
of trying to force people to adopt something they don't need through
technical trickery. It's not as if there are no easy wins out there:

1. caching: http/1 caching is byzantine and not that efficient. You have
ideas on the subject? Wonderful! Everyone loves smaller download times and
less bandwidth use.

2. compression: surely in the past decade the state of the art improved
enough you can add better compression engines as option in http/2?
Terrific! again, everyone loves less bandwidth use (but make it possible
to optionnaly inhibit it for people with CPU constrains)

3. cookies: magnificent! the wg didn't want to discuss this but EU
legislation shows demand exists to fix the cookie hell, and web sites
operators would rather pass their time elsewhere than operating cookie

4. intermediaries: fix intermediary deployment problems (in particular
paygates) and you fix the hotel/airport/metro station/convention/guest
user situation. Extraordinary! Many people would kill to avoid paying xG
bills when data networks are available, and resort operators only want to
keep away external network leeches.

And there are probably others I forget. Remember, web infrastructure as a
whole represents an heavy investment by many actors. http has been static
for a decade and that's a net plus for most users. Everyone but developers
hates technical change. You need to put a lot on the table to convince
network operators to let you pass. And you need to present it in a single
package "please pay for new equipments and BTW I'll introduce another
change next year so be prepared for another bill" is *not* a seller. So
putting away problems to look at in another revision is not the way to go.


Nicolas Mailhot

Received on Friday, 15 November 2013 20:07:04 UTC