RE: Action 31 - Propose a user-agent managed site-specific exception

Andy,

Thank you for the quick response.

I believe a Cookie is one possible way for management (would be vulnerable to cookie purges either by the user or by Anti-Spyware vendors - similar issue with opt-out cookies today) but there will be some technical situations where cookies are not accessible: feature phones and some app environments (Connected TV), for example, which is why I asked that the standard not be overly technically perspective on these elements.  Perhaps Cookies are put forth as the "Recommended" approach with guidance for non-cookie enabled environments.

- Shane

From: Andy Zeigler [mailto:andyzei@microsoft.com]
Sent: Monday, November 14, 2011 11:33 AM
To: Shane Wiley; Tracking Protection Working Group WG (public-tracking@w3.org)
Subject: RE: Action 31 - Propose a user-agent managed site-specific exception

Great points Shane - thanks for the feedback.

There's definitely the potential for a hybrid solution. For example, on the first two points you mention:


*         User able to retract exceptions outside of direct contact with a specific 3rd party

*         User able to see all of the exceptions granted to date

For example, if the exception is managed via a known cookie format, it would be straightforward for a user-agent to list out those exceptions and let the user revoke an exception via deletion of the cookie.


*         Exception list could be used to help manage 1st party/3rd party granted exceptions (for example, PublisherXYZ requests an exception for their site and the 4 3rd parties they work with in exchange for free content.  The exception list would be able to tie the exception for that 3rd party only in the context of this 1st party.

This is where I think things start to get complex, both technically and from a policy perspective. Rigo and other folks can weigh in here, but I think this would require re-inventing a lot of work that was done with P3P that would require sites to map business relationships onto domain names. Do you agree, or do you see a simple way of doing this?


*         Enables external audits (remove entry from list - look at header response code for correct behavior)

I think if I understand your point on this one, this would also be achievable with a site-managed cookie approach.

Thanks,

Andy


From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: Sunday, November 13, 2011 2:20 PM
To: Andy Zeigler; Tracking Protection Working Group WG (public-tracking@w3.org)
Subject: RE: Action 31 - Propose a user-agent managed site-specific exception

"The primary benefit of having a user-agent-managed list of exceptions would be for the user-agent to be able to "enforce" opt-ins by managing requests from tracking entities. I think this is basically wasted work..."

I believe there are many benefits to a browser managed list of exceptions:

*         User able to retract exceptions outside of direct contact with a specific 3rd party

*         User able to see all of the exceptions granted to date

*         Exception list could be used to help manage 1st party/3rd party granted exceptions (for example, PublisherXYZ requests an exception for their site and the 4 3rd parties they work with in exchange for free content.  The exception list would be able to tie the exception for that 3rd party only in the context of this 1st party.

*         Enables external audits (remove entry from list - look at header response code for correct behavior)

- Shane

From: Andy Zeigler [mailto:andyzei@microsoft.com]<mailto:[mailto:andyzei@microsoft.com]>
Sent: Friday, November 11, 2011 5:28 PM
To: Tracking Protection Working Group WG (public-tracking@w3.org<mailto:public-tracking@w3.org>)
Subject: Action 31 - Propose a user-agent managed site-specific exception


So I volunteered for the action "Propose a user-agent managed site-specific exception". A few of us over here sat down and figured out a couple of ways of doing this, but I think that this approach is fundamentally flawed, and I think a website-based approach in Action 32 is better for a variety of reasons.



Namely, it would be an awkward user experience if the user-agent injects itself into the opt-in process. This approach would essentially require a protocol that associates domains with business entities. I think that "what" a user opts-into and which resources on the page are included in that opt-in are much better managed by the sites that include them.



There are other issues here:



-          For example, imagine that I belong to a social network, and I opt-in to tracking. The user-agent stores the domain name of network. Now I'm on a different website, and the same social network operates a "like" button on the page. Should the exception carry over? These types of issues are much better handled by the websites that have business relationships with tracking entities, and there are scenarios where this becomes very difficult to jam into a protocol without adding a lot of technical complexity.

-          The primary benefit of having a user-agent-managed list of exceptions would be for the user-agent to be able to "enforce" opt-ins by managing requests from tracking entities. I think this is basically wasted work - if a tracking service is not DNT-compliant, then they won't bother requesting that the user opt-in - they'll just track the user directly, rendering user-agent enforcements useless.



Thanks,



Andy