[04:30:04] I'm User:Nikki on-wiki, I don't know who the other one is (re @jeremy_b: I've also not been following especially closely, would help if Nikki or Nikki had examples. what's the difference between the 2 ...) [05:13:05] edited :) (re @Nikki: I'm User:Nikki on-wiki, I don't know who the other one is) [05:22:35] yes, related to that, and yes, it included wikis loading scripts from toolforge, see https://phabricator.wikimedia.org/T304208 for example (re @waldyrious: Not sure if there were two similar initiatives, but what I recall is that there was an effort to get Toolforge-hosted tools (and...) [05:23:45] that's "by default". which is a lot different than something the user turns on. (re @Nikki: yes, related to that, and yes, it included wikis loading scripts from toolforge, see https://phabricator.wikimedia.org/T304208 f...) [05:28:06] anyway thanks that does look like a decent example to think about. maybe taavi or @bd808 has a comment about it? is there a policy change? (re @Nikki: yes, related to that, and yes, it included wikis loading scripts from toolforge, see https://phabricator.wikimedia.org/T304208 f...) [05:43:51] there's also things like https://phabricator.wikimedia.org/T275754 which is about non-default gadgets, and people arguing that we should block third party scripts entirely (I've lost the tab I was thinking of, but https://phabricator.wikimedia.org/T296847#7806786 is another example) [05:47:31] (where "third party" apparently means other than the production servers, not just anything outside wikimedia) [07:47:35] Reading that discussion, it seems like the issue in this case is not one of privacy or third-party hosting of resources, but rather using site-wide scripts that are hosted on wmflabs "with the apparently mistaken assumption that wmflabs is a production server". (re @Nikki: yes, related to that, and yes, it included wikis loading scripts from toolforge, see [07:47:35] https://phabricator.wik [07:47:36] imedia.org/T304208 f...) [07:50:15] I suppose the solution, short of making Toolforge stable enough to comply with the requirements of a production server, might be along the lines of the git-importing mechanism that Daniel mentioned above 🤔 [08:17:40] While trying to edit the Wikidata item about the Wikimedia Hackathon, encountered a bug: T393672 [09:48:22] but *why* are they concerned about code being loaded from a non-production server? because that makes requests to so-called "third party" servers which is a privacy issue (re @waldyrious: Reading that discussion, it seems like the issue in this case is not one of privacy or third-party hosting of resources, but rat...) [09:48:49] it's not really about the stability of the code, nobody is objecting to hosting the same code on-wiki [09:55:50] That's not how I read the conversation. It seemed to be about the stability of the server itself (its ability to reliably serve the code), not of the code (i.e. logic) per se [09:55:56] there was also https://meta.wikimedia.org/wiki/Third-party_resources_policy where it's clearly about privacy [09:57:38] It still seems to me that there are two issues here: one about loading code from third-party (i.e. non-Wikimedia) servers, which is a privacy issue; and another about loading code from Toolforge, which is a reliability issue. At least that's how I understand it, but again, take my words with a grain of salt :) [10:02:13] could you point to where exactly you think someone is saying it's about the reliability of toolforge? maybe I'm missing something, but I only see people talking about privacy and security :/ [10:14:24] Sure — here: https://phabricator.wikimedia.org/T304208#7790783 [10:14:24] Quoting that exchange, for convenience: [10:14:25] @Mahir256 (https://phabricator.wikimedia.org/p/Mahir256/): [10:14:27] As this is not the first task involving the use of @Pathoschild (https://phabricator.wikimedia.org/p/Pathoschild/)'s script (https://meta.wikimedia.org/wiki/TemplateScript), [10:14:28] you may wish to complain to that user that people find those scripts useful enough to consider them a default staple for others. [10:14:30] @Aklapper (https://phabricator.wikimedia.org/p/Aklapper/): [10:14:31] That makes no sense at all. [10:14:33] @Mahir256 (https://phabricator.wikimedia.org/p/Mahir256/): [10:14:34] Let me rephrase, then: please tell that user "Would you mind re-hosting all of your scripts on Meta, rather than on wmflabs, and adjust your documentation to follow suit, given that people find those scripts so extremely useful that they enable them for everyone, even with the apparently mistaken assumption that wmflabs is a production server?" (re @Nikki: could [10:14:34] you point to wher [10:14:36] e exactly you think someone is saying it's about the reliability of toolforge? maybe I'm missing somethin...) [10:19:20] Maybe I'm latching onto the "production server" wording and what he actually meant was something like "WMF server", but even then I fail to understand why the WMCS servers would not be considered WMF-provided 🤔 [10:22:44] Even loading script from toolforge is a privacy issue. Its not Google, sure, but a tool can collect information from every user without disclosure and without a source coded opened, differently that a script hosted on a wikipage. (re @waldyrious: It still seems to me that there are two issues here: one about loading code from third-party (i.e. non-Wikimedia) [10:22:44] servers, which...) [10:24:42] WMCS isn't held to same privacy and security standards that WMF Production is [10:24:50] or the same SLAs [10:25:16] taavi: that feels like a thing you'd be good at explaining [10:27:21] I feel that we need a visual aid, kind of a diagram-like of "rings of privacy/security/reliability/..." [10:42:57] RhinosF1: we (WMCS) don't set out the policy on what can and can't be done on the wikis, you need to talk to the people who do. as far as we're concerned, using WMCS resources on Wikimedia wikis is related to Wikimedia projects and thus allowed from our side [10:58:59] thanks taavi [10:59:11] i guess that's sec team or privacy engineering then [11:04:46] and depending how it's enabled by default I would say also traffic/performance. (re @wmtelegram_bot: i guess that's sec team or privacy engineering then) [11:05:04] possibly yes [11:06:54] also some code may have a middle ground. if it is enabled by default but only used when user clicks it then maybe there's no performance impact for the people that don't click to fetch it. [11:28:15] I think my point of view is similar to taavi’s. I likely would not advocate for common.js or a default gadget side loading content from Toolforge or another Cloud VPS project for stability reasons. [11:29:17] n.b. common.js is ambiguous, could be user subpage or could be MediaWiki NS. you seem to mean MediaWiki NS. (re @bd808: I think my point of view is similar to taavi’s. I likely would not advocate for common.js or a default gadget side loading conte...) [11:30:08] Yes, I mean the site wide JavaScript that all visitors load. [11:30:22] otoh something with fewer users in alpha stage, opt-in only, with more active development would be a good fit. (re @bd808: I think my point of view is similar to taavi’s. I likely would not advocate for common.js or a default gadget side loading conte...) [11:31:23] if it's stable getting updates rarely then the on wiki edits are less painful. [11:32:45] I plan to write a little essay as part of the documentation of my new tool that I hope will help folks think about these issues of stability, security, ease of development, and fitness for purpose. [11:39:13] https://tools-static.wmflabs.org/bridgebot/0c97c64f/file_70487.jpg [11:39:13] https://tools-static.wmflabs.org/bridgebot/6806153f/file_70488.jpg [11:39:15] https://tools-static.wmflabs.org/bridgebot/5f045e4c/file_70489.jpg [12:01:48] nice, elno spam [12:42:00] Ideally we'd have a good way to do VCS-backed multi-wiki gadgets, but WMF seems quite unlikely to pursue that. [12:47:01] cf. cross wiki templates. (re @AntiComposite: Ideally we'd have a good way to do VCS-backed multi-wiki gadgets, but WMF seems quite unlikely to pursue that.) [15:09:57] #WTS [15:09:58] We have threads on wwh, exploit, darkmoney, [15:10:00] korovka & other popular forums [15:10:01] KYC verifications on your details [15:10:03] and ready made accounts [15:10:04] Telegram autobuy bot -> @biztopbot [15:10:06] Revolut Chase Business [15:10:07] Paysera Business Bank of America business (Boa) [15:10:09] Bunq Icard Business [15:10:10] Wise Airwallex Business [15:10:12] Bankera Vivid Business [15:10:13] Paysera Revolut Business [15:10:15] iCard Genome Business [15:10:16] Blackcatcard Wamo Business [15:10:18] Genome Wise Business [15:10:19] Skrill Blackcatcard Business [15:10:21] Wirex Payoneer Business [15:10:22] Paysend Wittix Business [15:10:24] Payoneer Wallester Business [15:10:25] Mercuryo Zen Business [15:10:27] LYDIA Juni Business [15:10:28] Xapo bank Okeo Business [15:10:30] Paypal Oropay Business [15:10:31] Volet Libra Business [15:10:33] Zen VertoFx Business [15:10:34] PST Currenxie Business [15:10:36] Vivid Paytota Business [15:10:38] Weststain PayPal Business [15:10:39] Paysafecard Agilityforex Business [15:10:42] Paytend Satchel Business [15:10:44] Bitsa Viva Business [15:29:23] I just turned the "aggressive anti-spam" toggle back on for the Telegram side of this chat. The experiment of turning it off during the Hackathon has shown me that we we still need it (or a different filtering system) to stop boring drive-by channel spam. [15:58:13] bd808: we've implemented a very interesting one on the ptwiki group. It goes through OAuth verification via wiki account. [15:59:20] for a while I've been convinced that we get extra spam specifically because "hack" in title. compared to other channels that also have direct links publicly posted without a separate reception/vetting channel. (re @wmtelegram_bot: I just turned the "aggressive anti-spam" toggle back on for the Telegram side of this chat. The experiment of turning it...) [15:59:40] would that exclude anyone? (re @albertoleoncio: bd808: we've implemented a very interesting one on the ptwiki group. It goes through OAuth verification via wiki account.) [16:01:26] At implementation? We had to silent all members and they un-silent themselves through oauth (re @jeremy_b: would that exclude anyone?) [16:01:57] no, I mean people without accounts or that can't figure out how to do the oauth. (re @albertoleoncio: At implementation? We had to silent all members and they un-silent themselves through oauth) [16:02:12] there's a manual override if you want to give someone an exception? [16:02:36] There should be a pretty low barrier to creating a SUL account, so OAuth seems possible as a gate. [16:02:42] otoh then spam killing will get more boring :-P [16:03:30] Folks who want to avoid that sort of auth in Telegram would still have the RIC side as an option [16:03:33] *IRC [16:04:47] Yep. Just remove the silence rule manually for that user. (re @jeremy_b: there's a manual override if you want to give someone an exception?) [16:06:11] oh right IRC side. I was also specifically thinking there's telegram channels where people don't have to disclose username. fwiw. [16:07:51] Anyone who is concerned with absolute privacy might want to think about the threat model of Telegram in general ;) [16:07:52] We did that mainly because of impersonators. It started getting problematic. The antispan was a side effect. (re @jeremy_b: no, I mean people without accounts or that can't figure out how to do the oauth.) [16:08:42] 💯 😂 (re @wmtelegram_bot: Anyone who is concerned with absolute privacy might want to think about the threat model of Telegram in general ;)) [16:09:58] It is disclosured only with the admins, for all others it's still private (re @jeremy_b: oh right IRC side. I was also specifically thinking there's telegram channels where people don't have to disclose username. fwiw...) [18:38:01] in the en-Wikimedia discord we've not had a huge problem with OAuth to SUL accounts. We do allow unauth'd but they're restricted. There are a couple of people we've manually exempted and a couple of people who don't wish to, but largely not a problem. Hackathon has a different audience ofc [18:39:02] And in reality... Most people wanting to interact will need some sort of account somewhere to be able to use the services they probably want access to too [18:39:58] and someone could always make a sock, never edit with it, auth. [21:32:53] @albertoleoncio: I don't know that we have consensus here yet, but I would really like to learn more about the system that ptwiki is using and if it would scale to being used here. Are there operations docs on a wiki anywhere that I could check out? [23:20:06] The system uses two scripts, where the first is used by users to verify themselves, and the other monitors the entry of new users. [23:20:07] https://github.com/albertoleoncio/wikipedia/blob/main/telegram.php [23:20:09] https://github.com/albertoleoncio/wikipedia/blob/main/telegramdaemon.php (re @wmtelegram_bot: @albertoleoncio: I don't know that we have consensus here yet, but I would really like to learn more about the system th...) [23:27:13] @albertoleoncio: thanks! I just skimmed things, but I think I get the point. You have a webservice on toolforge where people can associate their telegram account with a SUL OAuth grant and then a bot that manages channel permissions on the Telegram side. Neat idea for sure. [23:28:14] Exactly :-)