|
»
« Return to Thread: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02
Re: [apps-discuss] Comments on draft-ietf-appsawg-http-forwar
by sm-7
::
Rate this Message:
Hi Stephen,
At 02:37 14-05-2012, Stephen Farrell wrote:
>- Is "privacy service" well-defined? (Or well enough defined?)
"privacy service" is not defined in the draft. I could have
suggested "providing an anonymous service" but that is not
well-defined as well. I suggest looking at this in terms of whether
the wording can be easily understood or else a reference for "privacy
service" will be needed.
>- 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?
In general, a user does not know that headers like this are being
added. They look for a proxy which they believe provides them
anonymity. The user relies on word of mouth or what the operators
advertises on their web site. I had a sentence (I didn't suggest it)
about user trust to cover privacy implications.
Section 15.7 of RFC 2616 discusses about proxies and privacy. It's
written from a HTTP perspective.
>- 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?
That's the reverse proxy scenario. The information is exchanged
between the user agent and the reverse proxy over SSL. As the origin
server is in a trusted environment, you can do away with the SSL
overhead if it is expensive.
>- 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.
Squid, a web known proxy which is widely deployed adds, an
X-Forwarded-For: header. There are configuration knobs to turn that off.
Whether it is a good or bad idea to standardize this header is a
matter of religion. :-) We could look at this in terms of consent model.
(a) User -> web site
(b) User -> proxy -> web site
In (a) the user communicates directly with the web site. We cannot
"hide" the IP address as that is needed for the communication
protocol to work and there is indirect user consent. In (b), the
user consent is up to the proxy. The User's IP address is not needed
for communication between proxy and web site. One can argue that the
proposal violates that model.
Regards,
-sm
_______________________________________________
apps-discuss mailing list
apps-discuss@...
https://www.ietf.org/mailman/listinfo/apps-discuss
At 02:37 14-05-2012, Stephen Farrell wrote:
>- Is "privacy service" well-defined? (Or well enough defined?)
"privacy service" is not defined in the draft. I could have
suggested "providing an anonymous service" but that is not
well-defined as well. I suggest looking at this in terms of whether
the wording can be easily understood or else a reference for "privacy
service" will be needed.
>- 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?
In general, a user does not know that headers like this are being
added. They look for a proxy which they believe provides them
anonymity. The user relies on word of mouth or what the operators
advertises on their web site. I had a sentence (I didn't suggest it)
about user trust to cover privacy implications.
Section 15.7 of RFC 2616 discusses about proxies and privacy. It's
written from a HTTP perspective.
>- 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?
That's the reverse proxy scenario. The information is exchanged
between the user agent and the reverse proxy over SSL. As the origin
server is in a trusted environment, you can do away with the SSL
overhead if it is expensive.
>- 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.
Squid, a web known proxy which is widely deployed adds, an
X-Forwarded-For: header. There are configuration knobs to turn that off.
Whether it is a good or bad idea to standardize this header is a
matter of religion. :-) We could look at this in terms of consent model.
(a) User -> web site
(b) User -> proxy -> web site
In (a) the user communicates directly with the web site. We cannot
"hide" the IP address as that is needed for the communication
protocol to work and there is indirect user consent. In (b), the
user consent is up to the proxy. The User's IP address is not needed
for communication between proxy and web site. One can argue that the
proposal violates that model.
Regards,
-sm
_______________________________________________
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 |
