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

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

Hi David,

I do not have a problem with having the option of a Tk:1 header, just the lack of clarity in the reason given for reinstating it. It will be up to a compliance document to define what it conveys and if it is required. On the other hand, if its presence in an other-origin response is supposed to be an indication to the user of a dodgy page, or a debugging aid for developers, then this is a technical rather than a compliance issue and UAs will need to pass the information on somehow.

Anyway, its removal in the first place was a chairs/editors decision, never requested by the rest of us. My problem was solely with overloading the definition of tracking with the ambiguous multiple contexts limitation, which I still feel is inappropriate in the TPE.

Mike

> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 08 January 2014 00:10
> To: Matthias Schunter (Intel Corporation)
> Cc: Mike O'Neill; Tracking Protection Working Group; Dobbs, Brooks
> Subject: 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+yIKMiNEyvYL3U817UPIwt8zrwwQANJGwBSsUr6ukgd57dz7K92rq7yEV
> m
> >> 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.
> 

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

iQEcBAEBAgAGBQJSzOhfAAoJEHMxUy4uXm2JIBYIALp+xGcyilr48q5xUE6SsjyI
8pYGozsglvzwqCpEYuW9GvMzMzoa5jVNYyA76cHbb3ukzoN0G4uLTJbFVyMTPal+
iDhhAtxN2tpjE/BAxvCkFv9OfqiTrKmwFAB8QHWQHDU9Solkn6eK3evMM3Ri/fQl
zkkqyoGgfZ697Afuk4LnZNGFhzGZIQAkYYavgI4tt0GdpE2EzOBFKuRZBpBlNYtj
N6pJoG+WFRozXVuxkhKzlDrDRH5Ga3VWitXUjV8FSM7JxBgcEgnF+sdqRrSMg2Ey
Yp0ptRYXGxuFS/60MnMY2NYnZqjvl6frEyNqphS0sa1x0B6OD4+Pq10Wjb98mqU=
=tMHq
-----END PGP SIGNATURE-----

Received on Wednesday, 8 January 2014 05:56:33 UTC