Last modified: 2014-04-11 19:17:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22005, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20005 - AbuseLog show private data (timestamp emailconfirm)
AbuseLog show private data (timestamp emailconfirm)
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-30 09:50 UTC by Umherirrender
Modified: 2014-04-11 19:17 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Umherirrender 2009-07-30 09:50:27 UTC
The details of the AbuseLog show a field "Time email address was confirmed". In my opinion is this critical, because the time of emailconfirm is private data and not visible at any other place.

Please give only a field, if the user has confirmed or not, this information is visible by Special:EmailUser, so there is no problem. Thanks.
Comment 1 Andrew Garrett 2009-07-30 10:35:50 UTC
I'm not sure that it's private, personally identifiable data, but it still might have been a bad idea to disclose it, it's a good secondary verification point for manual password resets.

Since it's been released for months, it's now dead as a secondary verification point anyway, so I'm not sure how "private" it is.
Comment 2 Andrew Garrett 2009-08-20 15:56:15 UTC
Sticking Brion on CC to see what he thinks.
Comment 3 se4598 2014-01-18 15:39:08 UTC
Is this fixed? I see that the email timestamp can still be used as filter variable, but not that it can be directly seen.
Comment 4 Umherirrender 2014-01-18 18:00:24 UTC
old log entries still shows it, but newer one not. No idea why, maybe the value is no longer stored at a detail, but that can also means, that is no longer usable on a filter, but that would be another bug.
Comment 5 se4598 2014-04-11 19:07:44 UTC
It's not fixed. I reproduced the bug locally by creating a filter which uses "user_emailconfirm". Because the value gets only lazy_loaded it's normally not set and thus not exported and stored in the db.

Speculatively it's enough if any active filter uses emailconfirm to get it stored by any other filter.

aside: the details (var-dump) of an edit are stored for me as serialized php-array in mw's "text"-table, not in a AF-table itself.
Comment 6 Umherirrender 2014-04-11 19:17:19 UTC
newly added lazy-loading sounds like a good reason, why it is not set on newer logs, but on old logs.

It is intended to use the text table (or external stores, when set)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links