RE: Batch closing of TPE issues (Deadline: December 03)

As long as "narrowing the initial scope to web browsers only" results in the TPE staying silent on entities outside the web browser or servers, or does not further restrict the implementation approaches beyond what the current TPE states, I am OK with it. I think any further restrictive text is unnecessary and technically unreliable in any case.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: Wednesday, December 04, 2013 7:51 PM
To: Mike O'Neill; SULLIVAN, BRYAN L; Brad Kulick; 'Matthias Schunter (Intel Corporation)'
Cc: public-tracking@w3.org
Subject: RE: Batch closing of TPE issues (Deadline: December 03)

Mike - v2 offers many opportunities to expand scope and include interesting edge cases.

Industry needs time to manage DNT implementations in a well understood and expected set of circumstances.  As web browsers represent the vast majority of intended network interactions under which DNT was envisioned, we'll be better served to isolate v1 to this universe.  

Those opposing this concept don't appear to represent actual implementers on the Server-side, so I'd ask if anyone on that side disagrees with narrowing the initial scope to web browsers only.

THE largest barrier to progress in this effort, in my personal opinion, has been the unnecessary attempts to solve all online privacy issues in a single pass.  Had we been more open to taking a narrowed approach to version 1 of the standard, we'd likely have been completed by now, have working implementations live in the marketplace (on all sides), and be discussing how best to leverage these experiences into v2 of DNT.

I urge the group to reconsider this position.  Let's save toolbars, routers/access points, dog collars, and ISP generated DNT signals for v2.  A broader scope here will likely ensure few to no one on the server-side implements this standard as there would be too many unknowns to provide certainty for businesses to embrace DNT.     

- Shane

-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Wednesday, December 04, 2013 12:01 PM
To: 'SULLIVAN, BRYAN L'; Brad Kulick; 'Matthias Schunter (Intel Corporation)'
Cc: public-tracking@w3.org
Subject: RE: Batch closing of TPE issues (Deadline: December 03)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1. A DNT capable home router (whole house, multiple device) is very 
+imaginable. It might be tricky (though not impossible) to allow 
+exceptions using the UGE but this use case underlines the need for a 
+non-JS mechanism to be discussed for DNT2.0

Mike


From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
Sent: 04 December 2013 16:20
To: 'Brad Kulick'; Matthias Schunter (Intel Corporation)
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: RE: Batch closing of TPE issues (Deadline: December 03)

While it may seem to narrow down the scope to a manageable set of variables, limiting DNT to browsers only, and specifically to the browser code as shipped in a specific web browser product, neither:
Reflects reality, e.g. as
a wide range of products exist in the market today to augment the user experience – most with the explicit knowledge of the user or the party responsible (by choice of the user) for the user’s secure/private service in a particular internet service domain, and these products will implement DNT as they implement a range of other security/privacy/policy-enabling functions there are far more Web applications in terms of number as installed on user devices, that are packaged as hybrid apps using various SDKs, and these apps are getting more general-purpose e.g. relying upon arbitrary 3rd-party content and advertising services, all the time Is in the end any simpler, reliable, or “comprehensible” (from a UX perspective) It is not simpler for the user to have to manage DNT preferences, distinctly in every device/app that they use.
That DNT preferences management burden across devices will lead to inconsistent settings as users will find it difficult to remember whether or how they have set DNT for each site/party across all these devices. Further, when the browser is reset, DNT preferences are likely to be lost and represent another resync burden on users, which will be inconsistently applied.
It will be much more difficult for users to understand why they have to manage these preferences (for themselves and others under their responsibility) in so many places, as compared to establishing one set of preferences that are applied by their:
Software plugins installed in all their devices Home gateways, proxies, etc Network service provider

If there need to be technical solutions to ensure that at some point in the preferences establishment/management process, the user or someone to whom they have delegated their privacy preferences management to, actually invoked the particular setting as expressed, then that’s fine and should be considered in a future work of W3C. In the short term, I do not see that as needed because:
many existing capabilities are invoked by agents of the user (e.g. the list above) without any technical non-repudiation assertions these things are considered valuable by users without any specific  assertion of authenticity web service providers are not rejecting affected transactions due to lack of trust in the source

Thanks,
Bryan Sullivan 

From: Brad Kulick [mailto:kulick@yahoo-inc.com]
Sent: Wednesday, December 04, 2013 7:09 AM
To: Matthias Schunter (Intel Corporation)
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Batch closing of TPE issues (Deadline: December 03)

Matthias,

The main concern is about creating a system that provides “certainty” to the ad ecosystem to develop trust in DNT.  To provide the best possible chance for DNT to survive and thrive as a broadly implemented standard, we should start small and in well understood and expected areas – in this case that means with Web Browsers in isolation. I acknowledge that this removes some “interesting use cases” but that is understood and purposeful to reduce the number of variables and entry points into the system. 

