W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

Re: ACTION-372 service providers and debugging

From: Jonathan Mayer <jmayer@stanford.edu>
Date: Tue, 19 Mar 2013 10:03:58 -0700
Message-ID: <CAFTK4kkB3qKU4sC8jKvXaL0HDFBkf9xPXJva4DJ3AqgAoAU5jw@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: David Wainberg <david@networkadvertising.org>, "public-tracking@w3.org" <public-tracking@w3.org>
Roy and David,

I regrettably don't have time for yet another go-round on debugging owing
to finals week. It appears we'll soon have a fresh ISSUE for tracking the
longstanding proposals and objections.


On Tuesday, March 19, 2013, Roy T. Fielding wrote:

> By their very nature, most service providers collect data for
> multiple parties via a centralized service.  The data is
> only separated after the protocol stream is parsed, which is
> fairly immediate.  Debugging will occur on both sides of that
> separation process and is permitted by each controller as part
> of the typical service contract.
> ....Roy
> On Mar 18, 2013, at 10:32 PM, Jonathan Mayer wrote:
> I would be willing to consider a debugging exception (for both third
> parties and service providers), but only if:
> 1) Data collection is not prospective.  In other words, the exception only
> applies if there's currently a bug getting worked out.  Industry
> participants have not provided technical evidence that historical linkable
> data would be essential for debugging unlinkable practices, and at any
> rate, I'm not comfortable with any provision that allows continuous
> linkable data collection.
> 2) Data collection is necessary.  There are many ways of squishing a bug.
>  Collecting intrusive data must be a last resort.
> I think Tom Lowenthal's language in ACTION-278 mostly does #1, not quite
> #2.  At any rate, we should probably have an ISSUE for tracking a debugging
> exception.
>  On Monday, March 18, 2013 at 3:04 PM, David Wainberg wrote:
>  The issue is that service providers should not jeopardize service
> provider status by virtue of looking across siloed data to perform system
> debugging. I believe the current language for the debug permitted use
> already implicitly includes this, but that we can make it explicit in
> non-normative language.
> Current permitted use:
> * Debugging**
> **
> **Information may be collected, retained and used for identifying and
> repairing errors that impair existing intended functionality.*
> Non-normative addition:
> *This provision includes use of data by service providers **from across
> multiple clients simultaneously for the limited purpose of system
> debugging. *
Received on Tuesday, 19 March 2013 17:04:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC