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

In message <A5DB7CA0-D6DC-4E21-911A-A9FDEAA8CC52@mnot.net>, 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 example.com/user/evil
    rather than all of example.com.

    The proposed distinction between "envelope" and "contents" has
    been recognized in legislation for centuries and would therefore
    provide a well-known and -understood tool for tailoring legislation
    more narrowly, than the currently very broad strokes used with
    respect to privacy on the internet.

    (The proposed scheme would also have other benefits outside
    the scope of this document, mainly for incoming load-balancers
    and reverse proxies on the server side.)

-- 
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 incompetence.

Received on Tuesday, 15 July 2014 11:40:53 UTC