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

Hi Matthias,

Good summary. I agree the "pretending to support DNT" issue makes it a tricky trade-off between ease of implementation and confirmability.

The status-id extension (to the Tk header) allows for multiple TSRs so maybe that’s enough. In the "wordpress" use case the hosting site could support different status-ids for its customers, who could qualify the default TSR by supplying a status-id in the http-equiv="Tk" tag if need be.

The big brand sites can handle the logistic problem by doing redirects, which is not that hard (though a bit harder than the way it is done ATM).

So I agree with your compromise.

Mike


-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 23 January 2017 18:16
To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Supporting TPE on sites/subdomains where a user does not have control of the server (ISSUE 15, ISSUE 10)

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:57:25 UTC