- From: David Singer <singer@apple.com>
- Date: Fri, 10 Oct 2014 12:51:54 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mike O'Neill <michael.oneill@baycloud.com>, Nicholas Doty <npdoty@w3.org>, Tracking Protection Working Group <public-tracking@w3.org>
On Oct 10, 2014, at 12:32 , Roy T. Fielding <fielding@gbiv.com> wrote: > On Oct 9, 2014, at 2:13 PM, David (Standards) Singer wrote: >> No, the existence of the exception is irrelevant if you don’t go back to the site. If you do, then the site also sees the absence of the cookie (it’s expired) and knows it needs to re-acquire the exception. > > That would make the UGE mechanism substantially worse than simply using > a cookie to record exceptions. The *only* reason we have a separate UGE > API is so that UGE's survive a general cookie flush. True, but the question of “how do I expire a UGE?” came up, and *one* way to do it is to use a cookie. I think it may work acceptably well for some or many. Somehow we’ve got from “can I use a cookie as the timer to help me expire a UGE?” to “can I rely on a cookie to record a UGE?”. The answer to the first is yes, if you like. But it doesn’t give you the right to ignore the DNT header and treat the cookie as definitive. If the DNT header comes as zero, and the cookie doesn’t arrive, then you eyebrows go up and you probably re-confirm the exception and re-set the cookie. > > ....Roy > David Singer Manager, Software Standards, Apple Inc.
Received on Friday, 10 October 2014 19:52:45 UTC