- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Mon, 6 Jan 2014 23:23:11 -0000
- To: "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>, <public-tracking@w3.org>
- Cc: "'Dobbs, Brooks'" <Brooks.Dobbs@kbmg.com>
- Message-ID: <03f501cf0b36$446457c0$cd2d0740$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias, If this is an HTML element then only the server addressed by the reference URL, presumably Google, will place or receive an UID or collect other data. That origin server can respond with a Tk: header or locate a well-known tracking resource at its origin, so the tracking status can only be asserted by the data controller managing it. The ultimate server can be different through redirection but the initial data controller has responsibility for starting the chain. If you mean by a tracking element a javascript library then this cannot generate a Tk: header from any external server and is incapable of affecting the placement of any tracking resource. I agree with Brooks, this use case does not make sense. Mike From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] Sent: 06 January 2014 20:23 To: public-tracking@w3.org (public-tracking@w3.org) Subject: Signals for internal / external usage of site elements (the signals formerly called "1" and "3") Hi Team, as part of removing dependencies in the compliance spec, Roy removed the "1" and "3" signals. I would like to make a case for keeping these two signals in a revised form. SCENARIO TO PREVENT The reason these signals were included is to detect/prevent the following scenario: 1. - A party designs an element to be used _only_ within its own web-site (e.g., the google logo). 2. - The party uses this element for some kind of tracking 3. - Another site (say Matthias's homepage) re-uses the element and, e.g., claims "not to do tracking" 4. - However, in fact, the other site does tracking (by accidentially embedding the tracking element) OLD TEXT This is the text, I copied from an older version of the DNT spec. 3 Third party: The designated resource is designed for use within a third-party context and conforms to the requirements on a third party. 1 First party: The designated resource is designed for use within a first-party context and conforms to the requirements on a first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party. Roy had to remove the text since it references "requirements on a first party" (that is undefined in the TPE and will be defined in the compliance regime) PROPOSED NEW TEXT I think that the signaling of "elements for site-internal use" and "elements re-usable by other sites" remains useful. 3 Third party: The designated resource is designed for re-use by other parties. 1 First party: The designated resource is designed for use within the serving party. In the scenario above, this would work as follows: 1. - A party designs an element to be used _only_ within its own web-site (e.g., the google logo) ("1") 2. - The party uses this element for some kind of tracking ("T") 3. - Another site (say Matthias's homepage) re-uses the element and, e.g., claims "not to do tracking" ("N") 4. - However, in fact, the other site does tracking (by accidentially embedding the tracking element) The result (detectable by a browser or by the site owner) is that a "1+T" element from another site would show up on the page that claims "N". This may indicate a potential problem. Any opinions/feedback/improvements? Regards, matthais -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSyzrdAAoJEHMxUy4uXm2JcagIAKfHi9xsmxwvfGog9mSur798 s/oW71+yIKMiNEyvYL3U817UPIwt8zrwwQANJGwBSsUr6ukgd57dz7K92rq7yEVm Y19mq2srxxqUeaOgXVci+1Ki6rc+k0oicqgOo808RbcthdqyhtSnkynniJG3GBcx jQXvlOXEb1i17/+6gHU4a2Lb0rf8JgHidv4G5YtjMH2iTFYdeLCdgquxogLWMtHQ tknFiVvDzSVDAMzJuiw1dHgLnYeSjXwo+kQpv+njFvB35sWIi+HISg3+WX0ZkR5C KwX1u/DIcFb/tQGHZUmDRv+sToz5BJI7ODo/lHp037lBIMQmQ8N8JROFRgCH1JU= =x++r -----END PGP SIGNATURE-----
Attachments
- text/html attachment: PGPexch.htm
- application/octet-stream attachment: PGPexch.htm.sig
Received on Monday, 6 January 2014 23:23:53 UTC