W3C home > Mailing lists > Public > public-tracking@w3.org > January 2014

RE: Signals for internal / external usage of site elements (the signals formerly called "1" and "3")

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



Received on Monday, 6 January 2014 23:23:53 UTC

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