RE: Issue 153

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

Shane,

Parents have often have no access to devices used by their children, which may have been acquired elsewhere or brought in by a friend. Having a router option to override non-standard privacy options and consent indications that may been unknowingly given could have value for parents and should be available to them.

Some routers have parental controls capability, for example to block pornographic websites. Even standard routers often have the ability to override DHCP settings and many parents use these to block DNS lookups of content they decide is unsuitable. This is a better way to give control to parents than a) device based controls that can easily be bypassed or b) centralised controls via ISPs where there are obvious civil liberties and privacy concerns.

Mike

> -----Original Message-----
> From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
> Sent: 12 December 2013 18:42
> 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-----

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

iQEcBAEBAgAGBQJSqgkxAAoJEHMxUy4uXm2J+VoIALwevOFaGFXfuj5oJmfm1UX0
sNvIGj6CC21mLye33kwgLCDY4k2PEYAv/j/HF3yJLBFxJNxr6doaA2UrJA5qokfM
/CPDpN2wJPFFXI1Hxe4BbBssDB0COvDniI6qMXip1wNiLajCOg64kHjiZd5TzlEU
UazZL4YtDWoV2gQLqe+J4w8uBhlSc4GIa+XNj1N+H8hOJlds3SuXoBdo1HsaBFUF
oJOGpdJ0Jx4veSqZ0QEBIZLquPC/lAG8LBezu12vX3EsC1BccTZ010m3mVSPRj15
KH98a5a2rwXIZ+wzfOwqhOr7WaswAPiRRISTumuESOkJ546a/E5WKxI1cRVdK1E=
=3Xyl
-----END PGP SIGNATURE-----

Received on Thursday, 12 December 2013 19:07:07 UTC