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

Hi Shane,

I agree with your concerns but not with your solution. 

The thing is, Wordpress cannot know what my hosted page is doing with data I collect from my DNT visitors. Only I know that. So Wordpress cannot speak on my behalf because they do not know enough. 

I agree that there could be multiple http-equiv’s per page. That’s feature, so long as we don’t introduce conflicts. I think we need some sense of scope. That’s why I suggested a very clear and tightly-bound name for who asserts what.

Here’s a real world example of what happens if we do not solve this. With P3P, a company hosting webpages set P3P Compact Policies en mass for all of their hosted pages. That turned out not to reflect the disparate data practices of the hosted pages, as you might well expect. (Was that Yahoo! actually?)

Having the platform speak for the publisher runs into real trouble, potentially legally. If we had one meaning for DNT… ah, but we do not. So given that reality now, I think the only path is to let each party speak only for that party. Similarly, you would not want first parties to make promises for their third parties. It just wouldn’t make sense.

A solution that avoids conflicts is key. I’m with you 100% there. But I am not yet convinced there would be conflicts, any more than a dozen third parties would pose conflicts. They have different practices, that’s all.

 Aleecia

> On Jan 23, 2017, at 11:13 AM, 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 <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.
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
>