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

David,

We are no longer talking about returning the TSR (i.e. WKR) in a Tk header. 

We are just talking about the existing TPE defined TK header delivered in a meta tag.

This is needed because otherwise a significant proportion of sites will not be able to comply with the TPE when they need to establish OOBC (they have to respond with Tk: C). If we do it we also get for free different hosted site TSRs (with a bit of help from the hosting site), without any further change to the TPE.

We don't need to get 
https://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv

changed. CSP 2.0 is a full Rec. and they did not do it. CSP is deliverable by meta tag https://www.w3.org/TR/CSP2/#delivery-html-meta-element , and this is supported by all major browsers now, it's been in Chrome for 2 yrs with no problems AFAIK.

As for the "danger", I do not see it. If the hosting site tracks its customers users this is of course a problem, but that’s is up to them both and needs to solved contractually anyway. It has nothing to do with the DNT protocol.

Remember a hosted site is perfectly able to track its users without the involvement of the host, by returning JS that writes to document.cookie. It can also inject arbitrary third-parties by embedding them in content.


-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Thursday, January 26, 2017 7:34 AM
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: Shane M Wiley <wileys@yahoo-inc.com>; 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)


> On Jan 26, 2017, at 1:14 , Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
>
> Hi Shane,
>
> I think you misunderstand the compromise position.
>
>
> There is no TSR supplied in the Tk header, http-equiv supplied or not.
>
> There is a dynamic status-id which can point to the particular 
> customer’s TSR (managed by the publisher), but that is already described in the TPE.
>
> The only new feature is no allow the Tk header in a meta tag, which 
> absolutely does not create confusion or hint at an additive outcome. 
> If the header exists the meta tag is ignored, this is very clear.

I still don’t get why this is needed, and I think it’s dangerous; it allows a hosted site to claim/pretend to support DNT without the cooperation of the hosting organization.

Fiddling with http-equiv means we have to ask for a change to <https://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv>

Do we have a hosting provider saying that they can’t work out a way to provide custom WKRs for their hosted sites?

>
>
>
> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
> Sent: Wednesday, January 25, 2017 11:45 PM
> To: Mike O'Neill <michael.oneill@baycloud.com>; 'David Singer' 
> <singer@mac.com>; 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)
>
> 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]
> Sent: Wednesday, January 25, 2017 1:46 PM
> To: 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> 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
>

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 26 January 2017 23:29:36 UTC