User Details
- User Since
- Aug 10 2018, 4:17 PM (202 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Samuel (WMF) [ Global Accounts ]
Mar 8 2022
Thank you both.
Mar 7 2022
Hey @sbassett and @JFishback_WMF , do you have any strong objections to making this task public? Its content may inform the ongoing discussion around third-party resources in T296847.
Mar 4 2022
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>
Feb 16 2022
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/PolicyPerhaps we could combine efforts here?
Feb 15 2022
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.
Dec 8 2021
Dec 6 2021
Dec 2 2021
Dec 1 2021
Oct 29 2021
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.
Oct 26 2021
@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
Oct 25 2021
Hey @Addshore -- thanks for bringing that to the Privacy Engineering team's attention. My understanding is that the metric tool would work as below:
Oct 21 2021
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=''
Oct 20 2021
Noted, thanks for the additional context @GeneralNotability. The description was updated accordingly.
Oct 19 2021
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.
Oct 18 2021
Oct 8 2021
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.
Oct 1 2021
Sep 20 2021
Thanks for handling that, @thcipriani
Sep 17 2021
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.
Sep 16 2021
Hey @Nikerabbit and thanks for providing some background on these tables.
Sep 15 2021
Sep 13 2021
Sep 10 2021
Sep 9 2021
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.
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?
Sep 3 2021
Interesting - https://github.com/miraheze/RemovePII does indeed look like it could maybe get us part of the way there.
Aug 30 2021
Aug 27 2021
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.
Aug 24 2021
Aug 16 2021
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
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 30 2021
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.
Apr 26 2021
Apr 23 2021
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.
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
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.