- From: Mike West <mkwst@google.com>
- Date: Mon, 27 Aug 2018 12:52:34 +0200
- To: phk@phk.freebsd.dk
- 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>
- Message-ID: <CAKXHy=f9BZ4RVJVwvt1m8GeQ1D04x3Dz1PL8i8yjt4cLgyvVhA@mail.gmail.com>
On Mon, Aug 27, 2018 at 12:02 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > 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. > Agreed. I don't actually think you and I are arguing on this point. :) >> , 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. I see. You're not suggesting that the identifier would be changed on every request, but after some period of time (e.g. after the user's private browsing session ended), and that the ephemerality signal is a nice way to let servers know that they can drop the session information after some reasonable period of time. I'm not sure user agents would want to advertise to servers that users are in such a mode, as it seems like there would be consequences to doing so (e.g. "We've noticed that you're visiting us ephemerally. How unfortunate! Please opt back into persistence to read the next page."). Is there an advantage to the user in this situation? -mike
Received on Monday, 27 August 2018 10:53:09 UTC