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

Hi Matthias,

Here is my text suggestion.

Tracking Status Value

A tracking status value (TSV) is a short notation for communicating how a
designated resource conforms to the tracking protection protocol, as defined
by this document and [TRACKING-COMPLIANCE]. For a site-wide tracking status
resource, the designated resource to which the tracking status applies is
any resource on the same origin server. For a Tk response header field, the
corresponding request target is the designated resource and remains so for
any subsequent request-specific tracking status resource referred to by that
field. A Tracking Status Value of "0" means that the origin server is
tracking as defined in this document. A TSV of "1" means that the user is
not being tracked. Any other value, or if the TSV is not present, indicates
that the origin server may be tracking. Other values MAY be described in the
document referenced by the URI in the policy property of the Tracking Status
Resource.

TSV    =  "1"                  ; the origin server is not tracking
           /  "0"	         ; The origin server is tracking
          / ALPHA/DIGIT   ; the origin server may be tracking, and this
value may be described in the policy resource          
       
Justification.

The DNT protocol is supposed to be a simple way for a user to express their
general preference on tracking and all this response element does is over
complicate that. It is of no practical use other than to obscure the issue
and will anyway probably be ignored by user-agents. A user simply requires
to know if their request not to be tracked is being honoured and having
upward of 9 possible values of the TSV convey very little to them. A 1 or 0
response maps simply to the DNT header values and will be easier for users
to understand.

Mike

> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
> Sent: 16 January 2014 20:00
> To: public-tracking@w3.org
> Subject: Re: Signals for internal / external usage of site elements (the
signals
> formerly called "1" and "3")
> 
> Hi Folks,
> 
> I had the impression that some people may be interested in retaining
> these signals in the TPE.
> If this is the case, I would like to solicit text proposals...
> 
> 
> Regards,
>   matthias
> 
> Am 08.01.2014 09:14, schrieb Roy T. Fielding:
> > On Jan 7, 2014, at 9:55 PM, Mike O'Neill wrote:
> >
> >> Anyway, its removal in the first place was a chairs/editors decision,
never
> requested by the rest of us.
> > First, the editors' draft doesn't have it because I don't know of any
way to
> express a first/third party design distinction without some notion of the
> constraints on first vs third (i.e., that's 100% compliance).
> >
> > Second, there have been dozens of requests to avoid importing
definitions into
> TPE that are not necessary to express the protocol.  Clearly, these
definitions
> are right on the borderline -- the distinctions that this group has made
regarding
> first and third parties are not discernible by either side of the
connection, so it is
> extremely unlikely that any technical implementations of those ownership
> concepts will be correct. They are regulatory concerns, not technical
concerns.
> >
> > Hence, if at all possible, my preference is to avoid using these terms
within the
> protocol exchange.  This does not prevent them from being used to guide or
> explain compliance.
> >
> >> 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.
> > That is both incorrect and irrelevant to this discussion.  One of the
nice
> > things about closed issues is that we aren't allowed to discuss them
again
> > without new information.
> >
> >> 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.
> > I will try once again to explain the problem space.
> >
> > First, we aren't talking about sites.  A browser might care to know
whether a
> given subrequest is to the same origin, same parent domain, or to a
resource
> that is controlled by the same owner as the page that they intended to
visit.
> Unfortunately, the browser doesn't know what page the user intended to
visit,
> let alone who owns that page.  The initial request target is not
necessarily a first
> party; the first party depends on how the potential action (i.e., link)
was
> presented to the user, not the URI referenced in that action.  This is
something
> that only a user (or regulator acting as a user) can determine.
> >
> > The fact that the browser has been told to fetch a number of pages and
> eventually render content within a frame on one of those pages and, as a
result,
> make more subrequests as instructed by an assortment of page rendering
> choices, driven from some combination of local configuration, standard
HTML,
> CSS, and non-standard scripting, does not in any way inform the browser
which
> of those requests correspond to the intent of the user. In fact, it is
quite possible
> that none of them do (e.g., phishing).
> >
> > A browser, therefore, has no idea whether a given page ought to be first
party,
> let alone the elements within that page.
> >
> > Second, if a browser happens to think it is on a first party page and
makes a
> subrequest to a resource that claims to be first party, why would the user
think
> there might be something amiss?  Because of the domain names?  Browsers
> don't know what parties own/control what domains.  Browsers can't see
> common branding.  Browsers can't make any of the decisions that would
> somehow distinguish one resource owner from another even when they are
> operating on different domains, and there's no guarantee that two
different
> parties can't occupy the same domain (in fact, they often do).
> >
> > Finally, if by some miracle the browser does manage to distinguish one
> resource from another as being owned by different parties, and somehow
> manages to know which of those parties the user actually intended to
interact
> with, and also that this is not a case of joint first parties, then what
is it going to
> do?
> >
> > Is it going to
> >
> >    a) make the subrequest with DNT:1 and hope it all works out?
> >    b) fetch the TSR for this designated resource and inspect its
> >       info before doing (a)?
> >    c) check the resource's reputation with some listing service?
> >
> > Those are the three choices.  Here are the implications:
> >
> >    (a) it has already decided that informing the user before they are
> >        tracked is not desired; the 1/3 flag will not be received.
> >
> >    (b) the TSR will either not exist (no compliance) or contain
sufficient
> >        detail for the browser to make a decision based solely on whether
> >        it trusts the identified controller -- whether or not the
resource
> >        is designed for first or third party use is irrelevant if the
controller
> >        is trusted (to somehow comply) with DNT:1, and even less relevant
if
> >        the controller isn't trusted.
> >
> >    (c) the listing service will make a decision for the browser,
regardless
> >        of the first or third party status.
> >
> >>> 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.
> > It is always harmful to send bytes that aren't used.  In particular, the
1/3
> distinction is the main source of variance in the TSR response, which
means it
> effects both the likelihood of simple static implementation and the
cacheability
> of the TSR verification result.  If there is no 1/3 flag, then the vast
majority of
> servers (both first and third party) can use a single TSR for their entire
service.
> >
> >>> 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’.
> > There has been no interest shown by browsers in presenting information
to
> their users, regardless of what the response might be. A user is going to
be
> 'flying blind', no matter how we specify the response, unless they use
special
> tools or extensions for discovery.  What the response does provide is a
> statement of business practice that can be inspected by such concerned
users,
> advocates, and regulators independent of any specific request.
> >
> > In terms of verification features, it would be far more useful to active
users for
> a tool to obtain the TSR for all page components and color code (or graph)
them
> by controller/owner identification.  The user can then find the identity
that they
> intended to interact with, see all the other parties that are not the
same, and
> make their own decisions about which ones are intended and which are not.
> >
> > In contrast, the cost and risk of reporting how each specific resource
has been
> designed to operate are very real concerns for site operators.  It is
fairly easy for
> a data controller to say that they will turn off all tracking (i.e.,
discard any data
> about user activity in contexts other than their own first party contexts)
for
> requests with DNT:1.  It is much harder for them to consistently identify
and
> categorize each and every resource on an origin server.
> >
> > Hence, I don't think the merits of a tracking status value for 1/3 come
> anywhere near to justifying its cost, both in terms of getting consensus
on TPE
> and in getting implementations of the protocol in practice.  If there is
ever a
> need for that information as a means of explaining compliance, then it can
be
> included in a qualifier along with all of the other explanations of
compliance.
> >
> >
> > Cheers,
> >
> > Roy T. Fielding                     <http://roy.gbiv.com/>
> > Senior Principal Scientist, Adobe   <https://www.adobe.com/>
> >
> >
>

Received on Saturday, 18 January 2014 20:15:06 UTC