- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Thu, 30 Mar 2017 09:10:45 +0200
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi Folks, based on the discussion last week. Below I codified an alternative approach to resolving the TSR issues (based on the emails on the list and input from last week). Our list of issues is at: https://github.com/w3c/dnt/issues/23 Note that issues that are not resolved by end of April will be auto-pushed out to potential future releases. Regards, matthias ----- DISCUSSIONS FOR MONDAY 1. Issue triage: Are there issues that are high priority and must be resolved in April? If not, we can process without change. 2. What additional fields are desired for simplifying compliance in the EU? Note: So far I have not seen any submitted proposals for an additional concrete field on the list. If I receive none, IMHO we can close this discussion on monday. 2. Best way to communicate "consent context". Our current approach was that the TSR serves two roles: A. Discovery (before visiting site) of essential tracking information B. Sufficient context to give clear meaning to user-granted exception. This role triggered that we plan to require TSR if the exception API is used. It also fuels our discussion "what extra fields are needed" Roy suggested that TSR may be the best place for (B). Let us see whether we find a better place for the consent-context information. One suggestion was that it should be part of the API call. 3. Asyncronous API / Update Events (Continued) https://github.com/w3c/dnt/issues/13 4. Anything else we want to discuss
Received on Thursday, 30 March 2017 07:11:16 UTC