Re: [w3ctag/design-reviews] HTTP State Tokens (#297)

> There's an enum in the explainer? (I don't see one.)

You're right. It's much more implicit than I thought it was in the `delivery` section of https://github.com/mikewest/http-state-tokens#a-proposal. Sorry about that, it'll be more clear if/when I ever get around to writing a spec.

> So perhaps not Lightbeam exactly -- but tools that help users understand what's happening with their information. So just as we try to minimize passive fingerprinting opportunities while worrying less about active fingerprinting, it seems like we ought to be concerned about the distinction between passive tracking versus active tracking -- probably even more so in tools designed for tracking than for the fingerprinting case.

I agree that we need to be cognizant of the opportunities we're creating, and mindful of the ways in which they'll be abused.

That said, this proposal is strictly narrower than status quo insofar as it does not allow tokens to be minted in third-party contexts, but only in first-party contexts. That is, the site which wishes to track users will need to "actively" deliver a `Sec-HTTP-State-Options: delivery=cross-site` header to the user in a first-party context in order to receive tokens in a third-party context. That seems to me to satisfy your concerns with regard to the passively-available characteristics of the token. Does it not?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/297#issuecomment-434747363