Talk:Third-party resources policy

05 June 2023: Start of the policy conversation

Hello, feedback regarding the Third-party resources policy is welcome below this message. Feel free to use the initial questions below as a starting point for the conversation or bring your own. Thank you!

On behalf of the Wikimedia Foundation’s Security team — Samuel (WMF) (talk) 00:50, 5 June 2023 (UTC)

Are risks sufficiently explained and relevant?

This section heading was created by Samuel (WMF) at 00:50, 5 June 2023 (UTC).

A security-wise less educated user can probably not understand the scope of the risks from these explanations alone (it is e.g. not obvious what you can do through harvested cookies and session tokens). I suggest adding links to somewhere where the concepts can be discussed a bit more in depth (perhaps a tailored set of security pages). It could also be worth pointing out that anything the owner of the script can do can be done by an attacker who succeeds in bypassing their defences – a benevolent owner may still use naïvely coded building blocks for their own scripts or otherwise neglect security.

The section on user privacy and safety does not differentiate between what a tool does and what it could do when interacting with a third-party resource. I think the section should concentrate on information that leaks regardless on how the tool is coded, as that's the (implicit) rationale for the proposal. Other leakage can be mentioned, but as this may include anything that the third party could do on a direct connection, it doesn't need to be thoroughly covered here. The latter theme could be covered on a page on WWW safety.

–LPfi (talk) 14:25, 5 June 2023 (UTC)

Hi @LPfi: and thanks for these suggestions. I am taking good note of your point about including explanatory resources for less security-savvy and illustrating how code used "naïvely" can lead to security issues. On the other hand, the portion about leakage is not that clear to me. When you suggest that the section should emphasize "information that leaks regardless on how the tool is coded", do you mean that the content should describe what personal information could be leaked or are you suggesting something else? — Samuel (WMF) (talk) 17:41, 5 June 2023 (UTC)

