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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matthias,

If the use case is simply to help detect an error by the data controller of the Matthias site, i.e. they have put an element with a an external reference to an other-origin tracking resource that ignores DNT, then OK but it seems like a sledgehammer to crack a nut. Your doppelganger is the responsible data controller and has no advantage in doing it, so it would be a simple mistake. 

We could have text to recommend that UAs draw the user's attention to it (a Tk1: response from an embedded other-origin resource), but that adds further complications to the text. Would we have to debate it as normative with MAY, MUST or SHOULD?

Mike




> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
> Sent: 07 January 2014 09:09
> To: Mike O'Neill; public-tracking@w3.org
> Cc: 'Dobbs, Brooks'
> Subject: 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+yIKMiNEyvYL3U817UPIwt8zrwwQANJGwBSsUr6ukgd57dz7K92rq7yEV
> m
> > Y19mq2srxxqUeaOgXVci+1Ki6rc+k0oicqgOo808RbcthdqyhtSnkynniJG3GBcx
> > jQXvlOXEb1i17/+6gHU4a2Lb0rf8JgHidv4G5YtjMH2iTFYdeLCdgquxogLWMtHQ
> > tknFiVvDzSVDAMzJuiw1dHgLnYeSjXwo+kQpv+njFvB35sWIi+HISg3+WX0ZkR5C
> >
> KwX1u/DIcFb/tQGHZUmDRv+sToz5BJI7ODo/lHp037lBIMQmQ8N8JROFRgCH1JU
> =
> > =x++r
> > -----END PGP SIGNATURE-----
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJSy9lNAAoJEHMxUy4uXm2J0qgH/iDXH6xBUWITXv8HfznwfjyO
B/wnM4KCAHE0aeIchHc6pI872cYSskdFkWQ5f82RA4THYEF8WdCW1jOYABI54fZF
FiuEmVnhSNDhqtuCkn0kuoO8mPHw8YSoiIjeftovK1Lb9ojj8w0zoMaxm9JOeo5f
KGtS6G7xkMHhL9Xn5vPufkOwAvBa1SP32kWtrgXg6krQ/zpAwJ2mRXL8zYsGEaoS
vichTp7X6k/tjQSEMjFhkZb1tFMzgPoFkP3lq9muiozetI6POH4yM8SxqRwr7EH8
at+YEglizf/u7t0rbeyJ34LDqCoWRcV3XypfheGIG/DpkkPNE5nqrR2tcYtH9mA=
=z+6W
-----END PGP SIGNATURE-----

Received on Tuesday, 7 January 2014 10:39:53 UTC