W3C home > Mailing lists > Public > public-tracking@w3.org > April 2017

RE: Issues for Monday Call

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Fri, 7 Apr 2017 14:45:39 +0100
To: "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>, <public-tracking@w3.org>
Message-ID: <002a01d2afa5$3f2464a0$bd6d2de0$@baycloud.com>
Thinking about this I wonder if there could be help with another problem currently affecting online advertising.

It may also be possible to improve transparency for subresources, e.g. to help advertisers get visibility on where there ads are appearing.

An API that gave all browsing contexts read-only access to every TSR on a page could do this. There would be no access to urls, just the existing TSRs. The controller property could then tell everyone who they are sharing a page with. Only the TSR returned or cached when DNT:1 would be made available.


-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 06 April 2017 09:49
To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Issues for Monday Call

Hi Folks,

1. to tackle the question "what extra field and qualifiers do we need",
we now focus on the final open new usecase which is online ad auctions.
Rob will report his findings and we see whether more info is essentially
required to satisfy the "information" requirement by the EU legislation.

2. We then look at the remaining high-priority issue:

3. Then at the other lower priority issues

Our list of issues is at:
Note that issues that are not resolved by end of April will be
auto-pushed out to potential future releases.



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
	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
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)

4. Anything else we want to discuss
Received on Friday, 7 April 2017 13:46:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:34 UTC