My point is that the gadget forwarding session tokens, user names and the like is likely pure bad programming, while you cannot avoid sharing your IP address, operating system etc. if the gadget makes your browser connect to a third-party resource (previously stored third-party cookies are also an issue, I don't know how those typically are or could be handled). The claim that "scripts connecting to third-party resources may also share [...] the device they are using, their browser information, and location" seems wrong. Scripts run in one's browser usually cannot connect to the third-party resource other than directly, which means these titbits are shared automatically, regardless of how the script is coded (I assume also one's location is automatically shared through the IP in most cases).

   Now, those facts cleared, what are the consequences? Is the device fingerprint enough to pair you with a user account on Google or Facebook? Does Google get that fingerprint through common designs of such resource interfaces? Does that mean that Google can (and does?) get to know your Wikimedia username by comparing your interaction with third-party resources to actions at Wikimedia sites? More generally: what should the user be afraid of when using such third-party resources (knowingly or unknowingly)? (Few sites have enough info on their own that leaked IP and device fingerprint would be an issue.)

–LPfi (talk) 08:41, 6 June 2023 (UTC)

@LPfi: many thanks for taking the time to illustrate your previous comment. I think those are good ideas for making that section of the policy much easier to understand and informative. — Samuel (WMF) (talk) 20:44, 6 June 2023 (UTC)

Do the definitions and required precautions make sense?

This section heading was created by Samuel (WMF) at 00:50, 5 June 2023 (UTC).

It seems the proposed policy would require all interaction with third-party resources to be done through interfaces offered by WMF production servers. For it not to cause disruption, these need to be offered. My understanding is that OSM tiles are nowadays fetched and cached by these. Are there other resources needing similar treatment?

For the restrictions to make sense, WMF needs to guarantee privacy when using production servers or possible external resources needed e.g. for participating in elections and surveys. I am afraid WMF shouldn't trust third parties in such matters, but instead guarantee that no sensitive information is sent to third parties.

–LPfi (talk) 14:25, 5 June 2023 (UTC)

@LPfi: I hear your point and I agree that, generally speaking, safeguards should be in place to ensure the privacy of users. Regarding OSM, I'd like to note that the scope of this policy is purposely limited to User Scripts and Gadgets that load third-party scripts. Unless I am wrong, OpenStreeMap does not fall within those categories. — Samuel (WMF) (talk) 19:09, 5 June 2023 (UTC)

Yes. On OSM and the like: if there is a valuable resource out there, which is not available through official means, there is a big temptation to use it through gadgets and user scripts, which may be used by many and become a de facto standard (such as many of the Toolserver tools). If those tools are disallowed, there needs to be a mechanism to include access to the resources or a substitute through official means. I don't know what third-party resources are in such use, but this proposal suggests there is a non-trivial amount of such scripts and gadgets – unless the third-party resources are used just out of sloppiness.

Loading third-party scripts, fonts and stylesheets is a different issue. I detest that the practice is common on the web, and I have often argued that using free equivalents hosted on the web site itself should be the norm. If there is a real need for such resources, effort should be put in replacing them, probably in cooperation with the free software/open source movement in any non-trivial cases.

–LPfi (talk) 09:32, 6 June 2023 (UTC)

@LPfi: echoing some observations made on Phabricator, external resources that are most frequently loaded in User Scripts and Gadgets are translation-related resources (including Google Translate and Yandex), fonts, and a variety WMCS-hosted applications. —Samuel (WMF) (talk) 17:15, 6 June 2023 (UTC)

How do you think the policy should be enforced?

This section heading was created by Samuel (WMF) at 00:50, 5 June 2023 (UTC).

I have no idea how to enforce it, because it's not clear what this proposal tries to achieve. Judging from the discussions below, most people are confused about it as well, so this proposal won't be very effective if adopted as is. Since forever, stewards and global interface admins have been removing on sight any occurrence of code which would transfer our users' IP address to non-WMF servers in violation of their privacy.

By the way, if the Wikimedia Foundation is suddenly very interested in doing something to defend Wikimedia users' privacy from a growing influence of third-party software, it could start by stopping its reliance on proprietary software and SaaSS, such as GAFAM's and Interpol's mass surveillance/upload filtering software. Nemo 17:44, 7 June 2023 (UTC)

When would it make sense to start enforcing the policy?

This section heading was created by Samuel (WMF) at 00:50, 5 June 2023 (UTC).

• What would that even mean? If you delete the fluff, all this policy says is "Gadgets and user scripts should not load third-party resources". There are no requirements. Maybe this is just a language misunderstanding and you don't mean should in the rfc 2119 sense, but regardless it doesn't seem like there is anything to enforce here. Bawolff (talk) 16:39, 5 June 2023 (UTC)

• @Bawolff: "should" here is meant as a requirement rather than a suggestion. So, I understand how this may be confusing. As asked a bit below, I'm definitely open to considering language tweaks to make it sound more forceful. With respect to enforcement, there are at least a few things worth considering. How do we make sure all the gadgets and user scripts currently involved in privacy issues comply with the policy requirements? What would enforcement look like (eg: page blanking, CSP automatic block, etc)? Should there be a grace period before enforcement? Should enforcement be done in a phased way, with most critical gadgets and scripts having a longer grace period etc? Those are some questions that could be explored. As a side note, I don't believe that referring to most of the draft policy as "fluff" brings any improvement to the content. Instead, it is just dismissive to the efforts put in proposing something to be improved :). — Samuel (WMF) (talk) 19:37, 5 June 2023 (UTC)

  I agree that explaining risks and suggesting best practices is worthwhile. As the actual policy is already determined through the terms of use, one could indeed see all this as fluff, but I don't think we should nitpick on the status of this document.

   For the timing, I think the first thing to do is to check what scripts and gadgets there are in widespread use. Is there any sense in them not being MediaWiki features instead (Commons has a big problem in essential features whose maintainers would like to retire)? Does the WMF have the resources to take responsibility for their maintenance, and in what timeframe can the code be reviewed and any offending parts be fixed? Truly personal ones are probably less of a problem, even when they might compromise the privacy of their author – it is difficult to protect people from themselves.

   The scripts and gadgets that this policy should target are the ones that spread like DOS/Windows viruses: users sharing a sloppily written piece of code that nobody cares (or knows how) to check. In Windows this is a huge social problem rather than a technological one – best practices aren't socially acceptable. Here I hope the best practices are or can be made part of the culture.

   –LPfi (talk) 09:58, 6 June 2023 (UTC)

  @LPfi: I am following up here on my earlier Special:Diff/25119150 where I shared that fonts and translation-utilities are among the external resources that are loaded the most in UserScript and Gadgets. There are also smaller categories like Facebook Connect, Google Analytics, etc and some WMCS-hosted tools (see tables). For most of those resources, there are reasons why some of they are not currently part of MediaWiki core (if this is what you meant by Mediawiki features). For example, fonts have been associated with performance issues in the past (Phab:T166138#7223384), Facebook Connect and Google Analytics are associated with user tracking and would be incompatible with Wikimedia policies. Of course, not all external resources fall within those top categories, in particular WMCS-hosted resources. In that sense, what you mentioned about enforcing the policy by focusing first on the most harmful external resources sounds quite interesting. In line with that, would it make sense to have some criteria for establishing what makes an external resource more harmful than another? . — Samuel (WMF) (talk) 17:58, 6 June 2023 (UTC)

Should WMCS-hosted resources be considered third-party resources?

This section heading was created by Samuel (WMF) at 00:50, 5 June 2023 (UTC).

I assume that some of the resources are essential tools for part of the community, while coding tools isn't restricted to highly trusted users. For the proposed policy to make sense, tools that aren't scrutinised and controlled by trusted users must be regarded as third-party ones, while regarding all the tools as untrusted would cause severe disruption. –LPfi (talk) 14:25, 5 June 2023 (UTC)

I think you need to draw a distinction between tools that are on a separate website (that you choose to go to) and tools that get embedded into some sort of user script. The former is 99% of tools and the privacy analysis between the two situations are quite different. Bawolff (talk) 17:19, 5 June 2023 (UTC)

True. There is a big difference. The problem is where there is no real choice, as you need to use the tools to get things done, which means that the editors who use them aren't protected by the policy. That exposure should be minimised, and the true extent of exposure you get by using a tool should be made clear. If I make a Google search, I know Alphabet will use the info. When I search for a book on the library website, I know I tell the library, but I don't like them having me load scripts from Google just because they couldn't be bothered to use a free platform. –LPfi (talk) 10:08, 6 June 2023 (UTC)

@Bawolff and LPfi: I agree that the distinction is important here. Tools that are on a separate website but not embedded in gadgets or user scripts are outside the scope of this policy. For external resources that are embedded into gadgets and user scripts the "scrutinised and controlled by trusted users" seems like an interesting point (others will be needed as well) to identify resources that are not too risky, hence policed potentially differently. That being said, I am not aware of any process for actively monitoring user scripts and gadgets. Maybe Special:Gadgets? — Samuel (WMF) (talk) 19:49, 6 June 2023 (UTC)

Disallowing all WMCS tools would kill innovation. There are things that cannot be coded directly in gadgets (e.g. those that require access to the Wiki Replicas or can be released only under a free license incompatible with CC BY-SA), or are much harder to do in gadgets (e.g. those that need libraries that are written in a language different from JavaScript). Getting these be extensions is probably prohibitively hard in most cases. Maybe there could be a site where only “trusted users” (e.g. all local interface admins and global interface editors, as well as users considered trusted who don’t happen to have one of these two rights) can put code, but in a quick self-service manner, similarly to how gadgets and Toolforge tools work. Or instead of relying on people being trusted, it could be behind a WMF-controlled proxy that strips all data that could breach users’ privacy (e.g. don’t include the X-Forwarded-For header, don’t forward the User-Agent header and cookies). (Being a new site, maybe it could be required that all code MUST be on gitlab.wikimedia.org to provide an edit history similar to wiki pages, but with code review being only OPTIONAL part of the process.) —Tacsipacsi (talk) 10:05, 7 June 2023 (UTC)

There is wikitech:Wikitech:Cloud Services Terms of use which imposes restrictions on what tool developers are allowed to do on WMCS. Has this been taken into account? —MisterSynergy (talk) 23:31, 7 June 2023 (UTC)

Hi @MisterSynergy: and thanks for joining this conversation. Although wikitech:Wikitech:Cloud Services Terms of use is a distinct policy and scope, its context was taken into account as part of the work on this TPR policy. — Samuel (WMF) (talk) 23:50, 7 June 2023 (UTC)

Okay thanks.

I am still trying to figure out why WMCS is considered to be a third-party resource in this context. If WMCS is used properly, minimal to no PII is being exposed to tools hosted on WMCS; furthermore, WMF clearly has control over that platform and can, at least theoretically, monitor what tool developers are doing over there.

It seems difficult to draw a line that separates harmful from acceptable usage of WMCS via onwiki JS scripts, particularly as long as it is not clear what the actual problem with WMCS is. Given how important this platform is for editing Wikimedia projects, there should definitely be a path to make use of it. —MisterSynergy (talk) 08:14, 8 June 2023 (UTC)

@MisterSynergy: There are many reasons why WMCS-hosted apps are not viewed as production sites by this policy. I could probably mention that (a) they are not subjected to the same level of control as sites in all.dblist (eg: production sites go through a CI/CD pipeline with strict tests and checks), (b) the level of scrutiny and dedicated maintenance isn't the same as production websites, (c) the code ownership isn’t on par, which means security risks and issues aren’t necessarily owned and mitigated in a timely fashion. Of course not all WMCS-hosted resources collect tons of PII but we should acknowledge that they can at least capture IP addresses and User Agents (eg: using server variables for example). Also, because a WMCS-hosted resource is usually less secure than production, any malicious actors compromising that external resource could repurpose it, modify the DOM to display a UI prompting users for sensitive PII such real name, ethnicity, financial details. When combined, these details can identify very precisely users and give ways to all sorts of real-life abuse — harassment, identity theft, physical harm (cf. bawolff example). Not to mention that this kind of compromise can turn the victim’s wiki account into a bot, result in privileged accounts takeover, etc. So, unless we decide on some criteria for what resources could be allowed or not, the status quo would be to allow all existing and future external resources, no matter how harmful they can be to the security of users and the platform. — Samuel (WMF) (talk) 19:24, 8 June 2023 (UTC)

Thank you for the detailed answer. Let me address some aspects:

• In the beginning, you are assuming inferior code quality at WMCS compared to production sites. This is very likely correct, but this policy is not about code quality. It is surely a poor user experience if things break and not be fixed quickly, but this itself is not per-se a threat. Any real threat can also be immediately mitigated by deactivating the gadget onwiki.
• Hostile tool takeover situations are indeed something to consider that I have not thought of until now. Has this already happened in the past?
• In order to turn a victim's account into a bot, the user needs to actively authorize the tool via a metawiki (?) dialogue that requests detailed access. This might be a criterium to consider indeed. However, a gadget that e.g. just requests data from an API hosted on WMCS without authorization cannot take over the account.
• I am not familiar with all of WMCS's services, but at least for Toolforge, some PII is systematically being hidden via a proxy. PHP server variables do not contain IP addresses, for instance; some PII such as user agents and language settings of the user's browser are probably exposed to tools, though.

My impression is that this policy proposal grossly underestimates the importance of WMCS for many editorial workflows. At the same time, some of your reasoning seems a bit far-fetched to be honest, and not directly applicable for the implementation of such a restrictive policy with regards to WMCS. —MisterSynergy (talk) 20:22, 8 June 2023 (UTC)

I think people are talking past each other due to ambigious language. My impression is that samuel is referencing the situation where a gadget doesn't just access an api but loads javascript hosted on toolforge. In such a situation a hostile take over could take over the user's account on wiki. However i think it is fairly rare (but not unheard of) for such setups to be used. I think the oauth take over, well a potential security risk, is not really a privacy risk, as the tool's website is the primary entry point, so toolforge's privacy policy should be controlling instead of the main privacy policy. Bawolff (talk) 21:09, 8 June 2023 (UTC)

MisterSynergy, bawolff is right that I am talking about gadgets and UserJS that loads javascript hosted on Toolforge. Sorry for any confusion. To answer your question about account takeover, there have been serious issues involving UserJS and third-parties leading to account compromises of privileged users. Obviously, I am not allowed to discuss specifics publicly. However, don't get me wrong, as a TF maintainer myself, I highly value the importance of WMCS within the realms of Gadgets, UserJS, as well as the broader Wikimedia ecosystem. — Samuel (WMF) (talk) 19:26, 9 June 2023 (UTC)

What am I missing here? The policy proposal is not restricted to executable scripts from third-party resources (including WMCS). To my understanding, accessing any sort of third-party resources is about to be forbidden due to potential privacy issues, and this should by default also include WMCS. Am I wrong here? —MisterSynergy (talk) 20:07, 9 June 2023 (UTC)

I would agree with MisterSynergy that it is confusing to deal with supply-chain risk in user scripts/gadgets, in the same breath as privacy risks of loading external resources. I think these should be dealt with separately and it should be clear which type of risk we are trying to deal with. (As an aside, is the serious issue we are indirectly referencing without talking about T194204 or something else? Because i dont think that had much to do with third party resources, but maybe that is not what you are referencing) Bawolff (talk) 23:01, 9 June 2023 (UTC)

Bawolff, T194204 is not what I was referring to. On the other hand, T296855 is an example of security incidents that were caused by TPR being embedded in a UserJS or Gadget. — Samuel (WMF) (talk) 18:42, 13 June 2023 (UTC)

I disagree with your characterization of T296855. AntiCompositeNumber (talk) 21:29, 13 June 2023 (UTC)

I don't have access to T296855, but the publicly available data is: There was a user (3 actually) who were banned for something related to T296855. One of those users created a user-space page, they then sent a message to an admin asking for advice on that page. 40 minutes later the admin's account is taken over and edits common.js. Over the next several hours, the user's subpage is deleted for having "Potentially dangerous code", the user is blocked for "Attempting to hijack other people's accounts", and one of the admin's local user scripts that they use, which previously hasn't been touched in months, is rewritten out of the blue, which happens to fix an XSS vulnerability in that script. I don't have all the details, but this seems to paint a pretty clear picture of a situation that would not be fixed by banning third party resources. Bawolff (talk) 21:54, 13 June 2023 (UTC)

Regarding T296855, step 2 within the task description very clearly indicates how a third-party resource (hosted at github.io) was used as part of that attack. That really isn't up for debate IMO. One could potentially argue that it wasn't the _primary_ method used in the attack, but to argue that it wasn't a key means of obfuscating a payload incidental in the attack is incorrect IMO. And I personally believe it is dubious to suggest that simply because an attack _could possibly_ be carried out via other means, that attempting to better contain certain avenues for abuse - which we've literally witnessed as methods within real-world attacks against the projects - isn't worthwhile. @Bawolff - I would imagine the events of the flea incident from several years ago are still somewhat fresh in your mind, and many of those attacks involved the usage of external resources to obfuscate certain attack vectors, so there are indeed other real-world examples. SBassett (WMF) (talk) 01:35, 14 June 2023 (UTC)

I agree that previous attackers have utilized externally hosted resources for their second stage command & control infrastructure. However i'm not aware of any that have used that as their way in. I'm also mindful that the industry in general has seen an uptick in supply chain attacks (solarwinds, the npm ecosystem issues come to mind). However, i don't think as written this policy does a good job of preventing those previous attacks wikimedia has experienced. They weren't the way in but things people did after they took control. By definition, malicious people are malicious, and don't follow policies. I don't see why they would follow this one. Now, perhaps the plan for this policy is to be a lead in to restrictive CSP. Which if implemented properly would reduce risk of external command & control. If so, then i think that should be talked about more in the policy (Just look at how many words have been spent over whether this policy should apply to user scripts, site js, MW extensions, WMCS etc. If the real goal here is to enforce technical measures to prevent external communication, then that settles all of those issues). Ultimately i don't think the aforementioned attacks are the most compelling motivating examples - once the attacker is in, making their life a tad bit more difficult, well nice if free, doesn't quite seem worth all this. At the very least it seems like a much better first thing to focus on for gadget security would "unsafe-inline" removal. As far as third-party resources go, I personally find arguments related to privacy or even supply chain risk much more compelling as it directly impacts those risks. p.s. i should clarify that I'm not opposed to this policy in general, i just think the phrasing of it is so ambigious that there is no shared understanding of what it all means. Bawolff (talk) 04:02, 14 June 2023 (UTC)

Some of this is fair, even if I disagree with it slightly, but is this policy attempting to justify itself solely on TPR being used as the primary attack mechanism during numerous Wikimedia security incidents? I was not left with that impression. The only line I might change to avoid that perception would be in the first paragraph where it states "This has sometimes led to account compromises and privacy issues". That might make more sense to read "This has sometimes been a component of account compromises and privacy issues" or something to that effect. Personally I'm not a fan of attempting to find a perfect solution for any security issue and vastly prefer a layered, if imperfect, defense, as that is often the only feasible approach IMO. While not specified within this proposal (as we are often told to avoid "solutioning" in initial proposals) I believe there are several things that could be done to improve the current state of TPR on the projects and within other Wikimedia systems. The fact that so much discussion has already occurred on this page, to me, indicates that at the very least there should be some canonical, living standard around acceptable use and best practices (if not something as hard and demanding as a policy) for TPR. SBassett (WMF) (talk) 13:59, 14 June 2023 (UTC)

@MisterSynergy: Yes, the current scope of the policy covers all UserJS and gadgets that connect to non-production websites, including WMCS-hosted tools since those have traditionally not been considered part of “production”. However, I acknowledge the many concerns raised about forbidding all external resources and the burden it would place on the community. This is why I am calling for ideas about exemptions. For WMCS specifically, the point is specifying under what conditions we could allow gadgets and user scripts to connect to WMCS-hosted resources. What would those conditions (aka, exemptions criteria) be? Do those criteria provide users of Gadgets and UserJS with adequate security and privacy safeguards? As said earlier, the aim with those questions is to identify exemptions that could become part of the policy. — Samuel (WMF) (talk) 18:44, 13 June 2023 (UTC)

IMO the special situation about WMCS is that things over there are pretty transparent. It is a hosting platform where we (WMF staff as well as more than 2000 volunteer tool developers) can see which data is collected and how it is being processed. The ToU of WMCS that restricts data collection is also under our control. This is a fundamental difference to actual third-party resources outside Wikimedia servers where we really have no clue what is going on.
What matters most in my opinion is that the tool sources at WMCS are readable for other tool developers. This enables a large group of users to access tool sources for a review. By default this is the case (at Toolforge), but tool developers can restrict read access to themselves using chmod if they want to. However, except from secret files, logfiles, and possibly a few more cases, this should really be discouraged and possibly forbidden if the tool is accessed by an onwiki script/gadget. Source control is nice to have, but since there is no guarantee that the actual tool is using the exact sources from the repo, I am not sure whether this is an actual criterium here. —MisterSynergy (talk) 19:20, 13 June 2023 (UTC)

@MisterSynergy thanks for these points. I have made a note of the need to have the source code public as well as the requirement that the code hosted on WMCS be inspectable. I'll keep reviewing those exemptions ideas alongside the others shared in this discussion. IMO, those are complementary criteria for WMCS specifically, as a public source code can help with public scrutiny and the requirement that the actual tool's code be inspectable can help with audits at the WMCS-level. While I am not aware of specific code-scanning for vulnerabilities and abuse in WMCS-hosted code, if the actual tool code is readable (except for config files, etc), I imagine audits such as phab:T286416 can help detect suspicious code. Of course, it's not a guarantee that WMCS-hosted resources will never contain harmful code that'll affect Gadgets and UserJS users, but those best practices can reduce the likelihood of abuse. — Samuel (WMF) (talk) 10:55, 15 June 2023 (UTC)

Examples of what this will end

Would be good to clarify what features this policy will end. For example we have the option for relief maps on WikiVoyage which notifies users that to activate it will share details with an external service.[1] I imagine this policy would end that? These relief maps are excellent especially for hiking.

Additionally we have a great deal of functionality on the wmcloud which could than become less usable, which IMO would be unfortunate. Doc James (talk · contribs · email) 10:57, 5 June 2023 (UTC)

Yes, I'm confused on how OpenStreetMap falls into the "Risks" category. SHB2000 (talk | contribs) 11:48, 5 June 2023 (UTC)

Hello @Doc James and SHB2000: and thanks for joining the conversation. The scope of the policy is purposely limited to User Scripts and Gadgets that load third-party scripts. It is my understanding that the Wikivoyage and OpenStreeMap examples you mentioned do not fall within those categories but I am glad to be proven wrong. That being said, it's worth noting that gadgets and scripts sharing user information with third-parties has always been a practice in conflict with both the Terms of Use and Privacy Policy (see Purpose section of the draft policy).

With respect to Wikimedia Cloud Services-hosted resources, you are raising a valid concern. Recent data-driven observations have surfaced that many of those resources conflict with the Wikimedia Privacy policy and Terms of use but are also helpful to various editing activities. This is why this policy conversation also explores the question of whether some WMCS-hosted resources should still be considered "third-parties" (see WMCS section above). The aim there is to evaluate avenues to enable some of those important editing-related resources while providing decent security and privacy guarantees to end-users. Any thoughts you may have in that direction are obviously welcome.

Samuel (WMF) (talk) 15:20, 5 June 2023 (UTC)

i think it is a mistake to only include user scripts and gadgets here (presumably you are also including common.js which is neither a user script nor a gadget). Rules for thee but not for me type policies tend to trigger resentment and the privacy concerns don't change depending on who is writing the code. Bawolff (talk) 16:27, 5 June 2023 (UTC)

@Samuel (WMF) I read the tickets and the collected statistics do not seem to differentiate between site resources, gadgets and user scripts. Notably MediaWiki:Kartographer.js used on Wikivoyage exactly as described, seems to be included in this collected dataset. —TheDJ (talk • contribs) 09:02, 6 June 2023 (UTC)

Hi @TheDJ: as part of the methodology used to gather that data, gadgets were looked up within the User and MediaWiki namespaces. Due to the multilingual nature of Wikimedia projects, filtering by namespace and looking up the page content were the most functional approaches found. This can explain why some noise may show up in the data. Also, the point was to highlight the external resources involved in top recurrent CSP violations that involve gadgets and user scripts. So, a certain level of noise was acceptable. Would you have any tips for differentiating between those types of scripts? — Samuel (WMF) (talk) 16:33, 6 June 2023 (UTC)

Exactly what passage of the Privacy policy or the Terms of use do gadgets and scripts conflict with if they contact with third-party services, but only with explicit user consent? —Tacsipacsi (talk) 10:09, 7 June 2023 (UTC)

Hi @Tacsipacsi: and thanks for joining the conversation. When you are talking about gadgets and scripts that "contact third-party services, but only with explicit user consent?" are you referring to user scripts and gadgets that display a type of privacy notice to users? — Samuel (WMF) (talk) 14:13, 7 June 2023 (UTC)

Yes. —Tacsipacsi (talk) 21:41, 8 June 2023 (UTC)

Thanks for clarifying Tacsipacsi. What "explicit user consent" means and whether displaying a privacy notice satisfies ToU requirements is something Legal is best positioned to answer. I have escalated your specific question accordingly and will keep you up-to-date as soon as I have an answer. — Samuel (WMF) (talk)

• This will likely break community grown tools that reach externally such as w:en:Wikipedia:RedWarn/w:en:Wikipedia:Ultraviolet/Install, possibly JWB. — xaosflux ^Talk 17:50, 13 June 2023 (UTC)

  xaosflux, and why do they do? ToBeFree (talk) 20:00, 20 June 2023 (UTC)

  @ToBeFree because they import scripts from external sources. (JWB may be all in house now RW/UW are directly importing off-wiki). — xaosflux ^Talk 21:27, 20 June 2023 (UTC)

  Sorry xaosflux, my question was unnecessarily ambiguous. What I actually wonder is why they import scripts from external sources. If I may guess, possible reasons are developer convenience and performance, not hard technical or legal limitations. ToBeFree (talk) 04:19, 21 June 2023 (UTC)

  @ToBeFree mostly yup, personal user script writers do things that work best for them - one of the benefits of the system! — xaosflux ^Talk 10:47, 21 June 2023 (UTC)

  A privacy issue caused by a long period of overly lax policing, I'd rather say. Forcing developers to do what's best for users rather than themselves isn't always necessarily bad. ToBeFree (talk) 11:13, 21 June 2023 (UTC)

  @ToBeFree I don't think we are too far apart on at least part of this! I think there is a difference between empowering users to innovate and develop vs what is served to unsuspecting users. I think the TPR ideals are perfect for sitescripts and default gadgets, and probably even for opt-in gadgets. I don't think we need a brightline that is just going to move the same things to even harder to check deliveries like greasemonkey or standalone external widgets/apps/applications. — xaosflux ^Talk 12:18, 21 June 2023 (UTC)

  I'm a bit late to the discussion but I thought that the reasons for the above was worth explaining. The reason why Ultraviolet is currently hosted off-wiki (and why RedWarn was almost transferred off-wiki) is due to potential licensing issues, since the software is released under the Apache License 2.0 and there was a suggestion (forgive me for being unable to find the link to that enwiki discussion) over a year ago to remove scripts that were not explicitly CC BY-SA-licensed as copyright violations. There was also some pushback on having minified code hosted on-wiki (even if our source code is publicly available, hosted on Wikimedia GitLab, and fed straight from CI/CD output) and, with a heavyweight script like UV, we may easily break past the 2MiB size limitation for on-wiki pages if we didn't minify. Hosting on Toolforge also gives us more leverage with caching because of the Cache header which we otherwise wouldn't have with just mw.loader.load, unless we made en:User:SD0001/Making user scripts load faster mandatory. Chlod (say hi!) 14:27, 1 July 2023 (UTC)

This is a step backwards on our strategic goals

I'm concerned with this proposal, and I have some reasons. Graphs have been broken for more than a month now, and it doesn't seem that they are going to recover, losing opportunities to show things in a more interesting way. Some efforts we have made to show Ourworldindata maps and graphs are also stopped at "security review". Some years ago, we launched (and invested lot of money on) a system that would read the articles in some languages but it never succeeded because of the same reason.

And I would accept that having third-party resources is not the best option if we had product team working on those features. But this isn't happening and doesn't seem it will happen in the future. Some years ago we were obsolete. Now we are paleolithic, a relic for archaeologists of the Internet. Meanwhile, other platforms are advancing by the day on new features. Every day we are further from our 2030 strategic goal. Theklan (talk) 11:18, 5 June 2023 (UTC)

I don't know what the article reading thing was, but security was hardly the only reason ourworldindata didn't happen, just the first hurdle it had to face. Besides technical concerns, the elephant in the room is that it was very unclear if enough users wanted it to make it worth it. Bawolff (talk) 17:00, 5 June 2023 (UTC)

Let alone who was going to do the amount of work to make it viable within the WMF setting (ddos strengthening, privacy isolation, security, parsoid and VE support, cache consistency and purging). We are further away from 2030 goals, but this is not something unexpected. I and many others have been warning from the start of that whole process that we were already overstretched and that implementing the 2030 goals would require at least tripling the tech department, if not more. This was ignored for a long time and we have had several crisis with code maintenance as of late that clearly surfaced how fragile many elements were. —TheDJ (talk • contribs) 19:41, 5 June 2023 (UTC)

@Theklan: thanks for voicing your concerns through this discussion. However, OWID review and the Security team's workflow more generally are outside the scope of this policy. — Samuel (WMF) (talk) 20:14, 6 June 2023 (UTC)

The problem is that, as TheDJ points, most of the things we need are not developed. If third party content is not possible and, at the same time, we are not creating those things, the obsolescence will only grow. Theklan (talk) 20:42, 6 June 2023 (UTC)

@Theklan: this is a valid concern. For the specific context of user scripts and gadgets, there is an exploratory reflection on if and when some WMCS-hosted resources could be treated differently than the other third-party resources. If you have some ideas in that area, please share under Should WMCS-hosted resources be considered third-party resources?. — Samuel (WMF) (talk) 20:58, 6 June 2023 (UTC)

There should be a Product department just making the product better. Is not what we consider as third-party resource: is how we do to have first-hand resources for our needs. Theklan (talk) 21:01, 6 June 2023 (UTC)

Ok, I'm going to be frank here.... Other than Sam, most of the security team knows jack shit about Wikipedia and the people who built it. Most of the issues this proposals deals with, would not be an issue if the foundation had invested properly in tools and content that people had been asking for. Instead now we DEPEND on the external stuff and you are taking it away. This is not a technology or security issue you now have, but a social issue that you need to negotiate. Saying "sure but that's not our problem, its another team" is NOT the appropriate response. —TheDJ (talk • contribs) 08:04, 7 June 2023 (UTC)

To be clear, by "Sam" are you referring to Reedy? Nardog (talk) 09:26, 7 June 2023 (UTC)

Yes. --MZMcBride (talk) 16:16, 7 June 2023 (UTC)

This doesn't read like a policy

Policies are rules that people are obliged to follow or operating procedures. This just has some suggestions and best practises. If the document has no rules it is a guideline not a policy. I think this makes the intended purpose of this document confused.

Other comments:

• i think the way this is using the term third party is confusing and misleading. The word third party makes people view this through the wrong lense. Often in other documents that refers to the authorship of the resource not the hosting provider (consider also external resources that are proxied or locally made resources hosted on github). I would suggest using the word "externally hosted" instead.
  • Additionally, this desperately needs to clarify where non-production resources (toolforge) falls (and any other things hosted by wmf that are not covered by the main privacy policy). Normally these would be considered external since the normal privacy policy doesn't apply.
  • it should maybe clarify if wmf can use such resources if contractual obligations are in place to ensure the privacy policy is followed.
• it should clarify if the user is allowed to consent to such services (say if enabling a gadget) and under what circumstances consent is allowed as an escape hatch (my 2 cents is it should be acceptable in optionally enabled gadgets/user scripts but not in anything global enabled. But there is already an exception at wikivoyage)
• i would suggest replacing the term end-user with user. End-user sounds a bit dehumanizing, but maybe that is just me.
• this should probably emphasize not just explicit persinal info but incidental collection. E.g. when the external resource doesnt collect anything but their hosting provider logs ip addresses, etc.
• re xss. This probably underplays the risks of xss a bit. However at the same time it is way too close to implying that xss is the only privacy risk here, which i think is misleading.
• i think the "consider alternatives" section should be removed. I dont think it fits with this document; how to make a user script belongs elsewhere. Second it sort of implies that once you have considered alternatives you can use third party resources if no first party stuff does what you need. Third - realistically it is going to be pretty rare that that there is a local resource doing the exact same thing, especially when it comes to proprietary apis.

Bawolff (talk) 16:23, 5 June 2023 (UTC)

I'd like to second the first point. In my reading, despite being labelled a "policy", this document does not require anyone to do anything, it only offers suggestions. It needs to be rephrased or renamed, depending on what was intended, before we can really discuss its contents. Matma Rex (talk) 18:29, 5 June 2023 (UTC)

Hi @Bawolff and Matma Rex: and thanks for joining the discussion. I'd like to address some of the points shared while continuing to give the others some thoughts.

• While I get the part about the text not reading like a policy, it is my understanding that the Required precautions section contains firm requirements such as "Gadgets and user scripts should not load third-party resources". Do you have any suggestions to tweak the language in a more assertive way perhaps?
• I am not sure I get the portion about underplaying XSS. Do you think those risks should be emphasized, explained differently?
• The "third-party" term was chosen to align more with the terminology used across the industry, especially within the Third-party risk management ecosystem.
• WMCS-hosted resources are currently considered third-party resources. That being said, recent data-driven observations make it worth asking if and when some of those resources should be considered differently, hence the open questions at the top about WMCS.

— Samuel (WMF) (talk) 18:55, 5 June 2023 (UTC)

I suggest "must" instead of "should" and "could" if these are indeed requirements. Matma Rex (talk) 19:24, 5 June 2023 (UTC)

Yeah, "avoid" is weak. It's a recommendation. It's a form of feedback from the Security team to the community, not a matter that requires feedback in return. ToBeFree (talk) 19:56, 5 June 2023 (UTC)

• re "aligning with industry" - i think that is the major problem here. Most of the parts of this policy that don't make sense here would make total sense as a part of a corporate policy designed to mitigate risk of third party components and supply chain attacks. The weaker language would make total sense in a corporate context where the assumption is that everyone has the same goals, people get fired if they play too fast and loose with doing what they "should" be doing, but exceptions still happen and there is a management chain to accept risk when things deviate from their ideal form. However that is not the context we are in, a top down policy from wmf is more like a law. If it doesn't set out specific binding requirements nobody will listen.
• Similarly i think "third-party" is confusing here because the context and threat model is subtley different from how most of the industry talks about such things. Not to mention the number of parties involved and their relationships.
• regarding wmcs - i dont think that data is very meaningful by itself. Clearly there is an apetite to access external resources, but just from the data we don't know in what context the external api was called, what consent was obtained. More importantly we don't know what expectations the users have or how that varries between different groups, including vulnerable groups. Something being popular is just one part of the analysis, we should also analyze what the risks are, which are acceptable, which can be mitigated, etc.
• re xss. To a lay person stealing session token sounds like some obscure piece of metadata, better to focus on actual consequences (e.g. turn your account into a vandal bot). But i would also talk about how for certain vulnerable people leaking the wrong person's ip to the wrong people could in the extreme case result in people dying. Privacy needs are extremely person specific.

Bawolff (talk) 20:50, 5 June 2023 (UTC)

@Bawolff: I have taken good note of the points you mentioned and will keep them in mind alongside the other comments shared in this thread while preparing the next update of the policy, thanks. re data - Sure beyond the popularity criterion, a risk tiering of these resources is important. This is the point in these questions about WMCS exemptions and the criteria attached to those exemptions. Having criteria that help establish why some resources are Low risk while others are High can help identify mitigations for a whole set of resources, both existing and future, depending on their risk tier — Samuel (WMF) (talk) 17:52, 8 June 2023 (UTC)

i disagree that risk tiering is important or even viable for this policy (beyond treating executable content different from non-executable content, but that is really more a security thing than a privacy thing). It might make for interesting data but i'm not sure what we would take away from that. Risk is context specific and cannot be evaluated outside of a specific context. Often there is an implicit context that makes sense, but it is unclear what that would be here. Bawolff (talk) 18:21, 8 June 2023 (UTC)

Exemptions

I think there should be some exemptions: — xaosflux ^Talk 16:25, 5 June 2023 (UTC)

Personal exemptions

There should be an exemption for user's personal script files (e.g. Special:MyPage/vector-2022.css), these are self-managed and only apply to yourself. — xaosflux ^Talk 16:25, 5 June 2023 (UTC)

Perhaps you get an on/off to accept these in your prefs... — xaosflux ^Talk 18:54, 5 June 2023 (UTC)

The problem is that users use eachothers css/js files.. and only one of those users needs to have sysop, interface admin or checkuser rights to create complete chaos. —TheDJ (talk • contribs) 19:43, 5 June 2023 (UTC)

which is probably a good argument to not conflate non-security privacy issues (non-xss) and security (xss) together in policies. Users can opt in to lower privacy and only affect themselves. They can't opt in to low security without affecting others. Bawolff (talk) 19:49, 5 June 2023 (UTC)

Users use other people's browser extensions too, but in both cases they are choosing to do that themselves, to themselves. — xaosflux ^Talk 19:59, 5 June 2023 (UTC)

Regarding users loading other user's scripts: that doesn't require a third party to cause a potential problem; if you load someone else's script you are subject to anything they put in there, the bad code can be local (as this discussion is about third party resources, not about prohibiting all local scripts as well). — xaosflux ^Talk 20:04, 5 June 2023 (UTC)

Hey @Xaosflux: and happy to read your inputs here. I may be wrong but it seems to me that the personal exemption you described does not fall within the remit of this policy since the scope is gadgets and user scripts hosted outside Wikimedia production websites, not personal on-wiki scripts. So, there is no need to include any "personal exemptions" in the policy. Is there a point I am missing? — Samuel (WMF) (talk) 21:52, 5 June 2023 (UTC)

@Samuel (WMF) no, what I'm saying is that personal userscripts should be exempt from this whole thing. They are self-managed, and your self-management can only impact yourself. If you choose to trust another that should be up to you - just like you can skip this whole thing and just put your userscript in your browser directly -- this just makes it more annoying for anyone that works on multiple browsers. Someone above made the argument that User:X could load User:Y's script, and User:Y could be loading EternalSite:x's script as some sort of special worry-- but user:x can just install SpywareBrowserExtension- if they choose to trust someone else that's what happens. — xaosflux ^Talk 22:17, 5 June 2023 (UTC)

I think that there is two separate thing. With normal and even admin user rights the complete chaos is limited to something which is revertable. Result would annoying, but in the end pretty harmless. With interface admin rights the result could be something what cannot be easily reverted (like leaking private information). One thing what i would like to see to mitigate this is that if I have interface admin right then I could enable / disable the interface admin editing on fly from user settings so it could be toggled on only when I need the right for editing the pages. Changing the value could be confirmed with two-factor-auth. -- Zache (talk) 03:34, 9 July 2023 (UTC)

Project exemptions

There should be a process for a project to determine if a TPR may be acceptable (such as by publishing a gadget), as per-user opt-in only. Some projects innovate with external resources such a mapping or translation services that there are no sufficient internal replacements for. — xaosflux ^Talk 16:25, 5 June 2023 (UTC)

In a world with SUL it is very difficult to effectively isolate these sorts of things per-project Bawolff (talk) 17:01, 5 June 2023 (UTC)

@Bawolff there are no global gadgets, so if these are opt-in only, you'd have to opt in at each project. Agree that a default-on gadget would affect unknowing users. — xaosflux ^Talk 18:50, 5 June 2023 (UTC)

if each individual user is opting in, i think that is workable. For default enabled though, there is enough cross-wiki integration in wikimedia (not to mention everything being cors linked) i would worry that the user's privacy could potentially be compromised in some circumstances even if they never intentionally use the project in question. I guess it would matter a lot on specifics. Bawolff (talk) 18:58, 5 June 2023 (UTC)

@Bawolff 100%! I'll clarify that above. — xaosflux ^Talk 19:02, 5 June 2023 (UTC)

Proxy servers

Currently, https://fontcdn.toolforge.org/ is a proxy server for the Google fonts server. Would anonymizing proxy servers such as these fall under the category of third-party resources that could not be used? isaacl (talk) 17:33, 5 June 2023 (UTC)

i don't know what this policy's take on it is, but the historical answer is that it is not allowed e.g. see discussion at https://phabricator.wikimedia.org/T209998 Bawolff (talk) 17:43, 5 June 2023 (UTC)

Thanks for the pointer to the Phabricator ticket. I'm unclear then why the proxy server is hosted on toolforge, if using it for Wikimedia-hosted pages or tools isn't currently considered appropriate. isaacl (talk) 20:52, 5 June 2023 (UTC)

it is considered appropriate for toolforge tools but not the main site. The main site is covered by a much stricter privacy policy than toolforge is. The historical view is that private data should not be transfered from main site to toolforge, as otherwise it would be a pretty big loophole if one could get around the privacy policy by just transfering the data to a wikimedia site not covered by the (main) privacy policy. Bawolff (talk) 21:06, 5 June 2023 (UTC)

Hi @Isaacl: and thanks for taking part in the discussion. Since WMCS is not part of Wikimedia production websites, the WMCS-hosted resources are currently considered third-party resources. However, this conversation is part of an exploratory process and thoughts on if and when WMCS-hosted resources should be considered differently are welcome. — Samuel (WMF) (talk) 22:37, 5 June 2023 (UTC)

One of the many flaws of this proposal is that it lists Complete list of Wikimedia projects as production websites. Based on that definition https://fontcdn.toolforge.org/ and https://maps.wikimedia.org/ fall in the third-party category, but it's no problem to include content from http://www.wikimedia.org.ph/ and https://translatewiki.net/wiki/. Multichill (talk) 21:28, 7 June 2023 (UTC)

Localhost

Please do not use CSP headers to block http://localhost and http://127.0.0.1; this "external" site is under the user's control and is useful for script development. Suffusion of Yellow (talk) 18:17, 5 June 2023 (UTC)

Hello @Suffusion of Yellow:, and thanks for raising this concern here. However, CSP rules are outside the scope of this policy discussion. You can look at this Phabricator ticket to see if it is a more suitable avenue for your suggestion. — Samuel (WMF) (talk) 21:05, 5 June 2023 (UTC)

Ok, so is this is going to be a "social" policy, with no technical measures to prevent the fetching of external resources? Or with this be prevented by some other means? Either way, please don't define localhost as a "third-party resource" even though it's "located outside Wikimedia production websites". This would be equivalent to policing what software I'm allowed to have on my computer. Suffusion of Yellow (talk) 17:04, 6 June 2023 (UTC)

@Suffusion of Yellow: by "social" do you mean that the policy will be enforceable by the community, as here for example? Then yes, although it is good to note there are ongoing plans for technical measures to prevent the fetching of external resources (see phab:T135963). That being said, ideas for enforcing this policy more specifically are welcome. I hear your other point about localhost URLs being part of your personal space. In that case it makes sense to think more broadly about those locations since other users may use custom domain names, local IP addresses, etc. In the event that exemptions are considered as part of this policy, what might be a good way to identify those local resources? — Samuel (WMF) (talk) 18:49, 6 June 2023 (UTC)

Expanding on a suggestion by Bawolff in that task, a user preference, maybe? That is, I go to Special:AllowedThirdPartySites, get asked for my password, then add "127.0.0.1", "foohostname.barnetwork", and so on. Suffusion of Yellow (talk) 19:06, 6 June 2023 (UTC)

New wiki for code incompatible with the CC-BY-SA?

Any thought of creating a new SUL-connected wiki, e.g. https://code.wikimedia.org/, not subject to the CC-BY-SA (but still requiring some sort of free license) where we can store GPL-"contaminated" user scripts? Then there would be no need to choose between reinventing the wheel, and storing such code on an "third-party" site. Suffusion of Yellow (talk) 18:33, 5 June 2023 (UTC)

Personally i think we should have a specific gerrit (or gitlab) repo for this, not subject to the normal CR requirements (that is then automatically deployed to the site). MediaWiki isn't a fun source code management tool. Bawolff (talk) 18:38, 5 June 2023 (UTC)

@Suffusion of Yellow: would this be place where users scripts would be "scrutinised and controlled by trusted users" as in LPfi's point? — Samuel (WMF) (talk) 20:32, 6 June 2023 (UTC)

If we go with my suggestion, then it would handled just like we do know; a few "trusted" users can manage scripts like https://code.wikimedia.org/MediaWiki:example.js, but anyone can put what they want in their userspace, e.g. https://code.wikimedia.org/User:Suffusion_of_Yellow/example.js. The only difference would be with the copyright disclaimers. Suffusion of Yellow (talk) 20:45, 6 June 2023 (UTC)

I like this idea, as I think it would mostly serve as a CDN or sorts, thus consolidating "external" code and making such resources easier to find, manage and audit. I don't like the idea of using SCM like Gitlab or whatever as a CDN in this case; I feel like those interests should be kept separate when feasible. Of course we should encourage anyone developing userJS or Gadget code to use modern SCM and appropriate CR processes. SBassett (WMF) (talk) 17:10, 8 June 2023 (UTC)

This is fundamentally flawed

Sorry, but it seems clear from what you've written here and your replies above that you don't really understand how things work on the wikis. You wrote "should" but claim you meant "must", you don't seem to have a clear understanding of what a "user script" is, you've made contradictory statements about CSP, and so on. IMO you should scrap this, get some advice from people who understand the ecosystem you're trying to change and the language used by people in that ecosystem, and then come back with a fresh proposal once you better understand exactly what you're proposing. Anomie (talk) 02:58, 6 June 2023 (UTC)

Hi @Anomie:, the policy draft and the broader consultation process come after preliminary rounds of discussions during which "advice from people who understand the ecosystem" was gathered: interface admins, gadget and user script authors, Wikimedia developers, staff, and various long-term contributors. The aim of this discussion is to improve the draft by exposing it to a much larger audience and benefitting from a bigger pool of inputs. If you have specific areas of improvement such as the language and explanations that seem contradictory, feel free to elaborate on them. — Samuel (WMF) (talk) 10:20, 6 June 2023 (UTC)

I'm not qualified to speak on the technical side, but I am sceptical that a sufficient consultation was done with those who know the ecosystem and how to write these things with the should/must split and much of the language reading as suggestions not obligations. Those are fundamental concepts of any wikimedia policy writing, not merely a matter of better language. Nosebagbear (talk) 15:24, 6 June 2023 (UTC)

Judging from the removal of jquery.tipsy’s removal, I believe no one in WMF development knows what a user script is. I agree this should be scrapped. Al12si (talk) 21:36, 9 June 2023 (UTC)

Day 1 thank you

Hi everyone, I want to say thank you for the initial comments! There were some good recommendations around the policy language, questions on the scope of the policy, and ideas about exemptions, especially regarding some WMCS-hosted resources. The Security team will continue to review those inputs and the new ones as they come in with the aim of updating the policy draft iteratively. — Samuel (WMF) (talk) 09:53, 6 June 2023 (UTC)

This is such a confusing way to structure a talk page. If you're preemptively creating sections, please comment and sign right under each heading. Otherwise it looks like the first commenter created that section. Nardog (talk) 12:35, 6 June 2023 (UTC)

Hi @Nardog: thanks for taking the time to improve the page structure and headings. This is much appreciated. — Samuel (WMF) (talk) 20:17, 6 June 2023 (UTC)

Please do not take away our ability to use third-party scripts

There are many legitimate reasons to load scripts from third-party sources. While I understand the potential risks, I believe they do not warrant the creation of such a heavy burden on us MW script developers.

For understandable reasons, useful third-party JS libraries are repeatly being removed from MW core, often without satisfactory alternatives. For example, just recently the jQuery tipsy library was removed, and the extremely useful jQuery.ui library is likely to face a similar fate. For volunteers like me who do not have enough time to learn the OOUI library in depth, taking away our ability to remotely load trusted & stable JS libraries would be disastraous.

As of 2018, the ability to edit user scripts that affect other users was heavily restricted to a very tiny group of editors, interface administrators. These editors are required to use a strong password for their accounts, as well as enable 2FA. I believe this restriction is tight enough, since interface-admins are usually experienced MW script writers. We should count on them that they do not load external scripts from unfamiliar or untrusted sources.

TL;DR: As a MediaWiki user script developer, I believe that imposing a restriction on the usage of external JS scripts and libraries would be a very big step backwards. I have written numerous user scripts that I do not see myself writing without relying on secure, trusted third-party sources. If the WMF wants to improve the security of users, I really hope a different approach will be taken, one that does not make the work of volunteers harder. Guycn2 (talk) 18:17, 7 June 2023 (UTC)

08 June 2023: Summary of the discussion so far

Hi everyone, and thank you for your continued contributions to this conversation. In addition to the responses already given here, I’d like to acknowledge some of the key points you’ve raised so far, offer a few clarifications, and propose some next steps.

• Concerns were raised about the policy language, some requesting that the policy be written using the conventions of RFC 2119, replacing "should" with "must", etc. Also, there were detailed suggestions about ways to make the policy content more accurate, clear, and understandable, especially around the risks facing users. The feedback on the language and content will inform the next update of the policy draft.
• Confusion was expressed with respect to the scope of the policy, in particular whether the policy means the end of all non-production tools. It’s good to note that the policy scope is deliberately limited to user scripts and gadgets loading non-production resources.
• It was repeatedly flagged that disallowing all external resources in gadgets and user scripts would place a significant burden on the community. Some external resources, in particular, those hosted on WMCS, are important for community autonomy and usually lack alternatives on production websites. As a result, suggestions around exemptions were shared: exempting WMCS resources based on how harmful they are, allowing anonymizing proxies, exemptions on an opt-in basis, user-level or project-level exemptions, etc.

In line with the last point, I am adding a new section labeled Exemptions criteria. The aim there is to identify exemptions that could become part of the policy. Under what conditions could external resources be embedded in gadgets and user scripts? When could the exemption be revoked? How to ensure that exempted resources do not compromise users' security and privacy? Based on this data, are some resources outright not acceptable? Those are initial questions in that direction. Let me know what you thoughts are. Also, please tell me if some points were not captured in the summary or should be moved down here. — Samuel (WMF) (talk) 00:35, 8 June 2023 (UTC)

Exemptions criteria

Here are initial questions for the section discussion: Under what conditions could external resources be embedded in gadgets and user scripts? When could the exemption be revoked? How to ensure that exempted resources do not compromise users' security and privacy? Based on this data, are some resources outright not acceptable? Samuel (WMF) (talk) 00:35, 8 June 2023 (UTC)

I think a rather clear case of what shouldn't be exempt would be any Default Gadget, or Site Script (e.g. skin.js, common.js) - and perhaps instead of carving out exemptions the TPR is just scope limited to those areas? — xaosflux ^Talk 17:17, 8 June 2023 (UTC)

@Xaosflux: Why must external resources be banned from Default Gadgets? Is it because they impact a large number of users? If that is the case, it’s good to note that some non-default gadgets loading external resources are often widely used too. When they load external resources, default and non-default gadgets both expose users and the platform to a wide range of risks. Instead of allowing all external resources in non-default gadgets and UserJS, shouldn't we explore the route of exempting resources that meet criteria X, Y, Z? —Samuel (WMF) (talk) 20:26, 8 June 2023 (UTC)

Default gadgets are opt-out, not opt-in. Taavi (talk!) 20:41, 8 June 2023 (UTC)

While this is mostly true, not always: there may be parts of default gadgets and site scripts that ask for explicit user consent, explaining the privacy consequences; and there may be non-default gadgets that get loaded without explicit user opt-in (e.g. conditional loading through site scripts or withgadget= URL parameter). Therefore, the criterion should be “anything that gets loaded without explicit user opt-in or consent”, not “any default gadget or site script”. —Tacsipacsi (talk) 21:47, 8 June 2023 (UTC)

@Tacsipacsi @Samuel (WMF) - basically I'm calling out anything that can get foisted upon readers without any choice. We know that in reality, registered webui users are a minority of the connections we serve every day - and I think that it would be a good start for TPR controls. By leaving out all the manual opt-in things, and the single-user-only things we should be able to avoid much of the friction with the userbases, while helping to ensure that the privacy of our readers is increased. At that point, we could look in to what may be exceptions to just that scope - and how that could be managed first. — xaosflux ^Talk 21:55, 8 June 2023 (UTC)

Agree with @Xaosflux. Project-wide exemptions should be simply not possible. Each gadget can define its own third part resource which each user must explicitly consent before enabling the gadget (and be able to revoke it at any time via going to a special page like Special:ManageThirdPartyResources or such, someone should also be allowed at add any more they want in that special page). Any attempt to load a third party resource with `withJS=` or `withgadget=` argument must simply fail by CSP not allowing it. The whole point of CSP is to avoid users sensitive data leaking if some JS gets compromised on wiki or PC, allowing arguments such as `withJS=` to bypass that would defy the whole purpose of CSP.

There should be several types of CSP exemptions as well. Loading font, loading scripts, loading media, etc. That is possible via fetch-directives.

Random example: One of my tools for my home wiki is a gadget that when someone tries to create an article, loads the English version and builds some basic info. It's done serverside in tofawiki.wmcloud.org that provides a json (an example). I want users to be able to load the data but if my server gets compromised, I don't it to be able to execute code. I'm not sure if that's possible though. Amir (talk) 00:52, 9 June 2023 (UTC)

oh and to emphasize, Splitting third party resources to "good" so it's loadable under any condition and "bad" would simply be infeasible. The default must always be "wikimedia production only" and let users decide what they want to explicitly allow on top (similar to adding a bot password). This means there is no point in discussing whether toolforge should be considered third party or not, or what about this website, or that website. This is not really the point. Amir (talk) 01:02, 9 June 2023 (UTC)

Hey @Ladsgroup: it is my understanding that you are making the following points:

• All external resources must be disallowed in Gadgets and UserJ by default, irrespective of whether they are WMCS-hosted resources or not.
• The technical measure disallowing those resources would be CSP, though it’s in report-only mode only for now.
• Gadgets and UserJS must only load external resources if they are rewritten to be compatible with some yet-to-be implemented solution that collects user consent and allow exemptions at the user level (eg: CSP opt-out, interstitial, etc, cf phab:T208188).
• Is my understanding correct? — Samuel (WMF) (talk) 16:47, 9 June 2023 (UTC)

Generally yes but I'm not sure about the rewrite part, it can be simply added to gadgets definition, e.g. w:MediaWiki:Gadgets-definition, you define what rights needed for a gadget, what dependencies it has. It's natural to think you need to add the domains you'd need for that gadgets and users will be prompted to accept it if they are enabling it. For user scripts, I guess any person enabling it should go to a special page and add the domain or something like that. It doesn't need to change one line of code, only definitions of gadgets. Of course there are complexities on our side like how to handle domain added to a gadget that is already enabled for many users but none of the challenges are impossible to fix. Amir (talk) 21:07, 9 June 2023 (UTC)

It’s a good idea if it’s feasible using CSP, but there are some details that need to be clarified / I’d like to have improved:

• Gadgets-definition is a good solution for gadgets, but what about user scripts and JS loaded from other (WMF production) wikis?
• What if the gadget is loaded using mw.loader.load('ext.gadget.*')? In this case, the Gadgets extension doesn’t really have control over what happens, only the core ResourceLoader has (unless Gadgets conditionally registers those gadgets, but that would be a step back from a performance perspective after removing the targets system improves performance).
• Having to go to a different page is cumbersome. What if a popup appeared on Special:Preferences#mw-prefsection-gadgets when one tries to enable a such gadget, asking for explicit consent but avoiding navigating to another page? When turning off the last gadget that asks for permission for a given site, another popup could appear, asking the user whether they want to revoke the permission as well. (Remember that no on-wiki styles and scripts load on Special:Gadgets, so users cannot be tricked into anything.)

—Tacsipacsi (talk) 17:56, 10 June 2023 (UTC)

It's a misconception: If the CSP exemption entry is not showing up in the startup module (in which it won't), it won't impact the performance. Amir (talk) 00:06, 12 June 2023 (UTC)

Just noting that phab:T36958 exists to bring gadget-like features to user scripts, allowing them to list the CSP domains in a definition, like for site gadgets. SD0001 (talk) 18:14, 12 June 2023 (UTC)

Google should generally be considered as evil, they make money from raping privacy. They are the very anathema of privacy. Google analytiocs shgould be completely banned from here. Grüße vom Sänger ♫^(Reden) 20:17, 8 June 2023 (UTC)

Nitpick

Please change "utilize" to "use", there's no advantage in using wordier language. Thanks! Frostly (talk) 03:03, 9 June 2023 (UTC)

Hi @Frostly: and thanks for joining the conversation. Well noted. I don't think this is nitpicking if it can improve the clarity of the policy, especially as the text is translated in various languages :). Thank you for your feedback. — Samuel (WMF) (talk) 12:33, 9 June 2023 (UTC)

What are we going to achieve?

I see the general point of the proposed document. However, in my opinion it's going to cause more troubles than benefits.

Asking users to type a list of URLs that they trust to is in my opinion a very bad idea. Why user should trust that particular domain? It's very likely it has only an API or some static main page. Even if the tool's code is open-source, will the user spot any evident pitfall in the code? No, they won't even open the repo. If the gadget or userscript description seems useful, they will turn it on.

Ensuring, that a script or gadget is safe, is the job of the technical people in the community (that is, mainly script authors and interface admins). Out of wiki users, only they do know, what can be considered appropriate for use on wiki. All in all, that was the reason to form interface-admin group in 2018. And this policy should not push the responsibility to unconscious users but rather should provide those technical people with guidelines, what to do if they want to incorporate not-first-party resources and services in their scripts and gadgets.

There are actually three kinds of resources with different properties:

• first-party – these include code and data on WMF wikis and are likely to be secure and contain no threats to the privacy,
• second-party – user-submitted code to WMCS that's under theoretical WMF's control, however are not pre-checked for vulnerabilities and threats,
• third-party – services run completely independently from WMF where there's no control over the resources served and the processing that's done.

Is splitting those between first- and second- party really the best option?

Even without use of second- and third- party services, malicious scripts and gadgets can leak data (for example by saving a session token or user agent to a wiki page). Such cases, when occur on-wiki, may be relatively easily discovered (provided that it's not on Wikidata) and taken down – but, on the other hand, they have much bigger visibility and likelihood of being archived. Privacy threats by other services will likely be less disruptive, however they may be undetected for a longer time.

Gadgets and WMCS tools have much in common. They both are run by community members, using WMF infrastructure, where Foundation staff can perform administrative tasks. The main difference is that they don't have to be open source, meaning that the community may not have control over the actual tool logic and resources it uses. But WMCS offer several advantages that could improve gadgets and their users' experience in a way that wouldn't be possible with only the on-wiki code. For tools that are intended to serve from-wiki API requests, I'd set up a network policy on Kubernetes/VM that would restrict/block outgoing traffic to the third-party services and/or anonymize the incoming traffic (like stripping User-Agent and other sensitive data) – this could make them be marked like "safe for gadgets", which could serve as a recommended way of using WMCS in gadgets. Similar scenario might be possible for third-party resources: a proxy on WMCS that'd ensure there are no sensitive fields in the request.

The general guidelines I'd consider are:

• Make the tool code open source
• If it's a gadget: Make it clear in the gadget description (visible in preferences) that the gadget uses external services and link to an on-wiki rationale why the code isn't solely hosted on wiki
• Provide the same info at the top of the source code in the wiki language with a link to the said rationale
• Provide a basic and up-to-date documentation on what data you process with the tool and a contact in case of a privacy threat (either on-wiki or on the tool's webpage)
• List the tool on some global list (e.g. on metawiki) – for use of people that might inspect these tools
• If restrictions in WMCS in- and outbound traffic are available, enable them or explain why you keep them disabled

Scripts that serve solely their original author (like Special:MyPage/common.js) might be exempt from those criteria because it's hard to protect users from themselves. Msz2001 (talk) 08:52, 12 June 2023 (UTC)

CDN under WMF control

Within Required precautions at footnote level https://cdnjs.toolforge.org/ should be mentioned. This has been established exactly for that purpose.

• ceterum censeo no offered software must connect to external websites.
• If ever, this requires completely open source and explicit opt-in agreement.

PerfektesChaos (talk) 16:18, 12 June 2023 (UTC)

Hi PerfektesChaos and thanks for joining the conversation. I am making a note of your point that by default UserJS and Gadgets must not connect to external an website unless that website's code is open source and the UserJS or Gadget provides "explicit opt-in agreement". However, what you mentioned about the footnote is a bit unclear to me. Are you suggesting that https://cdnjs.toolforge.org/ be mentioned somewhere in the "Consider alternative scripts" sub-section? — Samuel (WMF) (talk) 13:34, 13 June 2023 (UTC)

Yes, I do mean it should be mentioned in the policy. However, it is not really a policy, but an example how it is possible to avoid contacting external domains when executing some tool or gadget business. Therefore it is not mandatory, just mentioned, at footnote level. If all tools and gadgets retrieve such resources from a WMF server privacy is a bit increased. Greetings --PerfektesChaos (talk) 19:35, 13 June 2023 (UTC)

Ah, thanks for the explanation, PerfektesChaos. Since it's a quite precise example of best practices, don't you think it would be best to have it within the page Recommendations for gadget developers? Btw, that page is referenced directly in the policy under the required precautions. — Samuel (WMF) (talk) 20:12, 13 June 2023 (UTC)

The security and privacy benefits of cdnjs.toolforge.org over cdnjs.com are questionable. If we are serious about it, we should host CDNJS in production. Tgr (talk) 00:35, 10 July 2023 (UTC)

If the eventual goal is CSP enforcement - one thing to consider is that cdnjs can be used to bypass certain types of CSP policies. But that may be putting the cart before the horse. Bawolff (talk) 01:05, 10 July 2023 (UTC)

Toolforge

Are toolforge.org and wmcloud.org considered a third party resource for the purposes of this policy proposal? If it is, then this policy proposal may be too broad. We should think very carefully before we try to start forbidding users from loading scripts and resources that are essentially hosted within our ecosystem. –Novem Linguae (talk) 16:57, 12 June 2023 (UTC)

They should be permitted, if all code is open and the presented sources are those in effect.

• If code is hidden I can write a logfile without notice from a broad community.
• I can forward a message to an external site on every request including details. They can record the events out of WMF control.
• By comparison of timestamp and details and public onwiki activities I can connect user account with technical details at CU level, even more verbose.

I can present a clean source at github etc. but the executed code is something different.

If all code of a task is public and under WMF control, community stuff at toolforge, wmcloud etc. is fine.

If hidden things may happen inside a toolforge resource this is as unsafe as a third party implementation and should be refused.

Greetings --PerfektesChaos (talk) 17:32, 12 June 2023 (UTC)

As-written, yes, they would be. This is a problem, as a number of useful scripts load data from Toolforge APIs. AntiCompositeNumber (talk) 02:32, 13 June 2023 (UTC)

Yeap. Breaking a bunch of tools that use toolforge APIs is a huge problem, and makes me disinclined to support this change. –Novem Linguae (talk) 15:28, 13 June 2023 (UTC)

@Novem Linguae: that's a valid concern. As mentioned here, I want to stress that exploring exemptions, including for WMCS-hosted tools, is one of the goals of the current discussion. So I appreciate what you shared, especially about the tool's code being public as a potential requirement for exemption. For WMCS-hosted tools, you raised an interesting point regarding code being public yet different from what is deployed at say xyz.toolforge.org URL. To address that, the idea of keeping a list of tools and their repo on a central meta-wiki page to increase scrutiny was shared earlier. Do you have any opinion about some of this idea and the others shared by Msz2001 under this section — Samuel (WMF) (talk) 19:57, 13 June 2023 (UTC)

I agree with the concern on toolforge, as there are many gadgets and user scripts that calls server side running on toolforge. Samuel (WMF), it sounds to me like having a list of tools and their repo on central mediawiki could be a valid general solution, though not sufficient for dev of new tool. E.g. suppose developer implement new gadget with backend on toolforge and frontend as user script? I guess it would require also user level resolution (developers or testers being able to override the general list with their personal list). eranroz (talk) 07:15, 8 July 2023 (UTC)

The consultation period is just about over but I did want to put at least my two cents in: I find the categorization of Toolforge and Cloud Services as "third-party" to be faulty, considering a lot of the tools that editors rely on on both platforms are volunteer-run and any developer wishing to access either already go through a screening process and use of those platforms are already governed by recently-introduced strict privacy requirements. What's written in #What this policy will change for users right now gives me a bit of confidence, but when enforcement eventually rolls around (i.e., CSP is enabled), I don't see how tools listed on Third-party resources policy/Noticeboard would not be blocked, unless we had a really long CSP header with the Origins of all tools in that noticeboard. I'd prefer to see at least some clarification on this end before committing to anything. Perhaps enabling CSP reporting without blocking for Toolforge/Cloud Services would be a viable alternative to outright blocking these sources entirely. Chlod (say hi!) 14:12, 17 July 2023 (UTC)

Hi @Chlod, I'd like to acknowledge your concerns about classifying Toolforge and Cloud Services as "third-parties", especially in light of the recently added privacy requirements in WMCS terms of use. Also, it's my understanding that you recommend that there is clarity around how exempted WMCS tools would not be blocked before starting to enforce the policy. I'm making a note of your concern and proposal, and will include them in the consolidated list of feedback for this consultation. — Samuel (WMF) (talk) 18:39, 17 July 2023 (UTC)

Ratification process

What will the ratification process for this proposed policy be? Is there some manager at WMF that makes the final decision, will there be a community vote, etc? –Novem Linguae (talk) 16:58, 12 June 2023 (UTC)

@Novem Linguae: the Foundation's Security team leadership is the one making the final decision on the policy, under guidance from Legal. Based on the feedback gathered here, the policy will be updated iteratively throughout the consultation time widow. After July 17 and the end of the consultation phase, the updated policy will be shared with the Foundation's Legal team to ensure compliance with other Foundation policies, and its final version released in due time. Thanks — Samuel (WMF) (talk) 19:31, 14 June 2023 (UTC)

Any evidence of a problem so far?

Have there been any specific privacy incidents that led to the creation of this proposal, such as a malicious tool that was discovered to be harvesting user data? In other words, is it trying to fix an actual, demonstrable problem? –Novem Linguae (talk) 05:52, 13 June 2023 (UTC)

@Novem Linguae Security/privacy should be premptive and not reactive imo. We probably shouldn't wait for something (anything) to happen. As it stands, we have no CSP which means that a compromised interface administrator or a malicious script developer can/could deanonymize anyone with a few targetted lines of JS/CSS (which unfortunately is fairly easy to write). The third-party scripts policy (and the associated CSP changes which I assume will be implemented) should help in making it harder for such a event to ever happen (at all).

Note: I do not agree with the changes in their entirety especially the exclusion of toolforge/wmcloud domains and localhost etc, but opposing/questioning the validity of this on the grounds that "nothing has happened yet" is a somewhat circular and dangerous argument. Sohom (talk) 15:08, 13 June 2023 (UTC)

The whole user script system seems like it would be a security nightmare on the surface, but the number of actual incidents (counter-intuitively) seems very small (I've never heard of anything). These things are tradeoffs: usefulness of tools vs risk of problems. Since I love tools and they make me so much more efficient, I'd really like to see demonstrable problems before we go proactively interfering with them. –Novem Linguae (talk) 15:34, 13 June 2023 (UTC)

@Novem Linguae there have been some instances, last I recall was with a compromised admin account before int-admin split and required 2FA for int-admins. — xaosflux ^Talk 15:16, 13 June 2023 (UTC)

Thanks for that background. I wonder if there were any incidents involving third party tools breaking our privacy policy, such as a toolforge tool getting caught with code to log IPs. While admin account compromises are serious, I speculate this policy would not be able to fix those. –Novem Linguae (talk) 15:26, 13 June 2023 (UTC)

@Novem Linguae I'm not sure about malicious ones, but external sites simply have different policies; for example on the English Wikipedia there is a gadget that sends information to Google Translate. It is not a default gadget, and it labeled as (this gadget uses) code from external (third party) systems not subject to the WMF Privacy Policy on the opt-in section. With external links, even if they had a good privacy policy when added - they could change their policies or practices whenever they wanted to. — xaosflux ^Talk 16:03, 13 June 2023 (UTC)

@Novem Linguae: thanks for joining the discussion. Yes, on multiple occasions, UserJS and Gadgets loading external resources have resulted in security incidents (accounts of privileged users being compromised) and privacy issues (UserJS and gadgets sharing user information with external parties). While security incidents such as the one mentioned here are not detailed publicly for obvious reasons, you can get an idea of the external parties collecting user information through UserJS and Gadgets here. Also, I'll second what Xaosflux mentioned earlier, especially about the importance of preventing security and privacy risks, rather than trying to address them once they have already caused damage. More broadly, while it can seem far-fetched, it's good to keep in mind that privacy violations often mean real-life consequences for some individuals — harassment, identity theft, physical harm. So yes, the policy is trying to address an existing problem. While I agree with you that the policy alone may not fix that problem completely, by formalizing how TPR must be used in UserJS and Gadgets and promoting best-practices, we will end up in a much safer place than where we're right now — Samuel (WMF) (talk) 19:28, 13 June 2023 (UTC)

@Samuel (WMF) while we have some different ideas where to start on scope, I think that Site scripts should absolutely be in scope for TPR. — xaosflux ^Talk 19:31, 13 June 2023 (UTC)

Hey Xaosflux, I am sure you can tell that one of the challenges with this policy is avoiding scope creep. I mean, just look at the range of complexities that comes with regulating just UserJS and Gadgets relationship with TPR . More seriously, TPR use in the Wikimedia ecosystem is a wide domain so it's crucial to tackle some specific areas rather than going for a one-size-fits-all approach. So, I hear your point but I am curious to know your rationale for expanding the scope to include Site Scripts. Are there particular reasons to that particular expansion? Thanks — Samuel (WMF) (talk) 23:02, 13 June 2023 (UTC)

@Samuel (WMF) so to be clear, the intent is to have this apply to every personal user script, to every gadget, but it can just be ignored project-wide via Mediawiki:Common.js, Mediawiki:Vector.js or the like?? That seems like a much more important place to enforce something like this as it is force loaded to every user. — xaosflux ^Talk 23:20, 13 June 2023 (UTC)

@Samuel (WMF): (in case this reply got lost in the pile), just checking - does WMF think that arbitrary TPR's are fine if applied to everyone (including readers) via sitescripts? This seems completely backwards to the overall goal of improving privacy controls for users. — xaosflux ^Talk 13:58, 15 June 2023 (UTC)

Hello @Xaosflux, that isn't fine either as it's also an attack vector. I hear your point and have added it to the others that the Security team is reviewing while preparing the next policy update. — Samuel (WMF) (talk) 15:34, 15 June 2023 (UTC)

@Samuel (WMF) thank you, if this is going to be some sort of phase in (to do something instead of nothing while discussions continue) my support would be for these sitescripts and defaultgadgets first. Anything in those two sections can impact unsuspecting readers. — xaosflux ^Talk 15:36, 15 June 2023 (UTC)

@Xaosflux, that's dully noted. Thanks — Samuel (WMF) (talk) 22:11, 15 June 2023 (UTC)

There is a hot war in Europe, a Wikipedia editor was put in jail for Wikipedia editing, people may be sentenced to death in some countries when their opinion is not shared by government.

Not only commercial data collectors, but some countries with direct connection of telecommunication providers and the police are active. If they know the IP address used for an edit a few minutes later they can tell you your bank account and the location of your flat.

We should not wait until people in Wiki environment are looking into gun muzzles to start improving security of our tools.

Apparently close to river Moskva some hundred excellent technicians are developing tools for various purposes.

Greetings --PerfektesChaos (talk) 19:54, 13 June 2023 (UTC)

Bassel Khartabil was executed in relation to his activities for freedom of expression, including Wikipedia activity; a temporary fellowship was created after his execution, but WMF and the other related foundations funding the fellowship seem to have dropped it once the issue dropped out of the headlines. See w:list of people imprisoned for editing Wikipedia for others who have been arrested in relation to their Wikipedia activities and got sufficient publicity in WP:RS. There are very likely many who have been arrested or worse for Wikipedia editing but the info didn't get into WP:RS (or it did and no Wikipedians had the time to create articles). Osama Khalid and Ziyad al-Sofani's imprisonment is not even notable enough for individual Wikipedia articles. Boud (talk) 12:03, 23 July 2023 (UTC)

WMFs own privacy

I would actually argue that WMF itself also needs to do better privacy wise. The fact is, WMF developed features, like Citoid and (when it gets released) IPInfo both contact external websites. A lot of websites nowadays have notices on what external websites are used on their site, and WMF fails in that front. The reason websites did that is because privacy in Europe is actually harsher than in the USA, so ever since GDPR was accepted in the EU, these privacy notices that other websites than WMF have is outright required nowadays. Privacy and security policy wise are largely mutually exclusive, although they affect each other, so it is completely irrelevant in terms of Privacy whether WMF thinks the external websites they are using are safe or not. Snævar (talk) 13:35, 14 June 2023 (UTC)

I agree 100% about it being irrelevant from a privacy perspective whether or not we think they are "safe". Its about consent not safety. However, i think the line should be personal information transfer (including implicitly when making requests client side). Server side requests that do not transfer personal information should not be considered a privacy issue. IANAL but i don't think it would be considered one under GDPR. I believe all of Citoids external services are contacted server side without PII. Additionally, as far as i know (I have not followed the development closely), IPInfo does not contact external websites whatsoever. Bawolff (talk) 01:07, 22 June 2023 (UTC)

Touching external websites

One section above Citoid and IPInfo have been mentioned as a privacy risk. I do not think they make things worse, but improve the situation. Obviously it is necessary to discuss dangerous methods at specific examples.

Let us imagine a link to an article from the Daily Planet print archive or some online news platform is inserted into a Wikipedia article by a registered user.

1. Classic approach:
   • Look for a source at the newspaper website.
   • Visit their articles with the browser of the user and the IP address and other fingerprint details.
   • Insert the URL of the citation into the Wikipedia article.
   • The sysop at the newspaper website has no idea which of millions of clicks are connected to a Wiki account.
   • However, they could observe how often they are quoted within some large Wikipedias and record all occurrences every 24 hours. By comparison of two days it is easy to detect to which article a certain URL has been added, and blame who made this edit at which time.
   • Knowing that a certain URL has been added to Wikipedia at some hour and minute the sysop could check the logfile and see who accessed that URL ten minutes before. IP address and browser details may have been recorded. Most probably this is belonging to a WMF account. At least if repeated on other pages with other URL the privacy is broken.
2. Using Citoid
   • If insertation with details is made via Citoid, the website is visited by a WMF server. They tell “I am a Wikimedia agent, I have no screen size” and the IP address is in public register owned by WMF and these data is always identical for all Wiki user accounts.
   • This is a perfect proxy protecting privacy of WMF users.
   • One gap is there anyway: The user has been searching for information, and might have visited the source half an hour before, or yesterday, collecting material. These visits left traces.
   • However, Citoid is not making the situation worse. It might improve since the visit connected to the time of edit is disguised.

When IP address analyis services are touched they are visited by a Wikimedia agent at Wikimedia IP address rather than users theirselves with private IP address.

Tools and gadgets are much closer to the Wiki community than a news platform with global audience.

• A tool executing tasks related to certain wiki pages could connect their request log with editing of such pages.
• If a wmfcloud tool offers spelling check of articles or formal improvement every isolated call for this page is probably connected to an edit performed a few minutes later by a registered user.

JavaScript of any codebase, user JS or site JS or indirectly launched by such code has highest risk.

• They know the page name and number of every read page, and the user nickname. Encoding which wiki, current page number and nick into some d2af52b61c code as path of a beacon will enable an external site to record all read pages by which user at which IP address.
• Transclusion of JavaScript code from sources out of public WMF history control is a no-go.

-- PerfektesChaos (talk) 18:33, 14 June 2023 (UTC)

22 June 2023: Policy update notice

Hi all, and thanks for the fruitful conversation! The Security team has reviewed the feedback gathered on this talk page and updated the proposed TPR policy (comparison of the versions). Below are the main changes and a few clarifications regarding some aspects that were not included in that update.

Main points that were included:

• Clarified security and privacy risks with illustrations such as account compromise and real-life consequences of privacy violations.
• Followed RFC 2119 language conventions by replacing “should” with “must”; replacing "end-users" with "users"
• Clarified that TPRs loaded in UserJS and gadgets have contributed to account compromises and privacy issues rather than being the sole factor.
• Included a section on enforcement, acknowledging the existing manual removal of non-compliant UserJS and Gadgets and mentioning CSP as a future technical enforcement.
• Included a section on exemptions with an emphasis on opt-in and some requirements to promote best practices, including the idea of a public Noticeboard to facilitate scrutiny of external resources embedded in UserJS and Gadgets.

Points that were NOT included in the update:

• Making global scripts part of the policy scope: the proposal is being examined by the Security team. Meanwhile, we'd like to collect additional thoughts on this proposal in the Global scripts section.
• WMCS-specific exemptions: while only opt-in exemption is mentioned in the updated policy, this form of exemption is expected to allow WMCS-hosted resources to be used as well, provided that they meet opt-in exemption requirements. Furthermore, ideas that were shared specifically for WMCS-resources (eg: transparency of code, etc.) were incorporated as additional requirements for opt-in exemption.

Kindly let me know what your thoughts are! — Samuel (WMF) (talk) 01:53, 22 June 2023 (UTC)

Production websites

It's still a crap proposal. I'll just paste what I put here before, because you didn't address that: One of the many flaws of this proposal is that it lists Complete list of Wikimedia projects as production websites. Based on that definition https://fontcdn.toolforge.org/ and https://maps.wikimedia.org/ fall in the third-party category, but it's no problem to include content from http://www.wikimedia.org.ph/ and https://translatewiki.net/wiki/. Multichill (talk) 21:28, 7 June 2023 (UTC) Multichill (talk) 21:19, 25 June 2023 (UTC)

Yeah, it's not a suitable list. The page includes lists.wikimedia.org but not upload.wikimedia.org, so that would mean we could load email attachments but not access on-wiki files. - Nikki (talk) 16:22, 3 July 2023 (UTC)

@Nikki and @Multichill, I agree that Complete list of Wikimedia projects includes some websites that may not fall within the traditional definition of production websites such as Wikimedia. Although lists such as https://noc.wikimedia.org/conf/highlight.php?file=dblists/all.dblist exist, I am not aware of any canonical list of Wikimedia production websites. This is why the Complete list of Wikimedia projects was used instead. In the recent update, a footnote was added next to the link to delineate the scope a bit better but It is my understanding that it is still unclear. Is there any list or delimitation criteria that you think would be more accurate? — Samuel (WMF) (talk) 14:18, 6 July 2023 (UTC)

fontcdn.toolforge.org probably should fall in the third-party category. But yeah the link isn't really helpful. What is typically meant by "Wikimedia production websites" is sites administered by the Wikimedia Foundation, ie. sites which can be accessed according to the production access policy. Tgr (talk) 00:42, 10 July 2023 (UTC)

And most importantly, websites operated by people who aren't WMF, are definitely not production. Bawolff (talk) 00:44, 10 July 2023 (UTC)

Anyways, in the interest of trying to be constructive, I would suggest instead of saying production, maybe say operated by the Wikimedia Foundation and covered by the main privacy policy. Since I don't think you really care about it being "production", what really matters is it is in the same privacy-domain and information is not being transferred to places with weaker protections. Bawolff (talk) 00:51, 10 July 2023 (UTC)

@Bawolff @Tgr, I think websites "operated by the Wikimedia Foundation and covered by the main privacy policy" or a shorter variation of that sounds great and easier to translate than "production websites". As far as pointing users to a list, putting myself in the shoes of readers of the policy, I think it might be helpful to picture what falls within the category of WMF-operated websites, as much as possible. What link might make sense the most? — Samuel (WMF) (talk) 13:50, 11 July 2023 (UTC)

Non-Wikimedia resources in UserJS

I think the policy, as currently written, is a huge mistake. It would prevent lots of useful tools and resources while offering no alternative. I don't see why I should be prevented from loading non-Wikimedia resources in my user JS if I want to. I'm not asking anyone else to use the code. I can run my code from a browser extension instead where people can't see it, if you really insist, but making people resort to browser extensions to do things doesn't seem like a security improvement. I find it strange that you allow people to host things on Toolforge if you don't trust them. - Nikki (talk) 16:19, 3 July 2023 (UTC)

@Nikki: I don't think offering no alternative is what is being considered in the policy. In fact, a number of ideas shared in this talk page and the policy are around exemptions; they seek to enable gadgets and UserJS while ensuring best practices — transparency and opt-in requirements. Although I understand the point that you should be able to include whatever you want in your JS, I don't think it is a terrible thing to require that you follow best security and practices, especially if other people may transclude your script. Also, I'd like to acknowledge what you're mentioning about UserJS intended for personal use only, which is something raised by PerfektesChaos as well. My question is, how do we know that a UserJS which was initially designed for personal use only won't be transcluded and used by many other users? — Samuel (WMF) (talk) 16:10, 6 July 2023 (UTC)

I see two levels here.

Policy wise, I think the point itself raised by Nikki and PerfektesChaos can be solved by considering that there is an implicit user opt-in for javascript that you develop yourself. It would be silly and annoying to require an Oauth-like process to ensure you are aware of what your own code does.

This usually maps with UserJS, although not always. There are (or at least used to be) full javascript modules out there, intended for end-user installation, that should require some kind of user opt-in if they were to use third-party resources. Automatically finding such scripts or the exact mechanism through which to declare such opt-in not needing to be defined on the policy.

Platonides (talk) 22:27, 7 July 2023 (UTC)

As @Nikki pointed out, this is the worst case scenario: blocking third party, but not developing first party projects. It would be interesting to have this discussion if the WMF was, indeed, developing alternatives for the community, but the total failure of the Wishlist has proven that this is not the case. Now, you are proposing to make ourselves even more obsolete. Of course, this is not the worst move ever, but it's on the list of bad takes. Theklan (talk) 19:57, 9 July 2023 (UTC)

The overwhelming majority of user JS is code blindly copied and pasted by users with no ability to understand the code and little or no awareness of what security and privacy risks are involved in blindly copying blocks of JS. It doesn't make any sense to have weaker requirements for user JS than for gadgets. (Also they are a usability nightmare and should be killed in favor of user-level gadgets but that's not relevant for the policy discussion.)

Also, a CSP-based enforcement mechanism would be unable to differentiate between user scripts and sitewide scripts. Tgr (talk) 00:48, 10 July 2023 (UTC)

Policy-wise, I should be allowed to use scripts that I developed myself (shoot myself in the foot if you wish). Blindly copied JS code by users with no knowledge are not included there.

There are several technical ways to implement that, that could be explored later. Personally, I would favor the per-user preference of hosts allowed by this user (mentioned in another section), as it would be a very clean way for users to punch a hole into their CSP.

Platonides (talk) 00:48, 12 July 2023 (UTC)

On a philosophical level, there is no reason to prevent you from running your own code, sure. On a practical level, since it's trivial for you to use the generic opt-in mechanism (having to click through some OAuth-like diagram once per script is not by any reasonable measure annoying), it doesn't make sense to add code complexity just to try to avoid that.

The policy should probably just say "making third-party requests requires informed consent, and the WMF will provide a mechanism for obtaining that". You always have informed consent for using your own script, without having to do anything. (But in practice I'd expect you'll still have to click through some warning because it's easier to implement to consent mechanism that way.) Tgr (talk) 01:41, 12 July 2023 (UTC)

Opt-in exemptions

For the time being, opt-in exemption combined with transparency requirements strikes us as a viable way to promote best practices among gadgets and UserJS developers while reducing security and privacy risks on projects. The specific implementation of that opt-in exemption was purposely left unaddressed in the policy. What do you think about this choice? Do you have specific questions or recommendations? — Samuel (WMF) (talk) 01:53, 22 June 2023 (UTC)

Perhaps an opt-in user account preference like we've seen on mobile devices, something like; Allow third-party scripts to be loaded? That can include a warning (same or similar to MediaWiki:userjsdangerous). Allowing this to be set locally or via global preference could also be useful for end users. As to dealing with non-registered-users: perhaps going as far as just not letting them use these at all. (This could be useful if there won't be a blanket ban on such scripts in sitescripts or default gadgets). — xaosflux ^Talk 18:47, 22 June 2023 (UTC)

I don’t think that a general permission made in July 2023 is sufficient to permit any software in eternity to be loaded.

Best this is made on current gadgets pool with one in particular you need right now.

The permission is not meanigful nor a valid local or even more global account preference to permit on every Wiki every script to connect to anybody.

Greetings --PerfektesChaos (talk) 19:26, 22 June 2023 (UTC)

Well I certainly would not want to see anything require re-opting in every time a revision was made either. — xaosflux ^Talk 20:41, 22 June 2023 (UTC)

While it may make sense to make the consent unconstrained in the time dimension (perpetual), it definitely should not be unconstrained in the resources dimension: instead of a blanket “allow third-party resources” consent, the user should be given the opportunity to consent to use of one third party (e.g. Toolforge) but not the other (e.g. Google). The most logical for me is consenting per-domain (which means per-tool on Toolforge). —Tacsipacsi (talk) 21:31, 26 June 2023 (UTC)

“Toolforge” is a mixture of some 500 public available tools of 300 maintainers.

Nobody can make a meaningful consent that all tools on Toolforge including all tools introduced in future are declared as trustable for this user. A user consent or general preference for a domain “Toolforge” is pointless.

It would be to ask: Allow helpfulUtility@toolforge to load third-party scripts? and for user account preferences on preferences page a list of all tools is to be maintained, and linked to tool doc page which explains in detail which external resources are loaded and why this is inevitable and what are possible problems.

Regards --PerfektesChaos (talk) 18:00, 27 June 2023 (UTC)

(which means per-tool on Toolforge) – I don’t understand why you argue that [n]obody can make a meaningful consent that all tools on Toolforge […] are declared as trustable; nobody stated that one needs to do so. —Tacsipacsi (talk) 22:26, 27 June 2023 (UTC)

It is the suggestion of this section: Make a user preference that all tools of a certain domain, like toolforge.org, are permitted to load every external resource from now on for unlimited period.

“the user should be given the opportunity to consent to use of one third party (e.g. Toolforge)”

Toolforge is hosting several hundreds of tools, even some not available when the permission is given, and maintained by hundred people of all intentions.

There is no meaningful consent possible to such variety of codes and tools. Toolforge is not a domain with responsible administration and maintenance for every line of code at any time.

--PerfektesChaos (talk) 20:21, 4 July 2023 (UTC)

I think the preference of user exceptions should be a per origin list. You could allow to load from https://*.toolserver.org or just https://tool1.toolserver.org The good part is that this would map cleanly to CSP entries (served only to this user). Platonides (talk) 22:40, 7 July 2023 (UTC)

In principle it sounds good, but I don't understand the details of how the exemption would work in practice. A human reviewer manually tries the tool and checks the existence and adequacy of consent, and adds the tool into an allow list? Or is it something else that doesn't involve a central and human review process (other than individual users toggling a checkbox or tapping a "Yes, I'm happy" button)? whym (talk) 12:20, 6 July 2023 (UTC)

Hi, the section of the policy on opt-in exemption is purposely left technology-agnostic. This choice is to support and provide room for solutions that are currently being explored in different avenues such as here: T208188. That being said, it is my understanding that the opt-in exemption solutions currently explored (user preference, Special page, etc) do not involve a human reviewer who'll manually examine the consent. Contrariwise, those opt-in suggestions seem to agree on an automated flow in which (1) users are informed that the gadgets or script they'll use will connect to external resources, (2) users choose to allow that situation or not (Oauth-like authorization, checkbox ticking, domain allowlist, etc.), (3) TPRs are loaded or blocked, depending on users' decision. Let me know if that summary makes things a bit clearer — Samuel (WMF) (talk) 11:19, 11 July 2023 (UTC)

Just pushing this up. Amir aka Ladsgroup had good idea idea how opt in could be implemented in Exemptions_criteria. --Zache (talk) 05:56, 9 July 2023 (UTC)

Site-wide scripts

Because global scripts site-wide scripts are loaded for all users on a project, they represent an area for potential abuse at large-scale by embedding a third-party resource. As part of the current discussion, it was proposed that those scripts be also included in the scope of the TPR policy. What do you think about this proposal? — Samuel (WMF) (talk) 01:53, 22 June 2023 (UTC)

I think the name "global script" is misleading (as these are project-local sitescripts) not global in the scope that is normally discussed here on the meta-wiki; however I 100% think all of those sitewide *.js and *.css scriprts should be in scope, as well as any gadget that is enabled by default. I think there is also a good argument that this class of scripts is the only thing this policy should apply to. — xaosflux ^Talk 18:41, 22 June 2023 (UTC)

@Xaosflux: would the name "site-wide scripts" sound more accurate? On another note, I understand the argument of narrowing down the policy’s scope to site-wide UserJS, stylesheet scripts, and default gadgets. However, it is important to recognize that non-default gadgets and UserJS loading TPR are also significant sources of security and privacy concerns. That's why they were included within the scope. Of course, the policy's scope could potentially cover other areas within Wikimedia systems but the Security team has opted for a layered approach. We're purposely focusing primarily on some specific areas where we have observed recurring real-world instances of security and privacy issues: UserJS and gadgets, including non-default ones. — Samuel (WMF) (talk) 12:26, 28 June 2023 (UTC)

site-wide scripts is better than global scripts. When users think of "global scripts" they are almost always referring to pages such as Special:MyPage/global.js (already covered by "user scripts" above). — xaosflux ^Talk 13:46, 28 June 2023 (UTC)

@Xaosflux: thanks! I've adjusted the section header accordingly and it's introduction. — Samuel (WMF) (talk) 16:14, 6 July 2023 (UTC)

I think that common.js/vector.js/user-group.js etc should be included in TPR policy as they are working similar manner than gadgets. However, there should be some community managed system to whitelist TPR domains inside wiki. (like mediawiki:third-party-loading-allowed-domains vrt c:MediaWiki:Copyupload-allowed-domains or something). This same whitelist could be used for gadgets which are enabled for all users such as (c:Help:FastCCI and c:MediaWiki:Gadget-fastcci.js) in Commons for deep category intersections which enabled for all users and uses fastcci*.wmflabs.org as backend) --Zache (talk) 04:56, 9 July 2023 (UTC)

If there was an on-wiki whitelist, it would mostly defeat the purpose of this policy: if an interface admin wants to load third-party resources without user consent, they simply have to edit the whitelist, put the domain there, and all protection is lost. (It’s a bit more visible than simply changing a random gadget code page, but on a wiki with not many interface admins, it’s still likely to go unnoticed.) If anything, the whitelist should be in PHP configuration, changed by requesting wiki configuration changes. But even better, there should simply not be a such whitelist, so that users are really in control what gets loaded. —Tacsipacsi (talk) 16:29, 9 July 2023 (UTC)

My point is that community should have be able to develop tools which are enabled for all users and which are using data from external sites. Most likely the loading the javascript directly from third-party sites should be disabled for security reasons using CSP, but loading data (such as filelists, values from API:s) or images (such as map tiles) should be possible. If we think that direct http-requests will leak information then lets add proxy which will mask IP and user agent, cookie etc information so user cannot be profiled with them. (sure, there is still possible to craft http-requests so it will pass information, but here will be always ways to leak private information if there is possibility to write executable code and it is tradeoff between usability and security) -- Zache (talk) 10:05, 10 July 2023 (UTC)

That would be a pretty clear-cut violation of the privacy policy, which essentially says that the WMF doesn't share personal information of the users with others without explicit consent.

Using a proxy (hosted in Wikimedia production) doesn't fall under the scope of this policy, since no non-production resource is being accessed. (I guess that depends somewhat on the exact wording and interpretation. Maybe the policy should say that gadgets are not allowed to make requests to non-production sites, that's better defined.) Tgr (talk) 00:52, 11 July 2023 (UTC)

It should anyway implemented before policy goes live. For example it should be possible for to create separate toolforge like instance which doesn't relay information (client IP, user-agent, referer, limit header information) to user webservices. -- Zache (talk) 07:08, 15 July 2023 (UTC)

Best practices for global scripts could include also that traffic needs to be routed through WMF production managed proxy which would mask users's IP address, browser, referer etc. If I understood correctly toolforge does this already for tools hosted there. --Zache (talk) 05:33, 9 July 2023 (UTC) edit: language fix --13:37, 15 July 2023 (UTC)

FWIW we should kill sitewide scripts in favor of default-on gadgets. Multiple different ways of loading scripts for everyone is a maintenance burden, monitoring burden, and usability problem. The policy should be agnostic of how scripting is implemented, though. Tgr (talk) 23:14, 9 July 2023 (UTC)

Scope: Private use and public offer

In scope section or somewhere else a distinction might be necessary:

• Tools which are offered to the public by any means, even more if executed without active consent.
  Those must fully comply to TPR.
• Some lines of code for private use only, in .js user page. No documentation, no advertising, no transclusion anywhere else.
  It might be impossible to track all such personal helpers.

PerfektesChaos (talk) 07:15, 22 June 2023 (UTC)

Hi @PerfektesChaos, I just want to acknowledge your point and mention that I've brought it up in the Non-Wikimedia resources in UserJS section. — Samuel (WMF) (talk) 10:55, 14 July 2023 (UTC)

Compliance Label

Once the rules are settled and the inital version is finalized and approved, a globally harmonized template should be created to label documentation pages of tools.

A statement should be made

• for this particular tool or for all tools within a certain range
• to be compliant, in certain levels, like
  • fully (nothing external, no other but fully compliant ingredients) external=-
  • cookies are used e.g. to remember user language or other preferences
  • loading or connecting external sources under current user identity (not as proxy like Citoid) which are explicitly specified
  • other standardized exemptions
  • individual addendum
• TPR version (year, month) 2024-11
• Naturally with myLanguage link to policy page.
• User nick (link) and date, perhaps not visible in minimized view.

The statement should be made in language independent codes as parameters like babel user language templates and might be displayed multilingual or in site language.

• The template name should be globally unique; fully self explaining and therefore not colliding.
• Presentation can be either:
  • large box in page width
  • small box in babel style
• Fancy icon for those who can see icons.
• Decoration and stylish improvements and implementation might be local.
• Background or border colour might indicate level; green, grey, yellow, red.

Maintainers can start to label their documentation pages explicitly in common maintenance process.
-- PerfektesChaos (talk) 08:07, 22 June 2023 (UTC)

Hi @PerfektesChaos, I think those are interesting ideas that the community could consider to improve transparency. On the other hand, I believe that such a documentation initiative also needs to be lightweight enough to avoid creating a burden, otherwise it could discourage community adoption. — Samuel (WMF) (talk) 11:07, 14 July 2023 (UTC)

It think software developers should be able to transclude a template on a wiki page {{PrivacyComplianceStatement |external=- |cookies=- |TPR=2024-11 |babel=0 |signature=PerfektesChaos 2024-11-01}} and to grab the resulting HTML code for non-wiki pages.

|cookies= might be used with a few keywords - preferences history

|external= could provide some standard features - CSS JavaScript or #switch: to individual text.

Best --PerfektesChaos (talk) 09:52, 18 July 2023 (UTC)

Affect on TorBlock extension

I found this code today. mw:ExtensionTorBlock, which is deployed to production, pulls a list of w:Tor (network) IPs from an external website. Would the proposed policy change break this extension, since this external call would possibly violate the new policy? –Novem Linguae (talk) 10:32, 26 June 2023 (UTC)

That code is written in PHP and runs server-side. Server-side usage of third-party resources is out of scope of this proposal and will continue to work. (Since it’s the server that connects to the third party, not the user’s browser, it poses a much smaller risk both privacy- and security-wise.) —Tacsipacsi (talk) 21:34, 26 June 2023 (UTC)

@Novem Linguae, I'll echo what Tacsipacsi noted above and confirm that the TorBlock Mediawiki extension is out of the scope of this policy as the current proposal is limited to UserJS and gadgets. — Samuel (WMF) (talk) 12:33, 28 June 2023 (UTC)

Scope of the policy

The following software must obey the policy:

• MediaWiki components included in current WMF distribution
• Site ressources which are automatically loaded or offered to the community and user ressources advertised or documented to be useful for others than the owner. All further components which may be loaded from the ressource are to be compliant as well.
• WMF Cloud tools which are advertised or documented to be useful.

The following software types are vulnerable:

• Client JavaScript with most capabilities.
• Server side programming like PHP, Python or whatever which can collect locally and contact external sites.
• HTML documents which can transclude beacons and resources. Usually tool answers are in HTML.
• Client CSS which might contain @import non-cacheable external CSS or URL of images.

The rules do not apply to:

• User ressources which are not advertised and made for personal use only.
• Tools not offered to the public, most bots.
• PHP extensions not part of WMF wikis.

Tools shall avoid to load external resources.

• If inevitable they shall make this obvious on their documentation page.
• If external access from client environment is used such software must not be run automatically, but by active request and notification about security aspects. If it is used anyway that is by consent.

PerfektesChaos (talk) 18:23, 27 June 2023 (UTC)

Notifying the developers of affected user scripts and gadgets

Did or will the proposer(s) notify the developers of affected user scripts and gadgets of this proposal, and encourage them to give feedback?

Directly notifying (emailing) all users with access to edit CSS/JS seems like a good idea, if not done already. Not all of them would be responsible for tools using third-party resources, but I would err on the side of notifying too many than too few. I believe significantly many don't subscribe to Wikimedia-l and Tech News. whym (talk) 00:07, 30 June 2023 (UTC)

Hi @Whym and thanks for joining the conversation. Wikimedia-l, the Tech News, Phabricator, and IRC where the main avenues for reaching out to gadgets and UserJS developers. By "emailing all users with access to edit CSS/JS", are you suggesting to target interface admins or virtually all users who can create a sub-user page with .css/.js extensions? — Samuel (WMF) (talk) 18:12, 30 June 2023 (UTC)

It's the former - local interface admins and global interface admins, and maybe stewards, who routinely edit JS on wiki. As much as I suggest to err on the side of notifying too many, I admit targeting all users might be a bit too noisy (on the recipient side). I hope there is another way to find people developing personal scripts that call third party resources for their own, though. whym (talk) 03:11, 1 July 2023 (UTC)

With the exception of tech news, these are pretty weird methods of outreach. IRC and phabricator are wholly inappropriate as community "outreach" method. Emailing wikimedia-l is fine as a secondary method, but super weird by itself especially without wikitech-ambassadors and wikitech-l. The lack of an executive summary of the proposal in the email is also not great - people do not click on links that are super vauge with no indication of how it affects them. Hell, the latest version has a bizarre requirement hidden behind misleading language requiring stuff on cloud use world readable file modes - yet i dont see any attempt to inform the wm cloud community of this new requirement. Anyways, I think mass-message to VP like pages would be more standard for a far reaching policy proposal like this. Mass message to iadmins would be a bit more aggressive but not totally unheard of. Bawolff (talk) 02:52, 2 July 2023 (UTC)

@Whym and Bawolff: thanks for your inputs. I've readied a list of interface admins for MassMessage and I'll draft the message a bit later today drafted the message body. I'll try to get some help to ship it later today. I am also planning to add another section to the Tech News and send emails to wikitech-l@ + cloud-announce@. I think wikitech-ambassadors@ is covered by Tech News but let me know if a separate email to wikitech-ambassadors@ is necessary. re: "world readable file modes", this requirement is to make it possible for other wmcloud maintainers to perform code scanning, which AFAIK would not be possible if the files have a stricter permission, say chmod 600. This is part of the ideas that were proposed in this discussion to improve transparency and scrutiny. Is it that you disagree with the requirement or that you would suggest a different phrasing instead? — Samuel (WMF) (talk) 11:06, 7 July 2023 (UTC)

re "world readable file modes" - its confusing, because the phrase "human readable" has a specific meaning different from world-readable and most people would assume that posting non-obfuscated source code to github would meet that requirement. It is also unclear how this requirement applies to tools where the deployed code is compiled or minimized and the source artifacts are not deployed to the server. It doesn't really make sense as a requirement for all of cloud services since in cloud VPS it is not going to matter what mode the file is. In toolforge one could presumably give privileges to the scanner to ignore modes if so desired (albeit some people might disagree that that is a good idea). Its unclear how this will interact with a glorious kubernetes toolforge future. Its unclear why this is relevant to a policy on privacy implications of third party resources. It is unclear what type of scanner is going to be used, and what is going to happen if the scanner finds something. I mostly mention this because static analysis tools are notorious for having large numbers of false positives, especially when used broadly against code bases not tuned to them. Bawolff (talk) 00:36, 10 July 2023 (UTC)

I'd just like to chime in and second Bawolff's comment that the communication which went out on e.g. wikitech-ambassadors list was not very clear. Had I not been aware from other sources that this might affect toolforge/cloud VPS then there would be nothing in that e-mail (or indeed the current phasing of the policy) which would lead me to believe that is the case. An executive summary and a handful of clear examples of what tools/scripts (the current state) of the policy would allow/disallow would help to actually engage people who can see that the tools/scripts they are responsible for maintaining would be affected. As is, even after having read this document and tried to get through the discussion page I'm still not sure what the effect would be on a) me as a code maintainer, b) current users of my tools/scripts, c) the potential of making those tools/scripts useable to a wider audience (i.e. all logged in or even logged out users), d) which changes will be done to the current way we support tools/scripts to be able to maintain a climate where volunteers and non-WMF employees are encouraged to build tools/scripts but in a safer environment than today. /André Costa (WMSE) (talk) 07:52, 10 July 2023 (UTC)

@André Costa (WMSE): I am sorry that it's still not clear how the policy will affect users. I'm creating a separate section with illustrations of the expected changes for users with the hope that it helps clarify things a bit more. — Samuel (WMF) (talk) 13:46, 14 July 2023 (UTC)

@Samuel (WMF) Thanks. I think that will be useful. / André Costa (WMSE) (talk) 13:09, 17 July 2023 (UTC)

WMCS terms compliance

The text «If the third-party resource is hosted on Wikimedia Cloud Services code, its code should comply with WMCS terms of use» should be changed to «If the third-party resource is hosted on Wikimedia Cloud Services code, its code must comply with WMCS terms of use». That's somewhat superfluous, but i think it's nevertheless appropriate to link from the TPR policy, since those developing user scripts may otherwise not be aware of the requisites WMCS tools are expected to be complying with. Platonides (talk) 22:33, 7 July 2023 (UTC)

@Platonides, I think that sounds totally reasonable, not superfluous :). I've taken good note of this change request. — Samuel (WMF) (talk) 11:24, 11 July 2023 (UTC)

