|
»
« Return to Thread: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02
Re: [apps-discuss] Comments on draft-ietf-appsawg-http-forwar
by Andreas Petersson-2
::
Rate this Message:
On Mon, 14 May 2012 12:10:32 +0100
Stephen Farrell <stephen.farrell@...> wrote:
>
>
> On 05/14/2012 11:29 AM, Andreas Petersson wrote:
> > 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
> >>> design,
> >>> exposes information which affects the privacy of users. This header
> >>> field
> >>> 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.
This header field do not really add information but only preserve it.
> 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.
You complaint is only valid when the user thinks he is using an
anonymizing proxy when he isn't.
>
> >> - 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?
This document do not encourage someone to decrypt traffic with no
reason. We can not list all reasonable and non reasonable use 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.
Well, X-Forwarded-For was introduced by squid. Squid has a significant
market share for proxy servers.
Also, the X-Forwarded-For is also used for Opera Mini, with almost 200M
users we have a significant market share for mobile users, and we
intend to start using the header field described in this document.
Best regards,
Andreas
_______________________________________________
apps-discuss mailing list
apps-discuss@...
https://www.ietf.org/mailman/listinfo/apps-discuss
Stephen Farrell <stephen.farrell@...> wrote:
>
>
> On 05/14/2012 11:29 AM, Andreas Petersson wrote:
> > 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
> >>> design,
> >>> exposes information which affects the privacy of users. This header
> >>> field
> >>> 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.
This header field do not really add information but only preserve it.
> 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.
You complaint is only valid when the user thinks he is using an
anonymizing proxy when he isn't.
>
> >> - 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?
This document do not encourage someone to decrypt traffic with no
reason. We can not list all reasonable and non reasonable use 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.
Well, X-Forwarded-For was introduced by squid. Squid has a significant
market share for proxy servers.
Also, the X-Forwarded-For is also used for Opera Mini, with almost 200M
users we have a significant market share for mobile users, and we
intend to start using the header field described in this document.
Best regards,
Andreas
_______________________________________________
apps-discuss mailing list
apps-discuss@...
https://www.ietf.org/mailman/listinfo/apps-discuss
« Return to Thread: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02
| Free embeddable forum powered by Nabble | Forum Help |
