+++ This bug was initially created as a clone of Bug #58196 +++
Key comments (edited to make them make sense with each other):
Comment 15 Liangent 2014-03-14 06:35:23 UTC
...
Those are two different requests: one table (view) containing user identifiable info (user id) with fewer properties includes, and another anonymized one with more properties.
Comment 16 Luis Villa (WMF Legal) 2014-03-14 18:57:06 UTC
Retitling then :)
For the filtered table: I am OK with this in principle, but would like to better understand (1) how we choose which fields to filter and (2) how we prevent new fields from leaking.
For the anonymized table: Again, OK in principle; it would be good (but not a must-have) to know more about the impact on users of small wikis.
Description Kunal Mehta (Legoktm) 2013-12-09 05:17:15 UTC
...
Only preferences that are considered to be public are replicated, the list from enwiki_p is:
mysql> select distinct(up_property) from user_properties;
+----------------+
| up_property |
+----------------+
| disablemail |
| fancysig |
| gender |
| language |
| nickname |
| skin |
| timecorrection |
| variant |
+----------------+
Comment 23 Krinkle 2014-03-27 20:17:11 UTC
...
The Toolserver's non-anonimized filtered view has a much stricter whitelist:
nlwiki_p at toolserver> SELECT DISTINCT(up_property) FROM user_properties;
+----------------+
| up_property |
+----------------+
| disablemail |
| fancysig |
| gender |
| language |
| nickname |
| skin |
| timecorrection |
| variant |
+----------------+
8 rows in set
Based on the discussion in the other bug: legal approves creation of a view on Labs of the user_properties table, where the eight properties listed above are exposed with userid, property, and value.
This should, if at all possible, be whitelist-based, so that new properties are not accidentally exposed. If we need to add more properties, please discuss with legal at that time.
If anyone here thinks I've misunderstood something about this table, please speak now :)
Version: unspecified
Severity: normal