Re: Fwd: New Version Notification for draft-nottingham-http-proxy-problem-01.txt

On Tue, Jul 15, 2014 at 4:40 AM, Poul-Henning Kamp <>

> In message <>, Mark
> Nottingham wri
> tes:
> >> A new version of I-D, draft-nottingham-http-proxy-problem-01.txt
> In 2.4 I think you should mention that content filtering is
> explicitly mandated by law in various jurisdictions.
> That doesn't make it any less controversial of course, quite the
> contrary, but mentioning it would make it clear that there some
> level of support will happen, no matter what.
> Under 5.4 you should probably add "... unless made illegal by a
> legitimate authority" to clarify the extent of our reach.
> I think it is unwise to lump header-modifications with "2.4 Content
> Modifications".  Modifying an Accept-Bla header, in order to make
> filtering easier, is not nearly as controversial as tacking advertising
> onto webpages.
> Otherwise it's a good summary of the situation.
> I would like to propose a section 6.8:
> 6.8  content-privacy with (some) visible meta-data
>     A lot of filtering proxies care only about restricting access
>     to particular sites or to particular paths under those sites.
>     Today they handle privacy protected access one of two ways.
>     Simpler proxies will resolve the CONNECT argument and compare
>     it to a white- or black-list of IP numbers, and allow or deny
>     access whole-sale to filtered IP numbers.   This causes rather
>     dramatic over-reach when one user on a web portal posts content
>     which causes the entire portal to be blacklisted.
>     More comprehensive proxies deploy man-in-the-middle certificates
>     to its clients (via out-of-band methods) and demasks all
>     privacy protected transactions in order to be able to inspect them,
>     gaining as a side effect also the ability to modify them.
>     Very little actual privacy would be lost if a minimum of
>     meta-data, specifically the URL less the query part, were
>     transmitted in the clear.
>     The IP numbers are already in the clear with TLS, and giving
>     the quality of traffic fingerprinting already available, expanding
>     this visibility to reveal the FQDN implies a very small loss
>     of actual privacy.
>     Revealing also the path component of the URL, but not the query
>     part, likewise would amount to very little actual loss of privacy,
>     but would allow filtering proxies to ban only
>     rather than all of

Mark can of course do as he likes with his document, but I would
not support adding this text to a WG document as I do not believe
that it is accurate.

It is quite common to have sensitive information in the path part of
URLs (for instance, Amazon item numbers appear here), and in
many cases, this is the only sensitive information required to
reconstruct the user's browsing history. I don't consider this to
be "very little actual privacy" loss.


Received on Tuesday, 15 July 2014 13:44:01 UTC