Re: #552: allow privacy proxies to be conformant

On 29/01/2014 2:47 p.m., Roy T. Fielding wrote:
> In the IESG comments on p1 from Sean Turner:
> 
>> 1A) s5.7.2 and s2.3: s2.3 mentions privacy proxies and s5.7.2 says the
>> following about proxies without qualifying the type of proxy:
>>
>>   A proxy MUST NOT modify header fields that provide information about
>>   the end points of the communication chain, the resource state, or the
>>   selected representation.
>>
>> So does that essentially mean privacy filters proxies are non-conformant?
> 
> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/552
> 
> I think that the above text (which is broader than the specific header
> field requirements in RFC2616) can be improved by replacing it with the
> following text:
> 
>    A proxy MUST NOT modify header fields that provide information about
>    the end points of the communication chain, the resource state, or the
>    selected representation (other than those necessary to describe how
>    the payload has been transformed). However, an exception to this
>    requirement applies to proxies that are specifically configured to
>    remove or filter header fields for the sake of privacy or security.
>    The person or organization selecting the proxy is presumed to have
>    control over its configuration.
> 
> Alternatively, we could go back to the list of specific header fields
> that were specified in RFC2616 sec 13.5.2 and Allow.

Why should it be okay if some network admin (IMPROTANT: *not* the
end-user or server operator being affected) explicitly asks for it but
not when the proxy authors who may very well understand the header
better think its a good idea to default-off on emitting something?

Either its okay to improve the traffic or its not. Whoever does it.
Surely the specification is not the right place to be forbidding
improvements.


The issue is that "end points of the communication chain" part. IMHO,
the downstream endpoint of the chain is not so important for the
transformation as the payload/content/resource, the proxy and the
downstream recipient of the message.
 We also have the possibility of a proxy adding/removing formats the
endpoint may be offering but which cause problems to the end-to-end
network. For example the Content-Encoding:sdch offered by a certain
browser can result in a response payload which is quite nasty to serve
up from cache, so caching proxy woudl prefer to drop it and let
gzip/deflate/identity encodings happen instead. It MAY do the sdch
conversion itself and generate the client response, but that has nothing
to do with the server.


On a side note;

 In the name of privacy it may be better to go back to the old list of
headers which are MUST NOT modify and a recommendation for new header
definitions to state whether or not proxy modification is also MUST NOT
/ MUST / whatever.

 Getting a header onto that list past a standards body with all the eyes
and minds is one of the fundamental checks-and-balances for user privacy
protection.

 Without that limitation any implementation could spread a new header
User-Home-Address or User-Bank-Login-Details (or something innocently
named with same field-values) and proxies are forced to violate the
specification simply to remove it.

 If the clause in question becomes a SHOULD NOT, then the proxies are
free to adjust headers if things get really problematic and the
standards body checking is replaced with more flexible and dynamic
industry moderation.

Amos

Received on Wednesday, 29 January 2014 05:31:52 UTC