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

Sorry folks, I was dumped from the meeting by my ISP who seems to have had a "network level event".

Aleecia, I think the identity name should be there, but maybe in the TSR? Every site that claims to comply with DNT has to have a TSR, according to the TPE.

There is already a "controller" URI in there but this just points to a undefined human readable webpage. It would be good to have a "controllerName". Just a simple string saying e.g. "Yahoo Inc." would do it.







-----Original Message-----
From: Aleecia M. McDonald [mailto:aleecia@aleecia.com] 
Sent: 23 January 2017 18:53
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>
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.
> 
> 
> 
> 
> 
>

Received on Monday, 23 January 2017 19:32:49 UTC