There are two acceptable paths forward in my opinion:
1) The spec txt remains as is, putting choice in the user's hands as to what devices/software/etc they use for DNT
2) The spec remains silent on anything but browsers, i.e. there is no blanket prohibition on other approaches - the "we'll address that later" approach
Re DPI I don't know why that was included other than snarkiness (I have no knowledge of what you're referring to, and don't think this is the appropriate place in any event to be referencing such things), but I'll let it pass.
Thanks,
Bryan Sullivan
-----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: Thursday, December 12, 2013 10:52 AM
To: SULLIVAN, BRYAN L; Mike O'Neill; Brad Kulick; 'Nicholas Doty'
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: Issue 153
Bryan,
You're describing a bit of a chicken/egg issue in that you're suggesting we have a platform privacy API ahead of ubiquitous installation of connected refrigerators. I'm not suggesting we won't expand to this level of coverage, I'm simply suggesting for version 1.0 that we keep the scope purposely narrow to:
1) Reduce the number of edge cases we're attempting to solve without experience
2) Increase confidence that signal generation is understood and can be trusted
3) With the above elements in place, increase the likelihood of voluntary implementation on the Server side
With broad implementation of v1, we'll be well positioned to advance the scope of coverage and with experience in-hand, develop methods to maintain a balanced approach as we include more and more edge-cases. As such, providing network device or ISP level controls should not be within scope of v1.
That said, AT&T's new ad network that operates through deep-packet inspection should be able to honor DNT requests generated at the browser level.
- Shane
-----Original Message-----
From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
Sent: Thursday, December 12, 2013 11:42 AM
To: Shane M Wiley; Mike O'Neill; Brad Kulick; 'Nicholas Doty'
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: Issue 153
Shane,
Most parental control solutions come in the form of add-ons or home gateways. I am not aware of platforms that embed these things (examples are welcome) but I would expect that only the platform-default browsers are designed to work with such controls (counter examples also welcome). I have earlier called for system-level APIs (as part of SysApps work) that consistently expose platform level privacy settings, but that work has not started.
Thus, depending upon the diversity of browsers that can be installed on a platform to implement access to platform privacy APIs (where they exist) is a questionable strategy for a consistent and usable UX. Having to do so as well across laptops, desktops, tablets, smartphones, TVs, refrigerators, ... for all the users in one's domain is clearly not scalable from a user or parental perspective. So the presence of platform APIs is not an adequate mitigation, until those platform features and APIs are ubiquitous, consistently accessed by web user agents, and manageable remotely (e.g. to allow easy sync of preferences). Until that happy day happens, and even beyond for some users/contexts, the role of intermediaries of all types will be an important one.
Thanks,
Bryan Sullivan | Service Standards | AT&T
-----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: Thursday, December 12, 2013 8:11 AM
To: Mike O'Neill; Brad Kulick; 'Nicholas Doty'
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: Issue 153
Mike,
A parent can override all signals at the device. An entire industry has been built around parental controls with many operating systems and some browsers coming with these built in. There is no need for an intermediary.
- Shane
-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
Sent: Thursday, December 12, 2013 6:18 AM
To: Brad Kulick; 'Nicholas Doty'
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: Issue 153
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I strongly object to this text. It would rule out intermediaries being even able to override DNT unset which would, for example, make it impossible for a parent to override deemed consent never mind consent erroneously obtained from a child.
Mike
From: Brad Kulick [mailto:kulick@yahoo-inc.com]
Sent: 12 December 2013 12:18
To: Nicholas Doty
Cc: Matthias Schunter (Intel Corporation); public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Issue 153
Nick,
To make this proposal more clear, I have updated it. Along with clarifying the what to remove/alter I have added some non-normative text might be helpful per yesterday's discussion.
Thanks,
Brad
Existing text
- ----------------------------------------------------------------------------------------
A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as "SuperFred", but might imply a preference if invoked as "SuperDoNotTrack" or "UltraPrivacyFred". 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.
A user agent extension or add-on must not alter the user's tracking preference setting unless it complies with the requirements in this document, including but not limited to this section (Determining a User Preference). Software outside of the user agent that causes a DNT header to be sent (or causes existing headers to be modified) must not do so without ensuring that the requirements of this section are met; such software also must ensure the transmitted preference reflects the individual user's preference.
- ----------------------------------------------------------------------------------------
New text
- ----------------------------------------------------------------------------------------
A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as "SuperFred", but might imply a preference if invoked as "SuperDoNotTrack" or "UltraPrivacyFred".
A user agent extension, add-on, or software outside of the user agent must not alter the tracking preference.
Non-normative:
User agent plug-ins and add-ons as well as software outside of a user agent are under continued review for future addition, whereby recognized limitations affecting a balanced implementation can be addressed.
- ----------------------------------------------------------------------------------------
On Dec 11, 2013, at 6:51 AM, "Brad Kulick" <kulick@yahoo-inc.com> wrote:
Nick,
You are correct. Removing "Likewise" would be suffice. But Given the paragraph that following we would want to add intermediaries as well. Therefore, it would be:
"A user agent extension, add-on, or software outside of the user agent must not alter the tracking preference."
Also, the paragraph following it would need to be altered to remove or sync with the above.
Thanks,
Brad
On Dec 8, 2013, at 11:43 PM, Nicholas Doty wrote:
I've set up a wiki with what I believe are the two proposals (the existing text which was the basis for sometime and for the batch closing period; and Brad's alternative to remove the "unless" clause).
http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_limitations_for_add-ons
Brad, we might want to clarify the wording of your suggestion: the sentence begins with "Likewise", but I believe you're proposing a different result (prohibition, rather than explicit choice) for user agent extensions / add-ons.
Thanks,
Nick
On December 4, 2013, at 12:48 PM, Brad Kulick <kulick@yahoo-inc.com> wrote:
Matthias,
Respectfully, I would like to maintain my objection for closing Issue-153 and allow it to proceed to CFO. Given the lower than normal participation for today's call, I would appreciate allowing for process to complete to ensure any other similar viewpoints are represented.
Thanks,
Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/
Charset: utf-8
iQEcBAEBAgAGBQJSqbd1AAoJEHMxUy4uXm2JWhgIAK1L9+EeFMkGVhq/VPjkjsdi
w/KMyIILjFFMAGNX+mc7vS8ULjygNOXJyftNHrcsS8vKFwTqsauUqYgsxmLFrqLV
TssreX8gAB2IO84Tws4E+Jq69cr6E3MjnojFknJmLTxnO6zwN63VtJn0WNlNOs/3
R1p5wWT+jjiEvKATjeUu0FoKTbm77+dDCQZMf5CdjPAo2PHcTHmRz+CXdnbt0Oqj
Yurj6zdbYF749HN7e2asc0e/FmV0iE+aG5ytXGorKFoXwb6AX6cC9lXbOtwY7jSX
cRdFC379CDKgHhiS0o/tExQp1txkrneFEzkvHx8qZXXwLaPpMOsphH8dpye3UZA=
=jsiC
-----END PGP SIGNATURE-----