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

Hi,

The spec just need to be clear on which signal trumps what in which 
case. We have been there before and worked it out.

Rob

Mike O'Neill schreef op 2017-01-24 19:18:
> Roy,
> 
> CSP gets delivered via meta http-equiv="csp"
> 
> https://www.w3.org/TR/CSP2/#delivery-html-meta-element
> 
> for same reasons. If the response header is there the meta tag gets
> ignored. Allowing the option lets a hosted site return a status-id (in
> a meta tag) then that can point to controller specific TSR, and also
> lets it claim Tk: C for OOBC if the API isn’t there. As long as the
> tag gets ignored if the header is already there makes it fine IMO
> 
> Mike
> 
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: Tuesday, January 24, 2017 12:52 AM
> To: Mike O'Neill <michael.oneill@baycloud.com>
> Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.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)
> 
> It is simply impossible for a page owner to state anything about DNT
> compliance without having the ability to control HTTP responses at the
> header and resource level. Likewise, placing it in an HTML response
> means the information will be received after it is useful. At best, it
> could be farmed by spiders, much like the "owner" link relation that I
> created back in 1993.
> 
> If you want to provide information about the resource owner within an
> HTML response, then use a link header field with a defined link
> relation. This can be added without changing TPE. Note, however, this
> doesn't have any meaningful impact on the protocol because sites don't
> track using HTML pages.
> 
> Personally, I still don't consider the issue to be a relevant concern.
> The goal is to provide actionable information that is relevant to
> future requests. HTML metadata rots quickly and is often cut and
> pasted to unrelated sites.
> 
> ....Roy
> 
> 
>> On Jan 24, 2017, at 4:56 AM, Mike O'Neill
>> <michael.oneill@baycloud.com>
>> wrote:
>> 
>> 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 Tuesday, 24 January 2017 19:24:45 UTC