On Sun, May 19, 2013 at 09:44:24PM +0200, Bernhard R. Link wrote: > * Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> [130512 12:39]: > > On Sun, May 12, 2013 at 11:53:17AM +0200, Bernhard R. Link wrote: > > > Package: popularity-contest > > > Version: 1.57 > > > > > > Please do not send second resolution information about program usage. > > > Best only send out information what is actually used by the resulting > > > graphs (i.e. a per-package NO-FILES/OLD/RECENT-CTIME/VOTE information > > > and nothing else). > > > > I am considering rounding the number of second to the next multiple of 24h.
I have made a git branch 'bill-trunc_time' for that purpose. Please check. > > However, unless you are using strictatime, you probably do not leak much > > information already. > > Doesn't relatime update atime when it is older than a day? So doesn't > relatime/strictatime just change from "second of last use before popcon > run" so "second of first use in a 24 hours window, but still exact to > a second"? Not exactly. It is only updated if it is 24 hour old. So you get the exact time of an event you cannot qualify. This is the stopped watch fallacy. [1] > > It is important the vote determination is done in a centralised way. > > How does that prevent not sending timestamps? If you do not have the timestamps, then you have to rely on the client computation being correct. > > > Additionally it would be nice to have a blacklist of packages to not > > > send information from. Or perhaps some filter on packagename > > > (mycompany-*) or sections (local/*). > > > > I am considering to allow packages to opt out of popcon by adding a control > > field > > like "X-Popcon: no". Would that be suitable ? > > That means you have to consider that when creating packages, which would > be quite complicated to get retroactively. If the package is leaked, it is too late anyway. At least this would prevent the package to be leaked by forgetting to update the blacklist on one computer. Cheers, [1] See Lewis Carrol complete work in your local library. -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
