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

Hi Mike,

thanks for the input.

Roy/David: Do you agree that "porting" this feature to the TPE does not 
make sense?
  If yes, I am fine with this simplification. I just thought that at the 
time we designed the feature it provided a useful functionality (which 
indeed may no longer exist if the 1st and 3rd party rules are shifted to 
the compliance document...)

Regards,
matthias
Am 07.01.2014 00:23, schrieb Mike O'Neill:
> -----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 Tuesday, 7 January 2014 09:09:02 UTC