Re: Supporting TPE on sites/subdomains where a user does not have control of the server (ISSUE 15, ISSUE 10)

Hi Folks,


the current solution in the TPE works as follows:

1 - The platform has the final say and defines all policies (it may
naturally collaborate with its customers to do so)

2 - The platform can define and publish one or more policies at the
well-known location (under different IDs). E.g.

    /well-known/.../     contains the default policy in a Tracking
Status Resource
    /well-known/.../ID1/  contains an alternative TSR with policy for
pages that are static without javascript and no tracking
    /well-known/.../ID2/ contains another alternative TSR with policy
for pages that use tracking/cookies/whatever

3. The Tk header then may include an ID to pick one of the posted policy
options.


We seem to agree that (1) should not be changed since only the platform
can give a definitive answer to the tracking behavior. Some pages alone
would not know what else may happen in the server.

The only discussion that remains open is whether to give a page the
option to transmit (3) via http-equiv instead of using a header.
IMHO this is no fundamental change to the scheme from a privacy
perspective and potentially increases usability/managability.I have not
heard any substantiated objection against allowing this choice (as long
as the Tk header overrides the http-equiv).

Any input?


Regards,
matthias



On 25.01.2017 23:44, Shane M Wiley wrote:
> Mike,
>
> To David's point, I don't believe the user of a publishing platform
> would be able to speak for the publishing platform itself - they are
> two different entities - likely with different data collection and use
> practices - and possibly differing views on DNT.  Depending on how
> locked down a publishing platform is though, it may be able to speak
> for its publishers.  Allowing http-equiv would create legal risk for
> the publishing platform if this was somehow misinterpreted as speaking
> for their position.  For example, if the user of a publishing platform
> (publisher) were to post an http-equiv does that reflect on the
> platform itself if the publishing platform hasn't already added a WKR
> itself?  
>
> In reality I believe BOTH the publishing platform's POV and the user
> of the publishing platform's POV will need to be presented together in
> a COORDINATED fashion such that the resulting response to the user is
> cohesive and harmonized.  As I've stated before I believe this could
> only truly be accomplished by the publishing platform offering a
> configuration option to its users to facilitate that coordination.
>  Having a header WKR trump an http-equiv WKR (or vice versa) doesn't
> make sense to me as it's likely the blend or some additive outcome is
> the true reality for the end user.
>
> - Shane
>  
> Shane Wiley
> VP, Privacy Policy
> Yahoo
>
>
> ------------------------------------------------------------------------
> *From:* Mike O'Neill <michael.oneill@baycloud.com>
> *To:* 'David Singer' <singer@mac.com>; public-tracking@w3.org
> *Sent:* Wednesday, January 25, 2017 2:26 PM
> *Subject:* RE: Supporting TPE on sites/subdomains where a user does
> not have control of the server (ISSUE 15, ISSUE 10)
>
> Hi David,
>
> The WKR issue is covered by Matthias's compromise, i.e. the status-id
> can be used to point to a hostee specific TSR at WKR/{status-id}
>
> Sure if the host site has to support multiple TSR's for its customers
> they could also invent a protocol for (dynamically) injecting the
> response header, but that is quite hard and it's yet another thing
> they would have to do.
>
> The http-equiv option makes it a lot easier and also solves the
> independent use case of letting many more sites comply with the TPE
> (where they have to return a response header for OOBC for example)
>
>
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com <mailto:singer@mac.com>]
> Sent: Wednesday, January 25, 2017 1:46 PM
> To: public-tracking@w3.org <mailto:public-tracking@w3.org>
> Subject: Re: Supporting TPE on sites/subdomains where a user does not
> have control of the server (ISSUE 15, ISSUE 10)
>
> I agree with the two comments:
>
> a) the WKR allows pre-flighting and exploration by researchers; it has
> a protection that we say access of the WKR must not be tracked. 
> Embedding it in the header information for a fetch of unknown status
> is not good.
>
> b) that hosted sites ARE under control. If you want to build a
> DNT-respecting site hosted by a provider, I don’t think you have any
> choice but to know how to do that with the provider. Perhaps you need
> configuration options, perhaps a new contract, perhaps a new
> provider.  But working with the provider is not optional; you’ll not
> be able to make any solid claims otherwise.
>
> Note that we *do* allow the status to vary by path (one of the
> permitted dynamisms).  The global WKR has a status of ‘dynamic’ and
> then section 6.3.2 applies.  It’s not ideal, as the static (untracked)
> WKR tells us very little, and you have to do an actual fetch to get
> the correct WKR — but this is no worse (and not very different) from
> the solution being proposed.
>
> Again on the http-equiv, I am unsure. If the hosting provider
> explicitly supports DNT or choice of DNT regime, one would assume
> they’d also tell the hosted sites how the DNT response header can be
> triggered.
>
> So, do we really have a problem?  I think the current spec. covers
> this situation as well as the proposed solution, and has the advantage
> of being already in place.
>
>
> > On Jan 23, 2017, at 21:13 , Shane M Wiley <wileys@yahoo-inc.com
> <mailto:wileys@yahoo-inc.com>> wrote:
> >
> > I'm not supportive as a publisher who has this very specific issue. 
> > The Working Group originally introduced the Well Known Resource
> > Location as a way for users (and regulators) to view a site's position
> > on DNT PRIOR to visiting the site and this breaks that model.  It also
> > introduces race conditions and conflicts between the owner of the
> > platform (Wordpress in Mike's example) and the users of that content
> > platform (exampleblog.wordpress.com).  It also introduces the
> > technical reality of possibly having multiple HTTP-equiv responses on
> > the same page - creating further confusion and race conditions.
> >
> > Would it be possible to look at other options that could be hosted by
> > the parent domain owner?  This would convey a more "real-world" view
> > as it would better blend the platform owner's own data collection and
> > use practices which those they extend to users of that platform.
> >
> > Attempting to divorce the two is definitely going to introduce
> > complexity and unfortunate confusion for users.  I agree that we
> > should provide some publishing platform supporting concepts but let's
> > not destroy the original value we sought when introducing the well
> > known resource location in the first place.
> >
> > - Shane
> >
> > Shane Wiley
> > VP, Privacy Policy
> > Yahoo
> >
> >
> > From: Aleecia M. McDonald <aleecia@aleecia.com
> <mailto:aleecia@aleecia.com>>
> > To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org
> <mailto:mts-std@schunter.org>>
> > Cc: "public-tracking@w3.org <mailto:public-tracking@w3.org>
> (public-tracking@w3.org <mailto:public-tracking@w3.org>)
> > (public-tracking@w3.org <mailto:public-tracking@w3.org>)"
> <public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > Sent: Monday, January 23, 2017 10:52 AM
> > Subject: Re: Supporting TPE on sites/subdomains where a user does not
> > have control of the server (ISSUE 15, ISSUE 10)
> >
> > Welcome, Bert Bos. I’m sorry to have dropped off the call mid-way and
> > missed this discussion.
> >
> > I really like the idea of using http-equiv here. In this scenario it
> > seems to me we want DNT responses from both parties, both the host and
> > the controller of the subdomain (or similar.) I wonder how well a user
> > agent can present all of the information to the user. But UI is out of
> > scope so that is someone else’s problem. :-)
> >
> > We might need to add a field to the http-equiv that’s basically the
> > name of the entity making the commitment? We might also somehow
> > capture the notion that while I am stating my policy, it is not the
> full picture.
> > (Perhaps the very existence of the entity name is sufficient to convey
> > that.) I can only tell users what my little part of the world does or
> > does not do, which holds if I am WordPress or if I am a
> WordPress-hosted site.
> >
> >    Aleecia
> >
> > > On Jan 23, 2017, at 10:15 AM, Matthias Schunter (Intel Corporation)
> > > <mts-std@schunter.org <mailto:mts-std@schunter.org>> wrote:
> > >
> > > Hi TPWG,
> > >
> > > today, we discussed how to resolve ISSUE10 and 15.
> > > I discussed our pros and cons below. My proposed resolution is:
> > > (A) We only allow TSR at the well-known resources to ensure
> > > discovery in one location and also before visiting a URL. It also
> > > ensures that a page owner cannot "pretend" to do DNT without
> support of the server admins.
> > > The server admins can allow users to post their TSR under given IDs.
> > > (B) We allow http-equiv to be used to deliver the header. This
> > > simplifies deployment and allows a page owner to add an ID that
> > > identifies the policy that it used.
> > >
> > > Below is my detailed arguments. Any feedback/opinion/pojnts I missed?
> > >
> > > Regards,
> > > matthias
> > > -------------------
> > >
> > >
> > > SCENARIO
> > > The scenario is that you use a subdomain / some pages / .. on a
> > > server that you do not fully control.
> > > E.g. a hosting provider, wordpress, tumblr, ...
> > > You want to support DNT on your pageswithout requiring the server
> > > admins to actively help.
> > > MIKE PROPOSAL
> > > - Header:  Page owner is allowed to deliver DNT header via
> > > http-equiv
> > > - Tracking Status: Instead of using a well-known resource,
> > > http-equiv could also point to a URL  that points to the tracking
> > > status resource.
> > >
> > > DISCUSSION
> > > - PRO
> > >  + Allows page/subdomain owners to support DNT without explicit
> > > support of server admins
> > >
> > > - CONTRA
> > >  - Without any server support, a page owner cannot know whether the
> > > server tech stack indeed
> > >    implements the desired policies (e.g. logging/cookies/retention
> > > could still continue)
> > >  - Discoverability is limited since each page could publish its own
> > > policy
> > >  - If a Tracking Status Resourfce is published at the well-known
> > > URL, this may be superseded /conflicted with a page-policy
> > >
> > > DISCUSSION 1: TSR / we-known URI
> > > * Without any server support, pretending to support DNT is not
> > > soundly possible => Consequence: We have to assume that the server
> > > helps
> > > * If the server helps, the server admins could allow posting TSRs
> > > under different IDs under the well-known URI
> > > * Then the header can point to one of those IDs.
> > >
> > > DISCUSSION 2: Support for headers
> > > * If a user has only HTML access, then it is hard to send headers.
> > > * In this scenario, a http-equiv would simplify delivery of the DNT
> > > signals
> > >
> > > PROPOSED RESOLUTION
> > > - We continue to require TSR to be posted under an ID at the
> > > well-known resource
> > >    - Better discovery
> > >    - Ensures that the server admins cooperate
> > > - We allow http-equiv delivery of the header for a particular page
> > >    - Simplifies deployment
> > >    - Allows pages to set their ID
> > >    - Proposed conflict resolution: Header overrides http-equiv since
> > > the header is more likely to come from the server owners.
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
> Dave Singer
>
> singer@mac.com <mailto:singer@mac.com>
>
>
>
>
>