Exemptions section needs work

Thanks for reaching out to interface admins across the wikis - this should have been done sooner. I can see the motivation for this policy and am broadly supportive of the principle. However, I am concerned about a few aspects of the policy:

• Personal user script pages (e.g. w:User:This, that and the other/vector.js). On the face of it, it seems unnecessary to include these scripts in this policy. The code in these script pages are loaded for the user concerned only, so one could argue that we should allow users to "shoot themselves in the foot" and add whatever they want to their personal script pages. There would be quite considerable resistance from some community members if this autonomy were curtailed. At the same time, this has to be balanced against risks:
  • Social engineering attacks, e.g. a well-known, trusted user's account - not necessarily a privileged account - on a certain wiki is compromised (either the account itself is taken over by a bad actor, or the account's legitimate owner is coerced IRL by bad actors), and convinces other users to add malicious code to their personal user script pages that loads malicious third-party resources.
  • On smaller wikis with few users watching for vandalism and/or low technical skills in the community, wiki pages containing instructions for installing legitimate power-user type scripts ("start using the QuickEdit tool by adding the following code to Special:MyPage/common.js!") could be subtly edited so that following the instructions causes users to load malicious third-party resources.
• At very minimum, I'd like to see some evidence in the policy itself that these competing goals - user autonomy and freedom to manage one's own personal script environment vs. the risk of attacks via personal user script pages - has been balanced.
• The exemptions section of the policy is very underdeveloped. What is the exemption mechanism? What does it look like? On Wiktionary we have a gadget, wikt:WT:QQ, which contacts the Google Books API to identify sources for words. This gadget, although it loads third-party resources, is 100% opt-in, and should continue to exist provided users give their informed consent for loading third-party resources. However, it does not look like a mechanism for this has been developed. Moreover, Google Books is closed source and it would not be possible to comply with the "additional transparency requirements". But the QQ gadget should clearly continue to exist, as it poses absolutely no risk to users who knowingly consent that Google may get some info about them. Of course, QQ should never be allowed as an opt-out (default) gadget.
• What is meant by "loading"? On Wiktionary there is a globally-loaded script that offers alternative search engines on wikt:Special:Search, including Google and Bing. This does not "load" third-party resources until the user clicks one of the alternative search engine options and clicks "Search", in which case, the user is redirected to the search engine they chose. It would be great if the policy could clarify that simply redirecting somebody to a third-party resource in a context where it is obvious that this will happen (e.g. they clicked an external link marked "(links to an external site)", or they selected a button labelled "Google" next to a search field) is not contrary to this policy.

