- From: イアンフェッティ <ifette@google.com>
- Date: Tue, 2 Oct 2012 06:41:13 -0700
- To: Nicholas Doty <npdoty@w3.org>
- Cc: Justin Brookman <justin@cdt.org>, "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <CAF4kx8dhB5z6i7xyg2q=gS2A3h+BwmUz-RjR4Vn5DdY+Pf+6OA@mail.gmail.com>
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