Re: #552: allow privacy proxies to be conformant

On Jan 28, 2014, at 9:31 PM, Amos Jeffries wrote:

> 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?

I don't think anything in that text prevents reasonable defaults
(or even unreasonable defaults).  It just has to be configurable
or it will not be interoperable.  In practice, proxy authors have
no idea what applications are intentionally being run on a network.
Their assumptions are always wrong when there is someone like me
using the network.

> 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 original requirements were added because proxy implementations
were interfering with deployment of Digest authentication.  Hence,
they are there to enable 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.

Those are payload transformations, explicitly permitted by that section.

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

Yes, that is what was in RFC2616: a general SHOULD NOT and a list of
MUST NOT fields.  I believe it was changed to categories because
proxies did not know what to do about etags, cache-control, and new
fields like authentication-info.  A category-based definition seemed
preferable to sprinkling proxy requirements in every header field.

I don't have a strong preference here other than a desire to minimize
the changes required to allow privacy/security filtering.  If you have
specific wording that would enable it better than mine above, please
propose that instead.  Reverting to the RFC2616 requirements is a much
larger edit.

....Roy

Received on Wednesday, 29 January 2014 18:49:32 UTC