This, that and the other (talk) 02:05, 8 July 2023 (UTC)

Given the propensity if users to blindly copy code they don't understand, I don't think it's a good idea to exempt personal script pages (and it doesn't seem technically feasible anyway). Since there's an opt-out mechanism, it wouldn't have much benefit anyway, just save users a very trivial amount of time.

+1 about the transparency requirements. It doesn't make sense to ban the use of closed-source APIs (logging of private information doesn't necessarily happen within the source code anyway). Tgr (talk) 01:02, 10 July 2023 (UTC)

@This, that and the other, thanks for your thoughtful comment. I think there are a few things to unpack here.

• re: Loading definition. My understanding of wikt:Special:Search is that it simply creates a redirection to an external resource, rather than loading or fetching that external resource. While I'm open to clarifying that redirection to external links doesn't count as "loading", I worry that we may need to expand the clarification to include other cases. For now, I am making a note of the recommendation and will continue to give it some thought.
• re: Personal user script pages. You're suggesting that the policy must include some evidence that the need for user autonomy and the risk of attacks via personal user script pages are balanced. To my understanding, the policy already covers the risks associated with both gadgets and UserJS loading TPRs. As for user autonomy, the exemption part aims at providing users with some alternate ways to use TPRs while being abiding by best practices. Do you have some specific recommendations for balancing those competing goals a bit clearer in the policy?
• re: Exemption. As mentioned in another comment, the section of the policy on opt-in exemption is purposely left technology-agnostic. However, the opt-in mechanisms explored in this talk seem to have in common a way to (1) inform users of gadgets or script that their device will connect to external resources, (2) enable users to allow that situation or not (Oauth-like authorization, checkbox ticking, domain allowlist, etc.), and (3) a way to connect to the TPR or not, depending on users' decision. As for the transparency requirements, this change follows some of the recommendations made here to increase community scrutiny. I can see how these requirements may not be applicable to close-source TPR. Do you have any suggestions for enabling community scrutiny of those closed-sources as well? pinging @Tgr as well on this one —

