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

Re: Issue-22, possible other direction

From: Alanna Gombert <alanna@iabtechlab.com>
Date: Thu, 18 May 2017 19:07:39 +0000
To: Rob van Eijk <rob@blaeu.com>
CC: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <41584201-B4A2-4402-BCBD-5B8BA50B4535@iabtechlab.com>
Hi all,

I run the Tech Lab. Happy to explain further. We are actually in meetings today discussing the initiative and companies are presenting their opinions as the solution is in public comment.

Best

Alanna

Sent from my iPhone

On May 18, 2017, at 14:52, Rob van Eijk <rob@blaeu.com<mailto:rob@blaeu.com>> wrote:

Hi Shane, David,

My proposal is in fact not far from the machine readable ads.txt file proposed by the IAB Tech Lab OpenRTB Working Group. (https://iabtechlab.com/ads-txt/).The otherParties property could eliminate the need fot the ads.txt file. We could make the content of the otherParties property useful such that it is fit for purpose for specific consent as well as  minimizing data leakage that will help against domain spoofing and other types of ad fraud/malvertising. Please let me know if we should explore this further.

Rob
---
PGP id: CC4F3863 [public key<https://sks-keyservers.net/pks/lookup?op=get&search=0xBEA020B7CC4F3863>]
PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863

Social media: @rvaneijk<https://twitter.com/rvaneijk>, github<https://github.com/rvaneijk>,<https://github.com/rvaneijk> linkedin<https://nl.linkedin.com/in/rvaneijk88>,<https://nl.linkedin.com/in/rvaneijk88> ssrn<https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225>,<https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225> stackoverflow<http://stackoverflow.com/users/4725192/rvaneijk?tab=profile>
---

-----Original message-----
From: Matthias Schunter (Intel Corporation)
Sent: Thursday, May 18 2017, 6:32 pm
To: public-tracking@w3.org<mailto:public-tracking@w3.org>
Subject: Re: Issue-22, possible other direction


Hi Shane,

we can use this as your text proposal (i.e. only the field syntax is
changed from array to URL). If you  want to propose something else, feel
free to do so ASAP.

Thanks a lot!

matthias


On 15.05.2017 23:09, Shane Wiley wrote:
> Rob,
>
> If a data controller were to provide a link to a list of their 3rd
> parties in the TSR or to a user more directly during their consent
> dialogue, would that meet legal obligations?
>
> otherParty: www.companyxyz.com/3rdparties/list.html<http://www.companyxyz..com/3rdparties/list.html>
> <http://www.companyxyz.com/3rdparties/list.html>;
>
> Why does this need to be machine readable if we're taking blocking off
> the table?  Additionally, since we already allow publishers to only
> request site specific exceptions for specific 3rd party domains, why is
> this additional list needed?  We already appear to have all the utility
> needed to support ad exchange scenarios such that publishers can request
> consent for only those 3rd party domains they have knowledge of and a
> contract with - so what does this add?
>
> If these are true:
>
>    - the Data Controller is responsible for the interaction between
> themselves and the user with respect to consent,
>    - consent can be obtained by providing a list of specific third
> parties in human readable form to a user as long as the scope is
> specific and informed,
>    - the current standard allows exceptions (consent) to only be
> provided for a specific list of third parties (wildcards need not be used),
>    - AND, as a working group we're not attempting to backdoor tracking
> protection lists for domain blocking
>
> ...I'm not seeing the "transparency" value of otherParty.
>
> - Shane
>
> Shane Wiley
> VP, Privacy
> Yahoo
>
>
> ------------------------------------------------------------------------
> *From:* Rob van Eijk <rob@blaeu.com<mailto:rob@blaeu.com>>
> *To:* "public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)"
> <public-tracking@w3.org<mailto:public-tracking@w3.org>>
> *Sent:* Monday, May 15, 2017 12:24 PM
> *Subject:* FW: Issue-22, possible other direction
>
> FW: Issue-22, possible other direction
> ... including the lsit
>
>         -----Original message-----
>         *From:* Rob van Eijk
>         *Sent:* Monday, May 15 2017, 9:08 pm
>         *To:* David Singer; singer@apple.com<mailto:singer@apple.com>; Shane Wiley
>         *Cc:* Matthias Schunter (Intel Corporation); Roy T. Fielding
>         *Subject:* RE: Issue-22, possible other direction
>
>         Hi,
>
>         I think it may be helpful to go back to the initial consensus
>         [1]. I am not a proponent of an API component in this
>         discussion. I would be happy with a simple, optional (MAY)
>         otherParties property in the TSR that complements the sameParty
>         property. I believe the otherParties property is beneficial for
>         different types of site owners, ranging from non-tracking sites
>         to RTB-driven sites.
>
>         I think we can keep the TPE clean and simple. The aim of the
>         otherParties property is (optional) transparency.
>
>         [1]
>         https://lists.w3.org/Archives/Public/public-tracking/2017May/0003..html
>
>         Rob
>         ---
>         PGP id: CC4F3863 [public key
>         <https://sks-keyservers.net/pks/lookup?op=get&search=0xBEA020B7CC4F3863>;]
>         PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863
>
>         Social media: @rvaneijk <https://twitter.com/rvaneijk>;, github
>         <https://github.com/rvaneijk>;,
>         <https://github.com/rvaneijk>linkedin
>         <https://nl.linkedin.com/in/rvaneijk88>;,
>         <https://nl.linkedin.com/in/rvaneijk88>ssrn
>         <https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225>;,
>         <https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225>stackoverflow
>         <http://stackoverflow.com/users/4725192/rvaneijk?tab=profile>;
>         ---
>
>
>
Received on Thursday, 18 May 2017 19:12:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:36 UTC