Privacy considerations

[ioggstream]

This PR

privacy considerations.

[ioggstream]

Hi @bemasc Does this clarifies your concerns?

[bemasc]

I don't think this is sufficiently detailed to be implementable as written. As an OHTTP implementor, what am I supposed to do to defeat these attacks? This text doesn't say, and I certainly don't think it's obvious.

If we don't have an answer, then I think this draft should change to Experimental.

[ioggstream]

@bemasc some clarifications:

1. the goal of this I-D is to provide to the clients enough information to avoid being throttled;
2. these fields are usually returned by servers that identify (e.g. via Authorization) their clients;
3. I will add the above clarification to the PR.

The Proxy Feedback I-D is another document.

As an OHTTP implementor, what am I supposed to do to defeat these attacks?

It would be great if you could provide some further examples about how those fields can be used to implement tracking techniques.

This text doesn't say, and I certainly don't think it's obvious

My understanding is that, if a client wants to prevent this kind of attacks, it can just ignore RL fields. Please consider that similar considerations apply to OHTTP even for other fields such as Retry-After: a client ignoring RL fields will finally get an error response (4xx|5xx) + a Retry-After header . Honoring Retry-After will eventually enable the server to affect the timing of client requests and make it possible for the server to link successive requests from a single client.

cc: @tireddy2

[bemasc]

@ioggstream Sorry, I thought this PR was for draft-rdb-ohai-feedback-to-proxy. For this draft, I have no objection to this text.

[ioggstream]

@bemasc Good to know, thanks for your feedback.

wrt OHTTP, I'm interested in discussing further potential issues related to Retry-After.

[ioggstream]

Hi @martinthomson, your feedback would be very welcome :)