Samuel (WMF) (talk) 13:22, 11 July 2023 (UTC)

@Samuel (WMF) as I wrote below IMO this policy suffers from trying to provide one-size-fits-all solutions for very different threats. What is the threat the community scrutiny of resource provider application's source code is supposed to avert, and how does it avert it? I don't see how such a recommendation would help, or why it would be necessary. Tgr (talk) 17:10, 11 July 2023 (UTC)

@Samuel (WMF) thanks for the response.

• Re UserJS: The term "UserJS" is a little confusing to me. In my head, there are two separate types of user script pages. There are the "personal" or "skin" user script pages (User:xyz/vector.js, User:xyz/common.js, etc) which are executed whenever a user views a page in that skin (or all skins in the case of common.js). Then there are other user script pages which are not automatically executed but which may be loaded or imported by users (User:xyz/MyCleverScript.js, etc) - these were widely used before Gadgets existed, and may still be used in certain contexts. The risks involved are slightly different: convincing a user to paste content on User:xyz/BlaBlaBla.js is only an immediate risk if other users are loading or importing this script, compared to the uniformly present risk of convincing a user to paste content on User:xyz/common.js. However, perhaps the difference is academic for the purposes of these policy.
• Re exemptions: I'll defer to Tgr, Bawolff and others who are highly experienced in these matters.

