On Tue, 10 Jul 2012 10:54:53 -0400
Alissa Cooper <acooper@xxxxxxx> wrote:
> Hi Andreas,
>
> On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
> >> The first statement above gets at this, but it seems to me that the
> >> middle ground between random generation per request and permanent
> >> unique token is worth emphasizing if there will be proxies that want
> >> to keep per-client identifiers around for some limited amount of time
> >> that isn't forever.
> >>
> >> It's also worth noting that the second statement above is equally true for statically provisioned client IP addresses.
> >>
> >> Also, this statement in 8.3 is not really true and probably better left out:
> >>
> >> "Proxies using this extension will preserve the information of a
> >> direct connection, which has an end-user privacy impact, if the end-
> >> user or deployer does not know or expect that this is the case."
> >>
> >> There can certainly be a privacy impact whether the user or deployer has awareness/expectation or not.
> >
> > Can you give some proof or at least some arguments for this statement?
> >
>
> If the deployer has awareness/expectation but users do not, then users' expectations that their client addresses will not be shared will be violated.
I interpret the statement "which has an end-user privacy impact" to be
true if any of "end user" or "deployer" does not know about it.
So that should cover the case when the deployer knows, but not the end
user.
> But even if users have awareness/expectation that their client addresses will be shared, the implications of that sharing may not be obvious, and there is nothing preventing remote servers that receive the information from abusing it. Examples: a user who doesn't know that his address is static and can be used by a remote server to track and correlate all of his activity; a user who doesn't know that his ISP maintains records of customer identity tied to client addresses that may become subject to law enforcement request; a service that combines static addresses or tokens received via the header with other collected identifiers and shares them with other servers to enable more pervasive tracking.
Thanks for explaining.
Yes, I can agree on this.
I do not think that this header changes real life affect on end users
privacy very much, though.
The big issue here is that there is quite a lot of things that the end
user are aware of.
> The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.
See my answer to SM. I think it better explains that the expectations
of the end user are important to consider, even if these expectations
are wrong.
I don't think that text will have much impact on how the header field
is used in practice though, or any technical impact, so removing it is
fine with me.
It would be interesting to hear what Stephen Farrell thinks about it,
since he wrote that text.
Cheers,
Andreas
Attachment:
signature.asc
Description: PGP signature