- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 7 Feb 2023 13:24:33 +0000
- To: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
- Message-ID: <f6fd5886-5da8-38a7-0bd3-1fd54a96238f@cs.tcd.ie>
Hiya, On 07/02/2023 12:56, Martin Thomson wrote: > > On Tue, Feb 7, 2023, at 07:32, Stephen Farrell wrote: >> Can someone clarify whether the u= field amounts to a super-cookie >> or not, and if not, how that might be the case? > > It doesn't have to be. Each site (*) could get a different key pair > and key identifier. Sure, that could happen. Question is whether that's likely or not. History seems to show that new tracking opportunities on the web will be exploited, so I'd argue that's not an ignorable risk for this scheme. IOW shouldn't this draft define a way or ways to avoid that risk? Seems to me it should. > The draft doesn't say that though, so you are right to ask. This is > probably another case where documenting a little more detail about > the usage context could help. > > (*) That's a web term, I know, but the question was also web-related. > The more general way to approach this is to say that for servers > where the client would not otherwise be linkable, the client must use > different keys and key identifiers. I'm not sure how a client could evaluate that "not otherwise" Cheers, S. > On the web, the boundary we use > to determine when linkability is assumed or not is site. >
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Tuesday, 7 February 2023 13:24:50 UTC