Salut @Jules78120, I pushed a fix. The tool should be pulling the correct statistics. Feel free to mark it as resolved if it works as expected.

LGMT. Thanks, @Dreamy_Jazz.

In T375751#10180483, @Dreamy_Jazz wrote:

Proposed patch:

T375751.patch1 KBDownload

Hi @joanna_borun, tagging you here as per @acooper’s guidance. The current task is a continuation of a discussion on restricting the on-wiki visibility of Abuse filter modifications (T241667). The Security-Team recommendation on that question has traditionally been to err on the safe side and restrict Abuse Filter modifications to specific groups rather than making them available publicly to everyone by default, including anonymous users. So T284944 is to make sure that the redaction happens on replicas as well. Let me know if further clarification is necessary.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Thanks for you input @Bawolff and @sbassett. So far the script outputs ~2800 potential candidates (See table in F55305255#7434). I'll see how to leverage semgrep to improve the filtering logic and reduce false positives.

$ python wikimedia-gadgets-loading-tpr.py

To get the data on gadgets loading in much quicker way, I'm exploring a different approach that requires fewer steps. The idea is to have a script that can:

In T290493#9754259, @CKoerner_WMF wrote:

We've restricted access to the WP API on Diff with a recent update. Can someone please confirm if this issue is resolved according to the description?

I was able to include the high-level category and presented the relevant data in a heatmap-like fashion. Although I did not include any percentage to avoid visual cluttering, I think the heatmap colors convey a sense of where exactly the most concerning areas. Kindly take a look at the WIP_Matrix sheet and let me know what your thoughts are.

Perhaps it makes sense to use Message::parse() in directly in User::getRightDescription(). It could be redundant for Special:ListGrants et al. since there is also some parsing happening there but at least it would prevent wikitext from being displayed as raw text. I'll submit a patch in line with this.

The color-coding approach using Gsheet formulas seems reasonable and fairly straightforward to implement. The current table format is suited for color-coding each individual health check metric row based on its score. However, if we need to include the high-level headings to the table, I'd need to think of a good way to feature both the individual row color-code and the high-level heading color-code while avoiding visual confusion or cluttering. I'll give it some thought and try something.

Hi, all — I’ll share here a joint privacy review of the two proposed changes: enabling the TagManager and the Marketing Campaign Reporting plugins, as well as a succinct privacy risk assessment of the self-hosted Matomo instance, although it wasn’t specifically requested.

@sbassett I proposed some changes in a new PR. I've seen some linting issues but I'll look into it a bit later. For now, I'd be curious to know whether I am going in the right direction. So let me know when you get the chance to look at the code.

I've given it a try in the sheet COPY_High-level indicators and grouped the factors under 4 high-level indicators: security, testability, activity, and stewardship. These indicators are mainly inspired by our Mediawiki documentation on Codehealth[1][2] and some external resources[3].

I had another thought about this requirement. Besides the higher level organizational header names, it would be helpful if the risk of those columns could be collectively expressed by a single value.

In T348781#9247936, @sbassett wrote:

In T348781#9247890, @sguebo_WMF wrote:

@acooper I think I need edit privileges to modify the sheet. I'd like to make a copy of the 'Matrix' sheet and tweak it.

I think you should have access to both of the linked Google sheets now.

@acooper I think I need edit privileges to modify the sheet. I'd like to make a copy of the 'Matrix' sheet and tweak it.

Hey @RhinosF1, I don't fully recall the use case that T&S had in mind back then. I'll defer to @jrbs to clarify whether this work is something that's still needed.

The policy draft is now publicly available for feedback on meta-wiki. Hope to hear your thoughts there!

my main point is that since we now have the stats above, and they point out fonts as among the main third-party resources people load, we should make sure we try to address that in some way (find a reasonable way to enable that use case without unreasonably raising the risk). It's currently bright-line prohibited, but the fontcdn solution has properties that reduce that risk to what I assert is an acceptable level. It's just not zero, which is what the current bright-line policy requires.

Hello — just a heads up that the policy draft will be released publicly for discussion next week, on June 5th, as part of the official consultation. When the policy discussion opens, there will be an announcement through the usual channels: wikimedia-l, IRC, etc. You can find more details about the upcoming steps and dates of the consultation in the subtask T337863.

Hey @ldelench_wmf, the Security team's review is complete. You'll find below our feedback:

In T335892#8824828, @Xaosflux wrote:

Either a separate column, or a separate table is fine; I think there may be some exceptions to add as well, for example the page https://meta.wikimedia.org/wiki/MediaWiki:Gadget-common-special-search.js is on the list above, pointing to a yandex.ru link, however it isn't actually importing that, that is inside a comment - not sure how much effort would be needed or what the expected benefit of excluding comments would be

In T335892#8824658, @Xaosflux wrote:

Can the stats table be split by userscripts and gadgets? The later certainly have far more exposure, esp when counting userscripts of defunct users in the user table.

Hey there -- just a heads-up that I have started compiling some data on Gadgets and User scripts loading third-party resources across Wikimedia projects in T335892. This may help get a sense of the impact of the policy. The initial data is probably off/incomplete. So any ideas to get more accurate data is warmly welcome :)

