Hey @Nikerabbit and thanks for providing some background on these tables.
Mon, Sep 13
Fri, Sep 10
Thu, Sep 9
Thank you for your answer. I have now wrapped the privacy review and would like to share the conclusion. The analysis focused on the sys database of db2083 server, which as of writing, contains 88 tables, encompassing performance statistics.
@sguebo_WMF thanks a lot for starting to take a look into this.
sys schema has lots of view (this is the documentation about them: https://dev.mysql.com/doc/refman/5.7/en/sys-schema-views.html) to be honest, I am not fully sure which ones could leak private information.
If this is helpful in trying to identify what can be potentially private, this is an output of one row per table, in case something rings a bell and you want to explore the table further:
Thanks for pasting the output of sys’ tables, @Marostegui. That’s really helpful. As I am wrapping up my analysis, I’d like to ask a quick question just to make sure that I understand things correctly. The host_summary table seems to contain IP addresses in the 10.192.** range. Judging by the range, my understanding is that these IPs are from Wikimedia load balancer and not from the end user. Is my understanding accurate?
Fri, Sep 3
That would be great. There is no real rush, I've just been reviewing blocked tasks that have been silent for a while.
Note: Miraheze has the RemovePII mediawiki extension for compliance with RTBF. There might be bits you can steal.
Interesting - https://github.com/miraheze/RemovePII does indeed look like it could maybe get us part of the way there.
Mon, Aug 30
Fri, Aug 27
Hey @mforns, that confusion is totally understandable so not worries at all. The good thing is that I have now updated my title in Phabricator.
Tue, Aug 24
A couple comments.
- The other day, talking with the team, we thought we Analytics could take this task, as sanitizing a full URL by applying a mask, could be useful to other data sets. This is something we could do, I created a task for it: T281144.
- On the other hand, I thought that, even if we purge the URL and only leave the hostname, that could still hold privacy sensitive information, that could indicate user's preferences or interests or specific situation. I think we should ask the Security/Privacy team about this. Pinging @JFishback_WMF, what do you think?
Aug 16 2021
Hi @sguebo_WMF! Do you have suggestions about what language we should use to inform users that information about them will be collected via the EXIF data and made public? Or do you suggest we reach out to legal?
Aug 6 2021
I used replica databases to evaluate wide anon-only range blocks applied to certain ISP(s), and for those tasks, having raw IP of (logged out) users is certainly beneficial.
Hi @Seddon, I am adding this task to the Structured Data board and pinging you here, following the above discussion about some privacy concerns related to the Upload Wizard.
Jul 29 2021
Jul 27 2021
I agree that the privacy harm is considerably lowered by the fact that users are made aware that their gender information will be made public if they choose to disclose it. Since it is my understanding that we’re comfortable moving on with that low level of privacy risk, I don't see any issue with declining the ticket.
Jun 25 2021
@sguebo_WMF Is this a modification of the approval given in T150679: Some Labs DB user_properties view fields are sensitive to expose that preference?
For context, the privacy engineering audit regarding the wiki-replicas is part of a body of work that is being done internally by the Security team. But I concur that a parent public ticket would have made sense too. I’ll keep that in mind moving forward.
Jun 14 2021
May 12 2021
I had the chance to sync directly with @Varnent who's in charge of those platforms, and I surfaced the solutions proposed above. So far, applying the CSP change at the Nginx server level on WordPress VIP does not seem to be an option. Instead, disabling Twemoji.js through a WordPress plugin would be the applicable solution. The Security-Team is supportive of this approach, which was suggested earlier in this thread and has already been used on the techblog (Cf: 4447d8f).
May 4 2021
Apr 26 2021
Thanks for the ping. I have added a sentence to reflect the concern on the gadget description for zhwikinews where I am a sysop.
Indeed, @Xiplus , do you find it feasible if we move your script to the wiki so that the concern could be eliminated?
Apr 23 2021
Apr 19 2021
I would be grateful if you clarify what you are requesting/ expecting. Are you suggesting that those gadgets be taken down or that their authors be required to draft an on-wiki heads-up, for instance on the widget's talk page? Or is it totally something else you're asking for?
Apr 15 2021
Since the WordPress blogs have none of the MW legacy, I suppose it'd make sense to set the CSP rules at the server-level for the blogs, not from within PHP.
I'm not sure if we have access to nginx config settings at Auttomatic, but that would be the best approach, sure. I was more implying that we could copy the current Wikimedia prod CSP as a starting point and tighten it as appropriate for the various WP sites referenced within this task.
Apr 9 2021
Originally I was interested in having the risk rating field being added to New Task. However, while looking at the tickets your referenced, I could see that the Security Type Advanced form (73) already has the Security rating field, although it seems to be locked at the moment.
Apr 8 2021
Apr 6 2021
I completed a prototype with basic filtering options. For now, one can filter by project (tag), year when the ticket was created, and severity. The code base is available at https://github.com/samuelguebo/vm-dashboard. It's public for now since there are no credentials or sensitive data there but I'm glad to make it private if there are any objections.
Apr 2 2021
Thanks @Reedy, I intend to use the Phabricator's Python library since it's pretty straightforward.
I guess I can grab the token with you once you've gotten the chance to create it.
I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.
Sounds good. Not sure if you're using personal API tokens for this, tied to your Phab account, but we probably shouldn't do that. We do have a bot though we'd likely need to recover credentials for that and add you and maybe @Reedy and myself as maintainers.
For now, I think we can make this public. If it becomes necessary to include sensitive data here, directly within the task, we can always protect it again.
Thanks for chiming in.
Some initial tests with Conduit enpoints
Pulling the Phabricator ID (PHID) of all tags starting with the Vuln- keyword:
curl https://phabricator.wikimedia.org/api/project.search \ -d api.token=api-token \ -d constraints[name]=Vuln-
Mar 9 2021
Mar 8 2021
Hey @sbassett, thanks for creating this and having checked a bunch of boxes already.
- I think I still need to ping a Phab admin to add me to acl*security_team.
- I wasn't sure about the Deployment & stats private data part, since per https://github.com/wikimedia/puppet/blob/5dca2a73bba83ad469a20cc38e0d0c15761befa3/modules/admin/data/data.yaml it seems I am already within the analytics_privatedata_users and deployment groups — restricted being a subset of deployment.
- I'll figure out how to enable the word highlighting for my IRC client (Limechat)
Nov 18 2020
Hi. I have merged the gerrit change, but
- i'm not sure how long it's going to take to take effect
- the current redirect is a 301 (a 'permenant' redirect), so browsers that have visited the url before are likely to still go to the old location.
Nov 5 2020
Oct 6 2020
Sep 25 2020
Handled through ca@
Jul 27 2020
Thanks again for the patch. While he can access the stats server (stat1005.eqiad.wmnet), Nahid is not able to access the maintenance server.
Jul 24 2020
2FA is now removed from the account User:Nabin K. Sapkota
Jul 6 2020
Jul 3 2020
Jul 2 2020
Jun 30 2020
Jun 11 2020
elukey@krb1001:~$ sudo manage_principals.py delete sguebo elukey@krb1001:~$ sudo manage_principals.py create sguebo --email@example.com Principal successfully created. Make sure to update data.yaml in Puppet. Successfully sent email to firstname.lastname@example.org
Done! Sorry for the lag!
No worries, @elukey. Many thanks for your assistance!