<npdoty> I understand that we
do have agreement on market research itself not being a
separate permitted use

<aleecia> To the extent
reasonably necessary for inspection of product bugs and
performance, third parties may engage in tracking. Use of
graduated response is preferred.

<aleecia> Operators MAY
retain data related to a communication in a third-party context
to use for identifying and repairing bugs in functionality. As
described in the general requirements [reference to
Minimization section], services MAY collect and retain data
from DNT:1 users ONLY when reasonably necessary to identify and
repair errors in functionality. Services SHOULD use graduated
responses where feasible.

<Brooks> 678 580 is Brooks
just joining

<dsinger> Notes that this is
also under the general requirements for all permissions (that
data collected for a permission cannot be used for other
purposes)

<npdoty> can someone point me
to dwainberg's text here?

<rigo> I would introduce
"strictly bound to debugging purpose"

<dwainberg> Parties may
collect and use data in any way to the extent reasonably
necessary for the detection and prevention of malicious or
illegitimate activity.

<fielding> for
security/fraud: Parties may collect and use data in any way to
the extent reasonably necessary for the detection and
prevention of malicious or illegitimate activity.

<Chris_IAB> debugging =
product development?

<rigo> no

<rigo> debugging ==
debugging

<justin_> So, dwainberg, are
you against retaining the language about preferring graduated
response? Your answer was unclear.

<dwainberg> I'm not sure what
purpose it serves.

<rigo> Chris_IAB, you can
only debug a product that already exists

<Chris_IAB> with all respect
rigo, just as a clarification, debugging is in fact a part of
ongoing product development

<WileyS> Rigo, Chris could be
suggesting "product improvement" (as development could mean
something net new or something that is evolving from its
current state)

<JoeHallCDT> Chris_IAB
debugging may be a subset of product development, but there's a
lot more under that umbrella

Dpdoty: graduated response came
from discussions in bellevue

<dsinger> we need a
definition of graduated response; we use it in several places.
"As you dig deeper, and know you need more data, then turn on
the collection then."

<adrianba> we also discussed
graduated response in the debug session

<Chris_IAB> fair enough
points all; I just wonder if all of this can be effectively
handled under the same condition model?

Rfielding: graduated response
came from security discussion not the debugging discussion --
doesn't belong in bebugging

<rigo> WileyS: product
improvement is a semantically loaden term in our area

<WileyS> debugging a 3rd
party ad network - one individual reports the bug but you need
to look at the data of many to confirm the source of the
issue

<rigo> +1 to roy

Fielding: not sure how this
deserves a seperate exception

<justin_> I do not feel very
strongly, and "reasonably necessary" should effectively mean
the same thing.

<Zakim> ifette, you wanted to
say i have no idea what graduated responses means

<WileyS> Publisher reports an
error with an ad showing on their site - requires you look at
the data of many users seeing the add to see what variables may
be driving the source of this issue. Not only user reported
issues (althought that's a valid source as well)

<ifette> :)

<JoeHallCDT> npdoty that
sounds like the UC Berkeley I School graduate student bullpen
that I know and love

<aleecia> presumably someone
put us on mute :-(

<aleecia> or rather, hold

Dwainberg: don't understand the
purpose of the language. It hinders our goals by offering too
much explanitory text. When we say "to the extent reasonably
necessary for..." is enough

<aleecia> Non-normative
explanation: This permitted use is intended for short-term
diagnosis and repair of third-party Web functionality, commonly
in real time. Long-term retention of all data is not compatible
with this permitted use. This permitted use is not intended to
cover broad quality assurance measurements.

<WileyS> Roy, do those
examples give you enough context?

Dwainberg: big terms like
graduated responses may lead to confusion and ambiguity

<justin_> Shrug. Fine.

<fielding> the short-term
should be normative

<npdoty> I understand that
we're talking about the debugging use, not the security/fraud
use

<justin_> +1 to fielding

<aleecia> Debugging not
security: so sorry to have started us down the wrong path

<WileyS> DSigner - doesn't
represent the real-world. We have bugs EVERY day, not just SOME
day. :-)