My recommendation from a data privacy perspective is to show aggregated data only and keep the PII in the back end for 90 days, during which time participants can update their answers, after which time we anonymize the PII data and keep only the aggregated data.
As far as aggregated data, I recommend reporting out when we have more than x persons in a [sub]category; below that we could either not report out or report, for example a compilation "other <x"

Usually, with PII data on persons we set a minimum for calculating averages so the data cannot be disambiguated and persons identified.
Essentially, such data should not be disaggregated at small numbers. There may be a standard at 10, that is usually 20 though for power to detect differences. So, for example, if you have <10 persons in a [sub] category then you don't report out on that [sub] category.
Security and GDI teams may be able to provide additional insights and feedback.

Hey @Iflorez, how will that work if event organizers are able to view data at an individual level anyway (F35861130)? Will the detailed view of the Participants tab be unavailable once data is aggregated, after the 90-day window?

In T296847#8668241, @Bawolff wrote:

@sguebo_WMF given that the TPR policy is being proposed to be incorporated by reference into the terms of use, i think there is a desire for there to at least be a public draft, if not the final policy, prior to the comment period for the terms of use ammendments closing.

Thanks for the ping @sbassett. We could borrow some ideas from the generic message currently displayed when logged in users visit external links, and a privacy notice(T65598#6914486) which was provided by WMF-Legal. Privacy best practices encourage both brevity and clarity of notices. So, a more privacy-conscious message could be something along these lines:

Hey everyone, I agree that having the Security-Team review every single Gadgets and User script would not be scalable or even realistic.

Tagging Privacy Engineering for an opinion/risk rating about the following. I'm not certain there's precedent for this on Wikimedia production or that wmcs would completely satisfy any privacy concerns for proposed, embedded content like this.

Hello @Skizzerz, is there a publicly accessible repository for the source code of https://owidm.wmcloud.org?

@jrbs was added as a maintainer to the NDA bot, see (https://toolsadmin.wikimedia.org/tools/id/tsbot). Also, the code was moved the Wikimedia's Gitlab instance: https://gitlab.wikimedia.org/repos/security/tsbot-nda

The repository was imported to Wikimedia's Gitlab instance: https://gitlab.wikimedia.org/repos/security/tsbot-nda

I examined the proposed API through common privacy risk categories:

Hey @ldelench_wmf, I have no objections to closing this one, thanks.

Hello, some quick updates.

@ifried, the Security-Team hasn't gotten the chance to discuss the mitigating options surfaced in the Google Docs conversation. Meanwhile, I would like to keep the ticket open and update it once we've made some progress.

Hey @ifried, the Privacy Engineering review is complete. Could you take a look at our conclusions and address any potential misunderstanding there? https://docs.google.com/document/d/1lFeq7jtUCmXdwoKwIfqgO-74ccTU0kBtX7zkJkeMByw/edit#?

Hello @ifried, Privacy Engineering will start looking into this as part of our current sprint. On a side note, I am aware that the previous features have been looked at by WMF-Legal. For this additional feature, are you having any conversation with Legal in parallel?