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

I think that the browser being able to tell in a uniform way whether a site was designed as first party or third party, without making any statements about what first party or third party rules it conforms to, is useful.

Even if a conformance regime is finally conceived that doesn’t make or need the distinction, it’s not harmful for the TPE to enable signalling it for sites using that regime; it’s just not relevant.

As you say, finding a resource that presumed it was in a 1st party context, being used in a 3rd party context, should be a warning flag to the browser that maybe the site is not following the rules for the context it has (probably unwittingly) been placed in.  In the current compliance document, we place much lighter constraints on 1st party than on 3rd, so there may well be a concern for the user here.

These flags don’t link to a specific conformance regime.  I don’t see the problem that Mike sees, honestly, and they really help the user not to be 'flying blind’.

On Jan 7, 2014, at 1:08 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:

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

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 8 January 2014 00:10:37 UTC