Thanks,

Brad

On Dec 3, 2013, at 2:16 AM, Matthias Schunter (Intel Corporation) wrote:

Hi Brad,


thanks a lot for this input. I will keep ISSUE-153 open for now and we can discuss it tomorrow.

My reading of your proposed change is that you want to ensure that only user agents themselves can transmit preferences. It would disallow anyone else to send DNT headers _even if this entity follows our requirements_.

IMHO this would exclude some interesting scenarios:
- - A plugin synchronising preferences of a user between devices / browsers.
- - A intermediary service where I can manage my privacy preferences (e.g., a control panel in the OS)
- - A trust management plugin for browsers where DNT;1 is only sent to selected blacklisted sites (or any other
  policy that is more advanced than the default policies of user agents).
...

For me, the requirement that all requirements must be met in order to gain permission to modify DNT headers is indeed important. This is clearly not the case for some of the tools today.

Could you elaborate your concerns, i.e., why you want to exclude other entities from managing preferences - even if they adhere to our requirements?


Regards,
matthias




Am 21.11.2013 22:04, schrieb Brad Kulick:
Matthias,

I respectfully request we keep Issue-153 open.  We’re fine with closing the rest of the issues you’ve recommended.

To Issue-153, we believe intermediaries should *not* be allowed to alter the tracking preference in version 1.0 and to reserve this interaction between the user and web browser for now.  We believe this will result in a simpler implementation path through well-known interfaces and gives everyone time to gain real-world experience to consider how best to incorporate intermediaries altering signals in transit.

In Section 3 of the TPE, we should change the following text:

“Likewise, a user agent extension or add-on MUST NOT alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that tracking preference.”

- -to-

“Likewise, a user agent extension or add-on MUST NOT alter the tracking preference.”

Thanks,

Brad

On Nov 14, 2013, at 1:10 AM, Matthias Schunter (Intel Corporation) wrote:

Hi Folks,


while we are working on the new issues, I suggest we close the set of TPE-related issues that have been PENDING REVIEW for many months. These document the outcome of our former discussions on TPE where we reached a conclusion that resulted in text. For each of those issues, the text resolving the issue is already included into the TPE spec (and has been there for a long time).

Please: Validate that you can live with the resolution of the enclosed issues (Deadline: December 03).

In case you want to object to closing an issue, please provide the required documentation (see "the plan"), i.e., roughly you should say why the issue cannot be closed, what concern you have that is not addressed, and what alternative text you proposed to mitigate your concern.


Thanks a lot!

matthias

- --------------8<------------------
http://www.w3.org/2011/tracking-protection/track/issues/137

ISSUE-137: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)

http://www.w3.org/2011/tracking-protection/track/issues/153

ISSUE-153: What are the implications on software that changes requests but does not necessarily initiate them?

http://www.w3.org/2011/tracking-protection/track/issues/161

ISSUE-161: Do we need a tracking status value for partial compliance?

http://www.w3.org/2011/tracking-protection/track/issues/164

ISSUE-164: To what extent should the "same-party" attribute of tracking status resource be required

http://www.w3.org/2011/tracking-protection/track/issues/168

ISSUE-168: What is the correct way for sub-services to signal that they are taking advantage of a transferred exception?

http://www.w3.org/2011/tracking-protection/track/issues/195

ISSUE-195: Flows and signals for handling "potential" out of band consent

http://www.w3.org/2011/tracking-protection/track/issues/197

ISSUE-197: How do we notify the user why a Disregard signal is received?




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/

Charset: utf-8

iQEcBAEBAgAGBQJSn1/VAAoJEHMxUy4uXm2JaroH/jIO849Uqsc9hX7eOT97Gk3O
kVnoyw6VVsKkFEkU2ergSguAYBTMkjRcut6fVsUOSkSBY+k7xLjPGHQpQLHAo5zI
6l+Bc4D1navwtOAZITR94oF8cY8JiKB++VRE5/YadQ+ZKO1e4BFbwQdGatKIMFgd
ckLKMlxHTlg5sBRHGN7B7i6cBGqGSoGVjNImx6yUZMOr33iBl+tVgxxR8f84Kwj3
9gD5DR1O/3d6hrWpUxisSZu+E+1SABEi3KKxMiXrbqaTb4hKlEfHr6MnDIleLz5t
styUsJ3H3xjj2Pl3t8yOeHVAHEVlMBFPHWyoFhEKkZVguoQ0w9F7d94RdOG7wuA=
=ehoT
-----END PGP SIGNATURE-----

Received on Thursday, 5 December 2013 07:50:58 UTC