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

Hi Folks,


as far as I know, the current solution works as follows (and requires a
collaboration between wordpress and hosted page):

- Wordpress publishes a range of tracking status resources under a range
of IDs

    - ID1 = potential behavior 1 by Aleecia

    - ID2 = potential behavior 2 by Matthias

This makes the total range of policies discoverable at one location.


A hosted page then either

(a) works with Wordpress to ensure that its Tk: header includes the right ID

or (new: b) would include an http-equiv that contains this header that
points to the correct ID.

If (a) and (b) would be used in parallel, my understanding is that the
header should override the http-equiv (but I do not have a strong
opinion here).


IMHO this would work. Note that one cannot solve the problem that a
hoster (wordpress) sets bogus policies for all content. After all he
controls the server and the page owner is fully under control of the
hoster. As a consequence, there is no way to prevent such behavior.


Regards,

 matthias

On 24.01.2017 03:24, Aleecia M. McDonald wrote:
> 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
>> <mailto: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
>> <http://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
>> <mailto:aleecia@aleecia.com>>
>> *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org
>> <mailto:mts-std@schunter.org>>
>> *Cc:* "public-tracking@w3.org <mailto:public-tracking@w3.org>
>> (public-tracking@w3.org <mailto:public-tracking@w3.org>)
>> (public-tracking@w3.org <mailto:public-tracking@w3.org>)"
>> <public-tracking@w3.org <mailto: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.
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>