This, that and the other (talk) 00:40, 12 July 2023 (UTC)

Restrictions should be proportional with risk

I don't think the policy as it stands now makes much sense TBH. There are three very different kinds of risks related to third-party resources:

• Using third-party executable resources (such as Javascript or non-sandboxed iframe) essentially means that full control is handed over to the third party. They might perform actions under the name of the user, track the user's behavior in detail etc.
• Passing information about the user's behavior to the third party. E.g. to use the WikiWho API, you need to tell the API what page the user is reading.
• Any third-party resource request involves the user making a HTTP connection to the third party, which shares some information such as IP address. This is usually not risky at all, but still requires user content. More concerningly, the exact timing of third-party resource requests can allow (for the third-party resources' owner or for someone monitoring the network) to associate a Wikimedia user account with an IP address (e.g. if a resource is only used for editing, you can compare the timestamps of a user's edits with resource request timestamps from various IP addresses).

It doesn't make much sense to me to treat these equally in the policy.

• Using executable third-party resources should just be blanket forbidden. It comes with major risks such as account takeover, and there is no convincing use case for it.
• Passing information beyond those typically revealed by any HTTP request to the third party (e.g. passing the username, or the article title) should be clearly indicated in the tool's description, and probably the third-party resource should have a friendly privacy policy (ie. it should not store the information for a significant amount of time). We might want to apply this to tools revealing information via timing as well, although that's a much fuzzier area (and one where "official" Wikimedia software sets a low bar).
• Other third-party resource uses, which are not very different, in terms of information revealed, from the user visiting some random website, should require informed consent but shouldn't be a big deal beyond that. We probably still want to minimize them so the policy should say something along the lines of not using third-party resources where that can be avoided with reasonable effort (e.g. one can just host the resources locally).

