In T296847#7745018, @daniel wrote:

We had an RFC open about this for a couple of years, which has some analysis and discussion of legitimate use cases and UX for opt-in: T208188: RFC: Partial opt-out method for Content security policy

My current plan for rollout is as follows:

• Informal feedback round (in progress)
• Update policy based on feedback.
• New more formal feedback round from WMF staff e.g. please respond by X date
• Update policy based on feedback.
• A formal round of feedback from the community.
• We'll update the interface to provide a notice on pages where JS can be added that links to the policy:

<div class="mw-message-box mw-message-box-notice">All code written here is expected to <a href="#">adhere to the gadget policy</a>.</div>

Following T262493#7584789 I've begun drafting a policy and collating feedback on the talk page:
https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy

Perhaps we could combine efforts here?

As noted above, WordPress-powered websites such as Diff are used by the Foundation for public-facing initiatives. For instance, blog posts published on Diff feature names of their authors, and in most cases their titles within the organization. Although, the REST API allows people to retrieve the list of user accounts of the website, it generates list of already-public users, in JSON format that'll need to be parsed/processed. Therefore, the API is not disclosing any information that was not already private, nor is it increasing the visibility of information that was already public by making it easier to retrieve.

Hey @Addshore, on the behalf of Security-Team, I reviewed the privacy risks inherent to the proposed usage reporting feature for mwcli. I’ll share my conclusions below.

@sguebo_WMF Is this data visible on the wikis?

For example after a user has gone through a whole setup and played around with the environment a bit we might get something like this (at the highest detail level planned) from the next time the mwcli attempts to send data back.

• 4x docker mediawiki create
• 2x docker mysql create
• 2x docker mediawiki install --dbtype=mysql --dbname=default
• 2x docker mediawiki install --dbtype=sqlite1 --dbname=CUSTOM
• 22x docker mediawiki exec
• 4x codesearch search --output=ack
• 1x codesearch search --output=table

Hey @Addshore -- thanks for bringing that to the Privacy Engineering team's attention. My understanding is that the metric tool would work as below:

localuser:
  source:
    - localuser
    - globaluser
  view: >
    select lu_wiki, lu_name, lu_attached_timestamp, lu_attached_method, lu_local_id, lu_global_id
  where: lu_global_id = gu_id AND gu_hidden=''

Noted, thanks for the additional context @GeneralNotability. The description was updated accordingly.

Hey @GeneralNotability and @Urbanecm. As mentioned earlier, your question will be brought to WMF-Legal's attention. Feel free to rename it or adjust the description if I missed some aspects.

Something more robust would be needed if this is to become any sort of wikimedia, or WMF-wide standard. A longer-term fix would be to integrate such indications in to the software, but development on Gadgets 2.0 has been stalled for a LONG time.

That being said, I don't think "PRIVACY" is very useful there alone - from a UX perspective that seems confusing, did you notice there is already a lengthy hover text on the "E"xternal indicator? It looks like this:

Also keep in mind, there are actually much larger risks then "privacy" when loading third party scripts, such as account hijacking - surreptitious action making, etc.

Thanks for handling that, @thcipriani

On the behalf of Security-Team, I reviewed the privacy risks that exposing Translation extension’s tables in replicas may bring about. I’ll share my conclusions below.

In T289952#7359224, @sguebo_WMF wrote:

Hey @Nikerabbit and thanks for providing some background on these tables.

You mentioned that translate_messageindex should not be exposed because it contains some internal tracking information. I pulled up an excerpt from that table but I think I would need some help in understanding where you see an issue.

wikiadmin@10.64.16.207(wikidatawiki)> select * from translate_messageindex limit 1\G

*************************** 1. row ***************************
tmi_key: <redacted integer>:help:About_data/1
tmi_value: page-Help:About data|agg-Help

Could you please explain to me why you think this index information is concerning?
That may help me better grasp any security or privacy risk inherent to this specific table.

Hey @Nikerabbit and thanks for providing some background on these tables.

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.

In T195578#7335760, @Marostegui wrote:

@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?

In T279952#7329494, @mforns wrote:

@sguebo_WMF & @EYener, we discussed this task and will go ahead and implement this feature.
However, as it is something not trivial, we won't be able to do it this quarter.
We're aiming to tackle it next quarter.

In T195578#7321195, @LSobanski wrote:

That would be great. There is no real rush, I've just been reviewing blocked tasks that have been silent for a while.

In T290099#7322617, @RhinosF1 wrote:

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.

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.

In T279952#7034307, @mforns wrote:

A couple comments.

1. 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.

2. 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?

In T284941#7267325, @CBogen wrote:

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?

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.

Thanks for the useful information, @Aklapper and @bd808.

Hey @nskaggs and @bd808,

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.

In T284943#7156513, @bd808 wrote:

@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.

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).

Thank you again for the mockup. I had the chance to surface it to WMF-Legal and I'd like to ask something. Is it possible to make the privacy indicator a bit more obvious? A few ideas to consider would be either giving the indicator a distinct color, or making its size larger, or putting them in bold, or using "(Privacy)" instead of the "(E)" indicator. Kindly let me know what's feasible or not.

In T275754#7031267, @Waihorace wrote:

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?

The Foundation’s Privacy Policy mentions the commitment of “never selling [user] information or sharing it with third parties for marketing purposes” and “[...]only sharing [user ]information in limited circumstances, such as to improve the Wikimedia Sites, to comply with the law, or to protect you and others.” In principle, gadgets that share user information with third parties do so in violation of this policy. However, it is worth noting that some of these scripts are used by thousands of contributors. Therefore, I think there should be a short-term and a long-term approach to tackling this issue.

In T65598#7027012, @Xaosflux wrote:

Mock up:

Hey @Xaosflux ,
Thanks for producing the mockup. I'll run this by WMF-Legal and revert back to you.

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?

In T259421#6374107, @sbassett wrote:

In T259421#6373857, @Krinkle wrote:

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.

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.

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.

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.