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> 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>
> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org> 
> Cc: "public-tracking@w3.org (public-tracking@w3.org) (public-tracking@w3.org)" <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> 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

Received on Wednesday, 25 January 2017 12:46:37 UTC