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?