https://bugzilla.wikimedia.org/show_bug.cgi?id=58196
--- Comment #40 from Krinkle <[email protected]> --- (In reply to Tim Landscheidt from comment #39) > (In reply to Krinkle from comment #38) > > [...] > > > In theory this could still be exploited by being a patient person and > > waiting for the moment one month has ended. Then the first user to become > > active in the new month would be the only person with a newer month > > timestamp. > > > [...] > > Could this be mitigated by excluding data for the current month? Essentially, yes. See my comment 17: (citing comment #17 from Krinkle) > [..] no matter how much we crop the timestamp (even if we'd crop it to the > month or year), one could in theory still retrieve the preferences of one > user by performing queries in a loop until the next day, month or year > starts and correlate that to the one user currently editing on that wiki.. > > The only way I can think of that would mitigate that is forcing the current > matching crop of the date being delayed (e.g. all users active today on > 2014-03-17 would be listed under 2014-03-16 until this day is over, so that > all active users have had a chance to be active that day). However "excluding data" isn't trivial. It'll make statistics and sum queries act very counter intuitive. If you'd exclude all rows where timestamp == current YYYY-MM, that would essentially hide all values of active users, and make them re-appear next month and back and forth like that. To avoid strange statistical variance like that, I'd recommend making timestamp of the currently running month appear as last month's. That way no data is excluded. This seems like a simple enough variance that tools should be able to work with without much hassle. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