Dsinger: the graduated response
language means that you are able to collect a bit more data
because you suspect you have a specific problem that needs to
be diagnosed

<fielding> My software does
not have bugs every day. ;-)

<jchester2> +1 Singer

<adrianba> +1 to dsinger's
description

* Chapell notes that Google is recruiting
ringers for the next battle of the ad industry bands

<Chris_IAB> LOL WileyS, you
mean that all of our commercial code is flawed? No way ;)

<WileyS> Roy, Your users may
implement things incorrectly such that they point the finger at
your software as being the source (when they're really the
problem).

<dsinger> I know that bugs
are eternal, but specific issues that warrant collection of
specific data are not

<dsinger> so, (a) specific
problem (not general anxiety) (b) short-term (not indefinite)
and (c) proportional/graduated response (only the data you
reasonably need)? and the last is in anxiety/dispute?

<rigo> jchester2, doubt that,
"graduate response" was the name of the NATO doctrine to nuke
the russians

<aleecia> Research:
collection and use of identifiable data for market research or
other longitudinal aggregation purposes is not generally within
the context of a particular request; only unlinkable data may
be retained for this purpose. As described above, identifiable
data can be stored during short term logging to generate
aggregate reports.

<aleecia> Changes from the
editors' draft: Remove "Aggregate Reporting" section. Ensure
that unlinkable data is prominently declared out of scope of
these requirements earlier in the document. Ensure that the
"Short Term" permitted use makes it clear that retaining
identifiable data for the short term is allowed for creating
aggregate reports.

<jchester2> What do we mean
short term for ID retention? Is that linked to a specific
campaign?

<WileyS> Rigo, I believe its
the definition of "unlinkablity" that is the bigger
confusion

<jchester2> +Rigo

Rigo: complexity, not consensus,
explains lack of response

<npdoty> jchester2, I mean
"short term" to refer to the separate short term logging
permitted use (which might be 6 weeks, or whatever the group
comes down on)

Rigo: what is the minimum
requirement on the aggregate information?
... Aggregate is fine, but please make sure that you can't
re-identify in order to avoid discrimination

<jchester2> Nick, I think
that's do vague for this key area. It needs a discussion to
understand the contours and impact of such use.

<justin_> I think that the
text is clear that you cannot maintain non-deidenfitied data
for the purpose of research/improvement.

<npdoty> jchester2, can you
explain more?

<WileyS> Justin, agreed -
you'd maintain the data only to develop the aggregate outcome
to then do market research and product development

<npdoty> I think rigo's point
is that defining unlinkable is the difficult part

<jchester2> Market research
has changed in terms of capabilities and use, inc. in the real
time targeting context. So I hope our market research
colleagues and others can discuss how it's used today and the
implications for DNT:1

<justin_> fielding, You know
what I mean!

<JoeHallCDT> fiedling, using
double negatives like that is an art

<rigo> WileyS, we have to
come up with a plausible process of transforming personal data
to unlinkable data, not define unlinkable data

npdoty: Not proposing this as
text for the document.

<rigo> so we just define that
process, not the quality itself

<rigo> because "unlinkable is
a moving target"

<WileyS> Rigo, I believe
those are one in the same

<npdoty> apologies for the
formatting, which was apparently very confusing :)

<justin_> rigo, there is a
separate outstanding question of what consistutes
unlinkabling

<dwainberg> yes

<jchester2> Yes, I think!

<npdoty> npdoty: intended
"generally within the context" to explain the reasoning for
this permitted use, not as new text

<johnsimpson> say again what
we have agreement on..

<Chris_IAB> I like unsinkable
Ed :)

Aleecia: action item: editors
make changes for NEXT editors draft