Tgr (talk) 22:59, 9 July 2023 (UTC)

+1 Bawolff (talk) 00:22, 10 July 2023 (UTC)

This differentiation would also be useful because it would allow us to introduce a CSP block of external JS right now, without having to wait for an opt-in mechanism to be built. From a security POV, loading CSS or JSON or whatever from a third-party site is much, much less concerning than loading JS. Tgr (talk) 00:56, 10 July 2023 (UTC)

just to say aloud that non-sandboxed iframe cannot perform actions under the name of the user or do account takeover because same-origin policy restrictions. -- Zache (talk) 08:59, 10 July 2023 (UTC)

@Tgr Thanks for the detailed input. FWIW, the policy’s intent is not a one-size-fits-all solution to the TPR challenges. In fact, the policy is designed with a specific scope and adopts a layered approach. With that said, It’s my understanding that your concern is that the policy tackles some issues together. Accordingly, you are proposing the following different treatments:

• All executable resources must be banned due to the risk level involved, although this means users of those scripts loading TPRs will not have any alternatives.
• For gadgets and userscripts passing user behavior information (other than IP, UA and device information information) to a TPR, the extra information should be clearly indicated in the tool’s description (I assume that by “tool” you mean WMCS-hosted tool).
• More generally, and I assume this covers resources outside WMCS, the policy should just require user consent and encourage people to recommend that people do not use third-party resources where that can be avoided with reasonable effort.

Is my understanding correct? Samuel (WMF) (talk) 13:01, 12 July 2023 (UTC)

Yes; I think banning remotely loaded JS should be an important security goal, and I don't think this will break important use cases. People will have to upload their scripts locally, which might be a small annoyance for them but a meaningful security improvement (and probably better for performance, too).

Wrt the second bullet item, I think if the gadget sends personal information to an external service (other than what browsers send whether you want or not), it should be noted in the gadget's description (or consent form, once we have that) along with a link to the privacy policy of the service. Tgr (talk) 21:41, 12 July 2023 (UTC)

@Tgr One legit use case what it could break is that if user crafts gadget which would use external libraries (say leaflet or Huggingface libs for example) which would be impossible to copy without changes to wiki page so it would be still working. For normal user point of view the to os much easier to load it from CDN. Zache (talk) 14:08, 15 July 2023 (UTC)

Such libraries should either be hosted in Wikimedia production (we can just set up cdnjs as an extension for example), or we should allow JS files to opt out from minification (there is some discussion at T75714). We shouldn't leave an XSS vulnerability open just because it seems borderline useful for something. Tgr (talk) 07:23, 16 July 2023 (UTC)

Purpose

The purpose section is confusing. It doesn't mention security risk (which I assume is a stronger motivation than privacy), and it talks about the ToS section on doxxing which isn't very relevant. The more meaningful reference would be the privacy policy, which doesn't allow sharing user data without consent. And probably worth mentioning threat from governments etc. Tgr (talk) 23:10, 9 July 2023 (UTC)

@Tgr While the term security and privacy risks aren't specifically mentioned in the purpose, one of the first sentences of that section includes "This has sometimes contributed to account compromises and privacy issues". IMHO, this gives an overview of the risks there. Also, since there is a dedicated section on risks it'll mostly likely be redundant to go into details about the range of security and privacy risks at stake here (eg: state actor threats). FWIW, the ToS section reference isn't specific to doxxing but violating other user's privacy more generally. However, I am making a good note of your suggestion to reference the Privacy policy part about user consent. — Samuel (WMF) (talk) 13:35, 12 July 2023 (UTC)

I wouldn't describe directing the user's browser to make a request to google.com as "violating their privacy"; that language is really about publishing private information. It does break the privacy policy though (which in turn might break the law, e.g. CalOPPA in California). So IMO that's the more helpful legal reference. Tgr (talk) 21:34, 12 July 2023 (UTC)

Enforcement

The enforcement section doesn't really read as part of a policy document. The implementation doesn't need to be included in the policy; what a policy should say is 1) who does the enforcement (are e.g. interface admins required to do it? or encouraged but not required? or not their business at all? where to send reports?), 2) whether we are creating new rights or norms (e.g. global interface admins are allowed to interfere if a project is in violation of the policy). Tgr (talk) 01:06, 10 July 2023 (UTC)

@Tgr: I hear your point. For context, the enforcement section is included to (a) formalize an existing practice of manual removal and (b) clarify that CSP might be a technical enforcement. The last part was proposed as part of this conversation. Regarding your suggestion to focus on who does the enforcement, where to report violations, and whether new rights will be created, I think the policy already covers those aspects, at least partially. No new rights are expected to be created at this time, reporting avenues are included in the manual removal sections. Furthermore, the sentence “If you hold sufficient permissions and come across a gadget[...]” is indirectly encouraging interface-admins to enforce the policy. Do you think interface-admins should be called out specifically is the policy? More generally, if those specifics about enforcement must not be included in the policy document, where do you suggest we put them? Samuel (WMF) (talk) 13:20, 12 July 2023 (UTC)

I think that sentence is fine, I just meant that I would keep that and remove the rest of section to keep the text shorter. YMMV.

