Re: The future of forward proxy servers in an http/2 over TLS world

Hi Tom

the predominant use-cases are as follows.

1. A corporation, with many employees with computers and internet 
access.  The employer doesn't want the employees spending all day on 
facebook, youtube, or other sites, unless it's the customer-support / 
social media department.

2. A school which doesn't want students surfing porn

In all these cases, you have the issue of many computers, and a single 
policy.  To block in the browser requires several things, a centralised 
management of the policy, disseminated to the browserm some way of 
securing this so the users don't disable it etc.

If on the other hand you intercept outbound connections, and force them 
through a proxy, or require use of a proxy for internet access, you can 
enforce the policy in a place that's removed from the users.

Other features like a shared cache, AV scanning etc are also commonly 
used.

Also, there are products that provide categorization of sites.  If you 
wanted to allow all sites except porn sites, and to block that in a 
browser, you would need to know what all the porn sites are.

There are products that track this, but they are expensive, have a large 
resource footprint etc. You can't be running this on every endpoint.

So central control is required, and this is a proxy.

HTH

Adrien




------ Original Message ------
From: "Tom Bergan" <tombergan@chromium.org>
To: "Alex Rousskov" <rousskov@measurement-factory.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 17/02/2017 9:17:22 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>Ok, I see that I unintentionally stepped on a landmine. Sorry.
>
>On Thu, Feb 16, 2017 at 11:47 AM, Alex Rousskov 
><rousskov@measurement-factory.com> wrote:
>>On 02/16/2017 11:25 AM, Tom Bergan wrote:
>>
>> > You started by stating, without proof, that proxies are needed to 
>>block
>> > requests.
>>
>>Adrien did not state that at all! He actually stated that
>>
>>   * proxies are used to block requests;
>>   * blocking requests is a critical proxy purpose;
>>   * blocking by proxy becomes increasingly difficult or even 
>>impossible
>>     due to ongoing protocol changes
>>
>>All are well-known facts that do not require a proof, I hope.
>>
>>[ If you are implying that requests should never be blocked or should
>>only be blocked by user agents, then I hope that other folks on the
>>mailing list can prove you wrong without appearing to be as biased as 
>>a
>>proxy developer would. ]
>
>Yes, I'm asking why the blocking needs to happen in a proxy. For 
>example, Chrome's SafeBrowsing feature doesn't use a proxy. Your client 
>is a willing participant that will customize their software and 
>configuration as you ask them. Why does the protocol for deciding what 
>to block necessarily need to happen over a proxy, rather than a 
>side-channel? Maybe I'm being naive and don't know all the obvious 
>reasons why a proxy is needed and a side-channel won't work. Has 
>someone written an RFC describing why?