<justin_> Sure

<jchester2> we might have
more consensus if it was just unsinkable!

<johnsimpson> thanks got
it

<npdoty> agreement to remove
this as a separate permitted use and move the discussion to the
unlinkable definition

<dsinger> thinks we should
not say that doing something contrary to the spec. in order to
comply with local law is *compliant* but may be *needed*, and
maybe we need a qualifier to indicate (as previously
discussed)

<Chris_IAB> Rigo, for
example, does tribal law in the US, where the tribe is legally
a sovereign state able to make it's own laws, work for you?

Dsinger: "it may be necessary for
you not to comply with this specification in order to comply
with local law"

<rigo> Chris_IAB, sure!

<Chris_IAB> Rigo, if so, then
all ad networks may move to American Indian reservations, and
help them enact new laws...

<npdoty> dsinger, I think
that point was raised in earlier discussion, and we came to
agreement on this text

<amyc> think there is a
eparate section and issue regarding spec compliance

<rigo> Chris_IAB, they didn't
move yet to the Caiman Islands or to the turkish part of
Cyprus?

<Chris_IAB> local law = city
government laws and regulations too?

Dwainberg: This ties into the
concept of enabling parties to communicate that their honoring
of DNT may be different from that outlined in the spec
... agrees with the concept about not creating contractual
loopholes

<tlr> "applicable law"

<npdoty> if you agree with
the concept and we came to consensus on this several months
ago....

Aleecia: suggests that DWainberg
work with Npdoty

<rigo> tlr, "applicable" may
be the main headache

<tlr> we can't solve what's
applicable. So we just say "comply with applicable law,
please"

<fielding> I am struggling to
understand why we need this clause -- no other specification
I've worked on needs to point out that local laws might
apply

<Chris_IAB> rigo, they
haven't moved... yet.

What might be bother Dwainberg is the example
that I've outlined in IRC

<amyc> david, welcome your
participation in my ACTION:-)

<aleecia> * Identifiers:
flexibility is provided to implementers on how they accomplish
permitted uses and minimize data retention and use.
Implementers are advised to avoid data collection for DNT:1
users where feasible to enable external confidence.

<aleecia> Placing third-party
cookies with unique identifiers (and other techniques for
linking data to a user, user agent or device) are permitted
where reasonably necessary for a permitted use. Requirements on
minimization and secondary use, however, provide limitations on
when any collection technique is compatible with a Do Not Track
preference and what the implications of that collection
are.

<aleecia> To give flexibility
to implementers in accomplishing the requirements of this
specification and the listed permitted uses, no particular data
collection techniques are prescribed or prohibited.

re: the pharma company self-reg requirements
that may fall outside of what 'the law' says, but must be
complied with nonetheless

<aleecia> Implementers are
advised that collection of user data under a Do Not Track
preference (including using unique tracking cookies or browser
fingerprinting) may reduce external auditability, monitoring
and user confidence and that retention of such data may imply
liability in certain jurisdictions in cases of secondary use;
for more information, see the Global Considerations.

<dwainberg> Alan, what was
that example? I missed it?

<dwainberg> amy, yes, I'll be
happy to

<Chris_IAB> Rigo- Interesting
that a state wishing to induce commerce, might create laws that
are favorable to industry, in an effort to circumvent DNT...
given this provision.

<aleecia> so by "identifiers"
we mean "unique identifiers"

<Chris_IAB> Rigo, do laws
include case law in addition to stated law?

<WileyS> Great work Nick on
threading the unique ID needle

<fielding> No idea where it
goes in spec.

<rigo> Chris_IAB sure

<WileyS> +1

<johnsimpson> -1

Aleeica: Straw poll. +1 if you
can live with this text

<fielding> +1

+1

<jchester2> -1

<rigo> +1

<justin_> +1

<dwainberg> +1

<Chris_IAB> Rigo, it may be
more wise to stay away from the "law" provision in general, and
stay silent...

