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

Re: Poll text call: final text by 28 September

From: イアンフェッティ <ifette@google.com>
Date: Tue, 2 Oct 2012 06:41:13 -0700
Message-ID: <CAF4kx8dhB5z6i7xyg2q=gS2A3h+BwmUz-RjR4Vn5DdY+Pf+6OA@mail.gmail.com>
To: Nicholas Doty <npdoty@w3.org>
Cc: Justin Brookman <justin@cdt.org>, "public-tracking@w3.org" <public-tracking@w3.org>
Replying to you and Vincent here as the replies are basically the same.

Ideally, in the 6 week period, we wouldn't seek to describe such a
proscriptive, detailed set of uses to make it exactly match the other time
period. If that was what we ended up doing, I agree it would be duplicative
work to try to define a set once as a set of "Thou may..." and again as
"Thou must not...". However, I would hope people would agree that with such
a short time window of data, there's a lot less risk as compared to data
that has been collected over a longer timeperiod. As such, I would argue
that sites should be given more leeway in what they are allowed to do
during that window. There should be some limits, to be sure, but I don't
think the two timeperiods need to (or even should) line up exactly in terms
of what can / cannot be done with the data.

On Tue, Oct 2, 2012 at 5:47 AM, Nicholas Doty <npdoty@w3.org> wrote:

> On Oct 2, 2012, at 2:14 PM, Ian Fette (イアンフェッティ) <ifette@google.com>
> wrote:
>
> > If all you say is essentially "You may keep data for six weeks for the
> purposes of accomplishing permitted uses" then I don't get what the purpose
> is, it doesn't seem to make anything either easier or harder for
> implementers, indeed it seems like a no-op.
>
> Given that we have in the current draft limitations on retention, this
> grace period certainly doesn't seem like a no-op. The difference would be:
> "You can retain only the data you need for accomplishing permitted uses"
> vs. "You can retain any data for six weeks, but can't use it except for
> permitted uses". That would be the difference between a real-time data
> minimization system that strips any fields not necessary before writing
> logs to disk and a monthly batch process to minimize standard logs;
> compliance with the latter would seem to be much easier.
>
> > Going back to waaay earlier discussions, my original intent was to make
> it easier for people to claim compliance. I guess the analogue would be
> changing from a presumption of "innocence" to a presumption of "guilt".
> That is, in the six week period, compliance with the spec should mean that
> you don't do <insert super aggregious thing here, such as transferring all
> data to a third party>. There's a presumption you're not doing this, and as
> long as that remains true, you're fine. Since standard logging is (by
> definition) a standard practice, we aren't going out of the way to make you
> prove what practices you do or don't do, as long as you don't do X you're
> good.
>
> What I thought I was hearing from the group is that we didn't want to
> create separate lists of practices ranked by egregiousness. (I'm also not
> sure that the blacklist language changes the presumption in proving
> compliance -- in both cases you need to prove that you're not doing some
> set of things.)
>
> > Long-term data retention has much higher risks in terms of exposure to
> actual privacy problems (data breach, or secondary uses that users may view
> as harmful to their privacy desires). As such, if you retain data for a
> longer term (>6wks) then you have a higher responsibility, and the burden
> shifts to you to show that the data is being maintained securely, and that
> access to the data is well controlled and in accordance with the permitted
> uses.
>
> Right, I think that is a common goal: the motivation here is that
> short-term retention is both a common practice and less of a privacy
> concern, and so we can relax data minimization requirements (limits on what
> data can be retained) for short-term retention. I'm not sure I see why that
> would also extend to a different set of use limitations in the short term.
>
> Thanks,
> Nick
>
> (Apologies if I'm echoing Vincent who is faster at sending these emails
> than I am.)
Received on Tuesday, 2 October 2012 13:41:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:35 UTC