- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 27 Aug 2018 10:02:32 +0000
- To: Mike West <mkwst@google.com>
- cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, rigo@w3.org, squid3@treenet.co.nz, rigo@w3c.org, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <CAKXHy=c5DhRq7b7xeH_7YHggL8vmJZYedSzAHLMtgqe4yv-gLA@mail.gmail.com> , Mike West writes: >> My original proposal was that this identifier is 100% under the >> clients control > >This is the proposal I put forth in the explainer document as well. It >sounds like there's some interest in letting the server set some number of >bits at the front of the identifier for routing, etc. and I can see how >that would be helpful, but I think there's a strong case for complete >client-side control. Historically pretty much anything the server has ever had any amount of control over has been used to track users across the network, so there is a very strong case for not making the same mistake again, and give the client complete control. >> , and that one bit is a courtesy bit where the >> client signals if it intends this to be a permanent session or an >> ephemeral/temporary session. >> >> As a starting point, browsing in private mode would set the bit >> to ephemeral, browsing in normal mode would set it to permanent. >My impression is that folks are generally happier sending no identifier at >all when opting-out of advertisers' tracking (or an explicit "0" in the >case of platform-level advertising identifiers like we see on iOS and >Android), but randomizing on every hit is certainly something we could >consider doing. This is where I take the servers side. I want it to be random to give the server-sandwich has something to route on, and I want to mark it ephemeral so that servers can avoid storing session state that will never be reused. Ideally the server would prefer the client to say "I'm leaving, you'll never see this session again", but I doubt that would be reliable enough. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 27 August 2018 10:02:59 UTC