> On Mon, 14 May 2012 10:37:10 +0100
> Stephen Farrell <stephen.farrell@...> wrote:
>> On 05/13/2012 06:07 PM, SM wrote:
>>> As a starting point, here's some suggested text for Section 8.2:
>>> In recent years, there has been growing concerns about privacy. There
>>> is a
>>> tradeoff between ensuring privacy for users versus disclosing information
>>> which is useful for debugging. The Forwarded HTTP header field, by
>>> exposes information which affects the privacy of users. This header
>>> should not be used if the proxy is being operated as a privacy service.
>> - Is "privacy service" well-defined? (Or well enough defined?)
> Maybe we can write something like "if the proxy is intended to
> anonymize the user" ?
Maybe. Could be a rathole I guess so it may well be better
to say when its ok to use this, rather than when to not use
this, or perhaps some mixture of the two. I'm not sure myself.
>> - In general, is a user supposed to know that headers like this
>> are being added? If so, how? If not, doesn't that have privacy
>> implications as well?
> There are lots, and lots of different proxy types and the users needs
> special education for each of them. However, this can not be done in
> this document.
So you're saying that this is designed to be invisible
to the end user. That may be entirely reasonable but does
have privacy implications, especially if this gets used
in the wrong places or ways.
If this is designed to be invisible to the end-user then
I agree there's no issue for the draft related to educating
users, since the poor user can't ever tell when its happening.
>> - Section 5.4 is also odd: when would we want a proxy to make it
>> look to the UA that stuff the proxy got unprotected was protected?
> It is not uncommon that you have a reverse proxy that do SSL-offload.
> This should be of no concern for the user.
But that's only reasonable in some use-cases, and is
entirely unreasonable in others, right? (e.g. for
a corporate outbound proxy or an ISP's proxy) Where
does it specify those reasonable use-cases and say
not to do this in other cases?
>> - I also wondered how widely the X-Forwarded stuff is deployed and
>> generally whether its really a good or bad idea to standardise
>> this. I can't tell from (the quick read I had of) the document.
> It has a really wide spread usage in the world of proxying.
I'd be interested in some references for that, if you have
'em. But assuming this is widely used, then yes, that is an
argument for figuring out how to document it better.
Whether that's a winning argument is another question maybe.
I guess that depends on how well its documented and whether
it'd improve or dis-improve the Internet.