W3C home > Mailing lists > Public > public-tracking@w3.org > January 2012

Re: ACTION-43: added user-agent-managed site-specific exception proposal to Editor's Draft

From: Sid Stamm <sid@mozilla.com>
Date: Thu, 19 Jan 2012 13:31:09 -0800 (PST)
To: JC Cannon <jccannon@microsoft.com>
Cc: David Singer <singer@apple.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <456b75c3-adf7-46f0-9ba9-3a430dd8370c@zimbra1.shared.sjc1.mozilla.com>
Me too. 

Users may choose one UA over another because it makes the right decisions *for* them... then the UAs will cater to their set of users based on how those users want to interact with the UA and the web.

It's a good idea to spec out how the UA communicates with web servers, and makes sense to provide non-normative guidance or examples about implementation techniques, but not normative language dictating how user agents help users make choices.

-Sid

----- Original Message -----
> From: "JC Cannon" <jccannon@microsoft.com>
> To: "David Singer" <singer@apple.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
> Sent: Thursday, January 19, 2012 1:17:33 PM
> Subject: RE: ACTION-43: added user-agent-managed site-specific exception   proposal to Editor's Draft
> 
> I wholeheartedly agree with David on this point.
> 
> JC
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: Thursday, January 19, 2012 9:29 AM
> To: public-tracking@w3.org (public-tracking@w3.org)
> Subject: Re: ACTION-43: added user-agent-managed site-specific
> exception proposal to Editor's Draft
> 
> Right.  As I am sure you know, I am all for user-control and user
> self-determination.
> 
> But there is an important avenue that users have to exercise that
> control, and that is in their choice of user-agent, and their choice
> of its configuration.
> 
> They re at liberty to say "I use browser X even though it doesn't
> support DNT because of Y", and they are liberty to say "I prefer
> browser M over browser N, because N is constantly asking me to make
> DNT choices in real-time, whereas M I can configure so it just gets
> it right".
> 
> I think it a *huge* mistake for us to design the way the user makes
> choices.  Be clear in the text that certain aspects of 'driving' the
> protocol belong to the user, but don't tell browsers what to do to
> make sure that that is the case. " MUST provide a user interface
> prompting the user to choose" is not a good phrase.
> 
> On Jan 18, 2012, at 23:45 , Rigo Wenning wrote:
> 
> > David,
> > 
> > we are approaching the "normal" catch22 situation of the data self
> > determination concept that is secretly underlying all our
> > discussions IMHO.
> > 
> > On Wednesday 18 January 2012 16:37:25 David Singer wrote:
> >> I think we're designing a protocol between the UA and the server,
> >> and what
> >> that protocol means and its requirements.  UA to user interactions
> >> are out
> >> of the scope of a MUST statement, I think.
> > 
> > And if you want to have (some) user-control and self-determination,
> > we assume
> > that at some point the user should be enabled to make a (albeit
> > possibly
> > automated) decision. And the protocol, at some point, needs to
> > trigger that
> > decision process. I do not believe we can avoid that without going
> > square to
> > the entire concept of privacy (because privacy is finally about
> > autonomy).
> > 
> > This said, a specification should only said that there MUST be a
> > user decision
> > and not how that user decision is implemented. Note that P3P
> > implementation on
> > UAs failed mainly because of lacking guidance and complete
> > misunderstanding by
> > implementers. Coming out of a 4 year research project where we
> > investigated
> > some of this, I could imagine that it may be worthwhile to have
> > some good
> > practices documentation where we join forces to unearth good
> > privacy
> > interfacing guidelines.
> > 
> > Best,
> > 
> > Rigo
> > 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 
> 
> 
> 
> 
Received on Thursday, 19 January 2012 21:31:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:30 UTC