I do think it's worth thinking about whether we want to empower stewards / global interface admins to intervene on the basis of this policy. Local interface admins are already empowered to intervene if they see a script as problematic, but global functionaries typically only act when there is no local functionary.

(I don't know what the answer should be; might be worth asking some stewards about it.) Tgr (talk) 21:48, 12 July 2023 (UTC)

Safety risk

"For a number of vulnerable users, this often means real-life consequences including harassment, identity theft, imprisonment, and physical harm." feels a bit over the top. (I'd bet this has happened exactly zero times.) "For vulnerable users, this could mean real-life consequences including harassment, identity theft, imprisonment, and physical harm." is more accurate while still getting the point accross. Tgr (talk) 01:13, 10 July 2023 (UTC)

I don't know if it has happened in the context of wikimedia sites (by it i mean abused a third party resource in order to do someone harm. I know of course people have been harassed in connection to their activities on Wikimedia sites). However we live in a world where targeted attacks against individuals via the websites they use do happen. There have been high profile attacks involving other websites, many involving much more effort & complexity than the types of attacks that we are talking about here. I don't think the risk we are discussing here is implausible. However i do agree with your proposed edit, in that "could" is better than "often". Bawolff (talk) 01:40, 10 July 2023 (UTC)

@Tgr and @Bawolff. Just acknowledging that I've made a good note of the proposed change. Thanks — Samuel (WMF) (talk) 15:10, 12 July 2023 (UTC)

Gadget minification

One aspect I've seen occasionally that stands out to me: gadget minification. Some gadgets developed by interface admins are minified and the creators keep the full version in an external location (eg Github). Is it still considered "transparent"? Should this be allowed? Let's say the creator deletes the source code from the external location, what implications follow from this? ━ ALBERTOLEONCIO Who, me? 12:47, 10 July 2023 (UTC)

FWIW, gadgets, unlike user scripts, are minified by the server before being loaded anyway, so regardless of appropriateness in relation to this proposal, having minified scripts in the MediaWiki namespace is a counterproductive practice. Nardog (talk) 13:52, 10 July 2023 (UTC)

A project should develop its own readability projects for something like this. If the only maintainer for a script leaves, turning if off is usually a good idea as well. — xaosflux ^Talk 14:40, 10 July 2023 (UTC)

Hi @Albertoleoncio, the general idea around transparency requirements is to encourage best practices and make community scrutiny a bit easier when that's possible. However, the TPR policy doesn't say anything specifically about code minification or obfuscation of gadgets. For specific cases such as gadget minification, I agree with @Xaosflux that it would be more scalable to allow local communities to adopt specific, stricter transparency requirements than those mentioned in the TPR policy, if they deem it necessary. Samuel (WMF) (talk) 11:43, 14 July 2023 (UTC)

Policy:Universal Code of Conduct & Wikipedistics 2013-2023

Hello Colleagues, Recently we have encountered some misunderstandings regarding the role of technical developments/departments and legitimacy in introducing new features, as was the case with the Global AbuseFilter.

For those who have joined this project in the last 5 years: please. reads the fights[2] we've seen in the past when Sue Gardener left and Lila Tretikov managed for some time until she got kicked out.

If you have any doubts about how to act pls. keep in mind https://foundation.wikimedia.org/wiki/Policy:Universal_Code_of_Conduct

• Abuse of office by functionaries, officials and staff:
  • use of authority, knowledge, or resources at the disposal of designated functionaries, as well as officials and staff of the Wikimedia Foundation or Wikimedia affiliates, to intimidate or threaten others.
• Abuse of seniority and connections:
  • Using one's position and reputation to intimidate others. We expect people with significant experience and connections in the movement to behave with special care because hostile comments from them may carry an unintended backlash. People with community authority have a particular privilege to be viewed as reliable and should not abuse this to attack others who disagree with them.

Just to make it short:

• Yes, you can develop a bunch of functions here.
• No, you cannot implement these features without the legitimacy of communities, especially those that already have their own solutions.

Best --Ｔｏｍ (talk) 07:51, 11 July 2023 (UTC)

If you think someone is behaving inapropriately make a specific allegation. This message doesn't seem particularly applicable to me. Bawolff (talk) 13:23, 11 July 2023 (UTC)

We are discussing parts of policy here. Don't talk about your possibly strange (pres. inexisting) concern. Especially User:Samuel (WMF) who invited for this discussion should keep in mind the struggles we have had as written obove. Hence my reference to the need to legitimize the distribution of new functions and the decision-making autonomy of the different communities of Wikipedia. --Ｔｏｍ (talk) 13:31, 12 July 2023 (UTC)

Hi @Ｔｏｍ, and thanks for joining the conversation. UCoC and self-governance of Wikipedia communities are outside the scope of TPR policy consultation. For UCoC specifically, I don't see how this policy discussion would qualify as Abuse of power, privilege, or influence. On the other hand, I you have specific suggestions to improve the content of the proposed policy, you are warmly encourage to share your thoughts either in the existing sections or in a new one. — Samuel (WMF) (talk) 15:04, 12 July 2023 (UTC)

Allways keep in mind: no never put bricks on a wall between the Comunities and WMF

Dear Samuel (WMF), you don't need to defend anything or anyone here. I didn't accuse anyone of anything bad.

We are talking about policy & regulations here, or how they should look in the future and be applied.

Also for TPR policy consultations no one can foresee everything and certainly not one can foresee which consequences can develop for which individuals and communities.

When technicians develop things, it is of course important how and that it can function technically. But not everything that is technically feasible means progress or profit for Wikipedia.

I believe that's what Mark Zuckerberg had in mind when he quoted old ideas of Larry Page: en:Don't be evil.

Hence, please also observe the TPR directive and please record it accordingly in the wording:

• Yes, you can develop a bunch of ideas, functions, and even policys here.
• No, you cannot implement these features everywhere without the legitimacy of communities, especially those that already have their own solutions.

Best --Ｔｏｍ (talk) 07:21, 13 July 2023 (UTC)

What this policy will change for users

I am adding this table here to summarize the expected changes for various categories of users. The summary below illustrates what is currently proposed by the policy as well as some of the ideas that are still in discussion on this talk page. Feel to let me know if I should clarify some items of the table. — Samuel (WMF) (talk) 13:46, 14 July 2023 (UTC)

User category	How will the policy impact me?
Logged-out user, developer of Mediawiki extensions that load non-Wikimedia resource, maintainer of a WMCS-hosted tools that are NOT embbedded in any gadgets or userscripts	I am not covered or impacted by this policy
User of gadgets that load non-Wikimedia resources	I will not be able to use gadgets that load non-Wikimedia resources unless I consent.
Author and user of userscripts that load non-Wikimedia resources	Until an opt-in mechanism is in place, I am only encouraged to avoid embbedding non-Wikimedia resources in userscript. Once the opt-in mechanism is in place, my personal scripts as well as user scripts from other users that embbed TPR will not work, unless I consent to using them.
Developer of gadgets that embbed non-Wikimedia resources	I am encouraged to avoid embbedding non-Wikimedia resources in my gadgets. Until an opt-in mechanism is in place, I must adjust my gadget code to require consent from user. Once the opt-in mechanism is in place, I must adjust my gadget code to be compatible with it, if applicable.
Maintainer of a WMCS-hosted tool that is embbedded in gadgets or userscripts	If my tool is embedded in gadgets or userscripts, I need to (a) document my tool on the Noticeboard and (b) adjust the files permission of my code hosted in WMCS so that it is inspectable by other WMCS maintainers, except for credentials or similar config files.
Interface administrator	I am encouraged to enforce the policy by blanking the gadgets or userscript page and notify its author. If I am unsure, I can report the issue to an Administrator, a Steward or send an email to the Foundation’s Security team (security-team[at]wikimedia.org).
Administrator and other local users with advanced rights	In accordance with local community policies, I can encourage the best practices mentioned in this policy by proposing local guidelines or policies to adapt the main TPR policy. I am also encouraged to report local violations of TPR policy to interface admins, stewards or the Foundation’s Security team.

So wait, is this table implying that scripts/gadgets used by logged out users can load third party resources without consent to their heart's content? Bawolff (talk) 16:05, 14 July 2023 (UTC)

Hi @Bawolff. This is definitely not the intended implication. Unless I am wrong, logged-out folks do not use or create userscripts. So I did not expect them to end up loading TPRs through UserJS, hence the exclusion. As for "logged out users load[ing] third party resources without consent", I assume you are referring to logged out folks using default gadgets that may load TPRs, in which case you have a point. Would it make more sense to update the illustration table by grouping logged-out users with logged-in folks? — Samuel (WMF) (talk) 23:31, 15 July 2023 (UTC)

Logged out users might get this either through default enabled Gadgets (I know this is the case for some map features, using Toolforge or WMCS backend, on some wikis), I can also imagine there still being some wikis out there having tools included through their Common.js (unless that has by now been fully phased out in favour of Gadgets).

I would include these in the second line by rephrasing it "User of gadgets that load non-Wikimedia resources (incl. default enabled ones)". That also makes it clear that it can affect the majority of users, rather than a tech-savy minority. / André Costa (WMSE) (talk) 13:23, 17 July 2023 (UTC)

Do we really need to rewrite gadgets twice, first use some home-made consent mechanism and then again, this time to be compatible with the opt-in mechanism? As a MUST requirement? Please don’t make extra work for gadget maintainers, don’t enforce the policy (i.e. use only MAY and SHOULD requirements) until the final opt-in mechanism is in place. —Tacsipacsi (talk) 22:20, 14 July 2023 (UTC)

Hey @Tacsipacsi I am making a good note of your recommendation regarding enforcement timeline and will make sure to take that highlight that as I am consolidating the pending feedback before the consultation closure. Meanwhile, I have question: as it is not clear how long it'll take for an opt-in mechanism to be in place, don't you think MAY and SHOULD requirements will results in gadgets maintainers simply discarding those requirements in the meantime? — Samuel (WMF) (talk) 23:32, 15 July 2023 (UTC)

Of course, many, probably most, gadget maintainers will ignore the requirements in the meantime, that’s the whole point of being permissive. Frankly, as a gadget maintainer, I don’t want to do double work just because core developers work slowly. If you don’t expect paid WMF employees to do the necessary development within a reasonable timeframe, why do you expect volunteer gadget developers to work not only quickly, but also twice? —Tacsipacsi (talk) 23:45, 16 July 2023 (UTC)

Thank you for your response, @Tacsipacsi. I believe that's a valid point. For the sake of keeping the illustration table faithful to what is currently in the proposed policy text, I will not change the table content. As mentioned earlier, your feedback has been duly noted. — Samuel (WMF) (talk) 17:57, 17 July 2023 (UTC)

Just as a question: How do you think that tools like c:Help:FastCCI should be implemented? Ie. it is enabled for all users, it is integrated to UI, and it uses custom API to access to Wikimedia databases data in a way which is not possible using mediawiki API for performance reasons. -- Zache (talk) 07:01, 15 July 2023 (UTC)

Hello @Zache, Are you wondering how gadgets that are loaded by default for logged-in users and logged-out users should adjust, or is your question totally about something else? If it is the former, I think that a UI that allows all users (logged-in and logged-out) to know that they load TPRs and allows them to consent is a good thing. While it is my personal opinion that this kind of UI could be a good implementation, It's worth noting that the policy should not go into details about how homemade consent flow must look like for all gadgets. IMHO, including that level of specifics in the policy would probably prevent it from being scalable. — Samuel (WMF) (talk) 23:34, 15 July 2023 (UTC)

Not to get offtopic, but its probably no longer true that FastCCI is impossible without using WMF apis. In theory it would probably be implementable with a combination of mw:Wikidata_Query_Service/Categories & the search incategory: keyword. Of course, this is just one specific example so your question probably still stands. Bawolff (talk) 02:59, 16 July 2023 (UTC)

With regards to the Noticeboard. Would it not make more sense to have this be part of https://toolsadmin.wikimedia.org/ where tools (at least Toolforge ones) are already meant to be documented, rather than setting up yet another place for documentation to be placed. It doesn't have to be toolsadmin but I would definitely argue against fragmenting the tool documentation landscape even further. For the sake of the discussion here maybe not specify where but just say "I need to (a) document my tool in a pre-described location [...]". That clarifies that you cannot do it just in your code but leaves the exact where up for discussion, and avoids the use of Noticeboard (capital N) which may make some people think en.wp noticeboards. / André Costa (WMSE) (talk) 13:32, 17 July 2023 (UTC)

Ditto on the above. We already have Wikitech, toolsadmin, Toolhub, doc.wikimedia.org (which lists a few tools, like WWT), Meta-Wiki, MediaWiki, and a bunch of other places... No need to add another spot to check. Chlod (say hi!) 14:20, 17 July 2023 (UTC)

Hi @André Costa (WMSE), @Chlod and thanks for raising the issue of fragmenting the tool documentation environnement. I think re-using an existing place for documentation rather that creating a new one makes sense. For the sake of keeping the illustration table faithful to what is currently in the proposed policy text, I will not change the table content. However, I am making a note here that this comment will be included in the consolidated feedback of this consultation. — Samuel (WMF) (talk) 18:16, 17 July 2023 (UTC)

I would also add that i think "embedded" is an ambiguous term in context. I would suggest it either be defined, or a less ambiguous term be used. Bawolff (talk) 07:59, 18 July 2023 (UTC)

18 July 2023: Third-party resources policy consultation closed

Greetings, everyone!

As of July 17, 2023, the feedback period for the proposed policy regarding Third-party resources has officially come to a close. On behalf of the Foundation's Security team, I would like to express my gratitude to all those who took the time to contribute their thoughts, inquiries, or even those who simply skimmed through the page out of curiosity.

We are genuinely delighted with the remarkable quality and diverse range of comments we received. They have offered valuable insights into various issues, suggested changes, and overall enhanced the initial policy proposal. Even if certain feedback could not be directly incorporated into the updated policy text, we carefully examined your comments and gained a valuable understanding of the sentiment within the community. If you were unable to comment during this phase but still wish to share your opinion, you can reach out to us at security-team[at]wikimedia.org.

Now, the Security team will dedicate sufficient time to thoroughly review all the input received and determine the most appropriate course of action for the policy draft, based on the findings from this consultation. We anticipate sharing our decision on this Meta talk page by late-October.

Once again, thank you to all those who contributed their questions and comments! — Samuel (WMF) (talk) 00:03, 18 July 2023 (UTC)

@Samuel (WMF): given how this whole process went, I'm worried about what this "decision" is going to be. This proposal lacks community consensus and support. The right course of action would be to put this up for a community vote. Multichill (talk) 21:44, 23 July 2023 (UTC)

30 October 2023: About next steps

Hi all,

As announced back in July, the Security team has spent the past few weeks revisiting in detail all the feedback generously shared during the consultation and we have explored a few paths to move forward. First and foremost, I would like to clarify that the policy is still in a proposal state and will not go into force for now.

While the majority of comments agreed on a number of aspects such as documenting the use of third-party resources in a more transparent way, requiring user consent, other points gathered radically opposed views. For instance, there was a lack of consensus regarding external javascripts. While some argued that javascript resources loaded from non-wikimedia servers should be banned without any exception, others opposed that idea on the grounds that users should have the ability to opt-in and load those resources anyway. Additionally, a large array of opinions stressed the need for an automated opt-in mechanism, allowing users to be informed and able to decide whether to allow third-party resources or not. Nevertheless, a high-level implementation of that opt-in solution did not gather consensus either.

In light of the above, the security team will continue to refine the TPR policy proposal through a series of actions:

• The best practices collected during the consultation — and which were incorporated within the draft iteratively, will help expand some existing work on the general guidelines regarding gadgets. As guidelines are voluntary and not enforced, the best practices from the TPR policy could improve those gadget recommendations in areas such as security, privacy, and code transparency. This decision aims at encouraging better standards in a voluntary way, while the policy draft continues to develop.
• Further discussions with community members will be initiated to explore more deeply how to reduce the risks related to executable third-party Javascript, through CSP automatic block for example, while providing users with concrete alternatives, when applicable. Since on-wiki consultations are resource-intensive, we will proceed in a phased way, and start with targeted conversations, involving subsets of interface administrators, stewards, and WMCS users. Once specific proposals have emerged from the discussions with the focus groups, the Security team will open those proposals to a wider public discussion. The goal here is to keep refining the TPR policy while minimizing consultation fatigue.
• In parallel with the community conversations around executable external resources and their workarounds, the Security team will explore the idea of an opt-in mechanism, with guidance from Legal to ensure regulatory compliance. The output from the conversations with the subsets of community groups should help evaluate the feasibility and requirements of that technical solution in terms of UX Research, actual development, maintenance, etc.

If you have further questions or would like to partake in our discussions with the subsets of community groups, you can reach out to us at security-team[at]wikimedia.org.

Once again, I would like to thank you for your participation in this process! — Samuel (WMF) (talk) 14:26, 30 October 2023 (UTC)