Re: on HTTP/QUIC and HTTPBis

Yes, I think if we take the starting point that

* a company that is worried about cyber-slacking of employees
* a school worried about students surfing porn
* a mom and dad worried about their kids spending too much time watching 
minecraft videos on youtube

are going to block sites _no_matter_what_ we do, then we should make it 
possible to do this cleanly, and reliably without having to resort to 
nasty tricks.

Because if we don't allow people to block at protocol level, they will 
block at transport level, which will result in over-blocking, and very 
poor user experience.  It is not our place to say people should not 
block, and deny people the facility to do it properly, we are here and 
involved in protocol work for the people.  This includes people who need 
for completely legitimate reasons to block things.


------ Original Message ------
From: "Poul-Henning Kamp" <>
To: "Mike Bishop" <>
Cc: "Alex Rousskov" <>; "Patrick 
McManus" <>; "HTTP working group mailing list" 
Sent: 11/03/2017 8:07:29 PM
Subject: Re: on HTTP/QUIC and HTTPBis

>In message 
>>, Mike Bishop writes:
>>  I'm sympathetic to the lack of configured proxies' abilities to,
>>  with user/client awareness, monitor the contents of transactions
>>  which are otherwise encrypted and return meaningful errors.  I'm
>>  less sympathetic to middleboxes that act without client awareness
>>  or configuration.
>If so, wouldn't it make sense to proactively make it easier to
>roll out the former than the latter, rather than make it equally
>hard ?
>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 

Received on Sunday, 12 March 2017 21:33:27 UTC