<rigo> Chris_IAB, nope, this
is a rule of conflict. And we clearly say that law overrules.
This is essential for later regionalization

<npdoty> johnsimpson or
jchester2, is it possible to elaborate on those concerns? (via
email or a separate call is fine)

<Chris_IAB> Rigo,
respectfully, I think that weakens the spec, but it's your call
I suppose

<aleecia> * Minimization

<aleecia> A third party MUST
ONLY retain information for a permitted use for as long as is
reasonably necessary for that use. Third parties MUST make
reasonable data minimization efforts to ensure that only the
data necessary for the permitted use is retained. A third party
MUST provide public transparency of their data retention
period; third parties may enumerate each individually if they
vary across Permitted Uses. Once the period of time for which a
party has declare

<aleecia> data retention for
a given use, the data must not be used for that permitted use.
After there are no remaining Permitted Uses for given data, the
data must be deleted or rendered unlinkable.

<aleecia> Where feasible, a
third party SHOULD NOT collect linkable data when that data is
not reasonably necessary for one of the permitted uses. In
particular, data not necessary for a communication (for
example, cookie data, URI parameters, unique identifiers
inserted by a network intermediary) MUST NOT be retained unless
reasonably necessary for a particular permitted use.

<aleecia> Note: it may be
that this is the only time a requirement/prohibition is
necessary regarding "collection". All other requirements would
be prohibitions on retention (beyond what is necessary, or
beyond a short-term logging period) or sharing. A definition of
collection, then, is only needed for this minimization concept.
"Tracking" can be defined through "retention", "use" and
"share" only.

<WileyS> johnsimpson or
jchester2, could you please provide the details of your
concerns on the public email list?

<rigo> W3C is no ruling
authority, just a platform that creates useful things

<npdoty> text before "Changes
from the editors' draft" is the normative text, text after that
heading describes the changes

<npdoty> the paragraphs with
MUST ONLY, MUST and SHOULD NOT would be the normative text

<aleecia> * Secondary Use

<aleecia> A third party MUST
NOT use data retained for a particular permitted use for any
other purpose.

<aleecia> Changes from the
editors' draft:

<aleecia> Clarify that data
retained for one purpose cannot be re-purposed (even if the
second purpose might be related to another permitted use).

<aleecia> Note: This does not
require keeping separate copies of data for different permitted
uses (agreement in Seattle that a single copy is allowable),
but does require that data retained for one stated purpose
cannot be repurposed, even in aggregate form. (See resolution
at the end of: http://www.w3.org/2012/06/21-dnt-minutes#item08)

Aleecia: IFette had text from
Seattle that was helpful

<johnsimpson> Where is Nick's
text now? Just on email list?

<npdoty> if someone has a
pointer to Ian's text that would be useful, please point me to
it

Fielding: has concerns with last
sentence

<fielding> this one: In
particular, data not necessary for a communication (for
example, cookie data, URI parameters, unique identifiers
inserted by a network intermediary) MUST NOT be retained unless
reasonably necessary for a particular permitted use.

<rigo> Ninja, After there are
no remaining Permitted Uses for given data, the data must be
deleted or rendered unlinkable.

<dsinger> maybe it should say
"In particular, data not necessary for a communication (such
data might be cookie data, URI parameters…" to respond to
Roy?

<rigo> .. should be only kept
for that particular permitted use, shift in use shouldn't be
possible

<rigo> ... or shift in
purpose

<fielding> the sentences
before that are sufficient (and more accurate)

<dwainberg> It's redundant,
isn't it?

<WileyS> +q

<dwainberg> and adds
potential for confusion

<rigo> I don't think it is
redundant

<dwainberg> "MUST only retain
... " says enough doesn't it?

<WileyS> Oh well, I tried.
:-)

<npdoty> I'll take an action
to try to address that, thanks WileyS for the promising
suggestion