[00:34:26] Are self-harm articles not allowed [00:35:14] Even if it’s marked NSFW [02:30:14] @Agent please see DMs, potential oversight [02:59:14] Welp, I think there's a problem with renaming progress [02:59:50] Renaming someone making them appears on all wikis within MH [03:05:21] Oh, there's a bot flag thing for that which might not be flagging correctly... [03:08:48] no, afaik rename logs are added in RC everywhere [03:09:02] it's been like that for awhile, though perhaps we should consider removing it [03:09:09] oh wait hold on, it appears on every wiki? [03:10:08] Yes [03:10:20] Or rather, I would assume, every wiki where an attach has occurred [03:10:39] If it's literally every wiki, that's a big problem [03:15:37] yeah this has always been the case [03:15:42] if it's this that's bad bad [03:16:11] Yes, a rename is broadcasted on every wiki where the user is locally attached [03:16:28] so if you have an account on a lot of wikis then expect to see that rename on a lot of wikis [03:18:38] Would it be appropriate to ask someone for assistance in return for a commission based payment? [03:49:05] I created a global user page but it didn't work, is there any button to enable that? [03:55:53] where did you create it [04:02:44] https://login.miraheze.org/ [04:03:08] is it really worth it? [04:03:46] I just don't have the time to learn the system perfectly [04:05:10] you have to delete your Meta userpage [04:05:15] and all other userpages [04:09:31] wait, I can't delete my meta userpage as I don't have delete permission [04:09:41] @Agent ^ [05:48:39] Use admin Noticeboard [05:48:57] Please don't ping individual users. We have Noticeboards and emails [10:01:44] How can I insert templates on my wiki? [10:06:56] I would add a Infobox [10:14:25] templates has to be created in pages w/ `Template:` prefix [10:14:35] you can code them or import them from another wiki [10:15:18] [1/4] there are several ways to make an infobox [10:15:18] [2/4] - code tables [10:15:19] [3/4] - code w/ PortableInfobox extension [10:15:19] [4/4] - import from another place [10:17:34] [1/4] importing from Wikipedia is a common mistake newbies make here, these infoboxes often are pain to deal w/ [10:17:34] [2/4] so we usually recommend here to go w/ PortableInfobox, it has to be enabled in Manage extensions menu, parser hooks tab [10:17:35] [3/4] see pinned messages here for coding guides [10:17:35] [4/4] you can also make a simple infobox at `Special:InfoboxBuilder` visual interface [11:38:49] [1/2] Can a Steward please delete this page? It was blanked out by the author but has over 1000 edits. [11:38:49] [2/2] https://polcompballanarchy.miraheze.org/wiki/Ultroneism [11:53:23] it's done [11:53:39] lots of things link to it, I left a link to the list in the delete reason [11:59:06] It's probably the self-insert template, I'll clean it up [12:15:23] how is this image set? [14:01:04] PageImages extension iirc [14:17:32] thank you!! [14:23:53] it's the one that conflicts w/ WikiSEO? [14:40:43] So lately, whenever I'm trying to write documentation for infoboxes, the code is parsed horizontally instead of vertically, when it's written to be the latter. Anyone know what's causing this conflict? [14:58:19] yea [14:58:29] actually it's not conflict [14:59:28] Quite annoying that PageImages refuses to grab images in Infoboxes [15:02:17] oh? the image above is from an infobox [15:04:02] is that portable infobox? [15:06:13] I believe so [15:09:33] Didn’t they fix the conflict with seo [15:13:09] hmmmm gotta check this them [18:14:10] [1/2] I don't know if someone gets a notification for new OAuth consumers, but I proposed a new one: [18:14:10] [2/2] https://meta.miraheze.org/wiki/Special:OAuthListConsumers/view/f7d7b6d85767eb1b443f283b63d46d5b [18:42:18] For SRE mainly but could also be of interest to the wider community: we should have an OAuth policy I think, because right now it's kinda at the discretion of the however wishes to handle that stuff [18:44:20] Orange_Star: that's a very good idea [18:44:24] Like for example only using it for Miraheze-related stuff, like identifying users for a tool that's directly relevant to a MH wiki [18:44:38] No using it as free SSO [18:44:41] That stuff [18:46:51] that sounds indeed like a good idea [18:48:06] I'll try to write a draft, see what I come up with [18:54:26] This might be helpful as orientation [18:58:13] [1/2] renamed old image and uploaded new file w/ old title of that image [18:58:13] [2/2] now thumbnails are messed up lol [18:59:24] Wait I think is the advice [19:34:31] Draft is up (https://meta.miraheze.org/wiki/Requests_for_Comment/OAuth_policy) not yet ready for voting though. Suggestions to the talk page pls [19:36:15] Orange_Star: slight point of Ofer [19:36:17] Order [19:36:27] Actual user rights take precedence over grants [19:36:44] So if you don't have the 'checkuser' right and request it, you'll still be denied [19:36:53] I know [19:37:09] I feel it should be in bold [19:37:22] The grants / rights are probably confusing to some users [19:39:40] Orange_Star: ^ [19:42:32] added [20:02:54] Reception123: I would like to request a @miraheze cloak, now that we have a GC [20:13:40] or CosmicAlpha: ^ [20:13:52] Sure [20:20:32] We have GCs again? [20:20:40] yeah [20:20:47] Woo! [20:20:48] Reception123 and CosmicAlpha [20:23:46] Ye sar [20:26:47] Orange_Star: FYI, I requested your cloak a few minutes ago, so they should do it soon. [20:35:50] Orange_Star: done [20:37:03] Orange_Star: Any reason my Oauth was never approved? https://phabricator.miraheze.org/T10387 it was up for a month, until i closed it because i wasnt sure if my domain name would change. But im thinking of reopening. It fits the proposal criterias, except for open source, but id gladly make the code open-source as well. [20:37:34] There was simply no one to ever review it [20:37:36] Well there's a really simple reason for it: The people with access do not know what exactly to do in a review [20:38:03] Oh lol [20:38:25] Also the RfC is currently just a draft, nothing set in stone yet until people vote [20:39:10] Re: Access thing: At least I didn't know what to look for in these reviews, which is why I'm doing the RfC [20:39:15] can't speak for the other SREs [20:39:56] So there hasnt actually been an oauth system in place yet? [20:40:03] more or less [20:40:13] Gotcha [20:40:19] there are some consumers from non-SRE members, like the Discord verification bot [20:40:44] Orange_Star: basically determine if there's a risk [20:41:12] Identity only can be approved if user not an idiot and privacy meets same as CSP standard [20:41:33] that's another thing that needs addressing, the privacy thing [20:41:53] I think identity might allow access to user email [20:41:53] applying the CSP standards looks good to me [20:42:12] There's 2 versions of identity, the one with email access and another one without email [20:42:17] CSP is the only external trust map we have [20:42:30] Without email, user is not idiot is fine tbh [20:42:49] And like it's not illegal activity obviously [20:43:11] With email, CSP questions should be ok [20:43:15] But ask Owen tbh [20:43:16] If the user has to agree to email, before access it is also fine from my understanding. [20:43:37] User always knows what they are sharing [20:43:40] If they read [20:43:51] CosmicAlpha: is a director [20:44:06] So can make calls on if I'm talking shit about privacy [20:45:18] Yeah all i need is email-free identity. Im currently writing my own authentication code, but itd be so much more convenient if i coukd just use MH's. [20:45:28] I don't think we should count on the user reading the consent box [20:45:54] if email apply CSP standards, if not then I guess we can be more permissive about approving [20:45:58] Orange_Star: no but explicit consent reduces the liability a bit [20:46:12] With user consent it is usually fine with email. [20:46:17] If no private info being shared, user is not idiot is fine [20:46:43] If private info, we should check that the users expectation of what's happening is clear [20:47:02] I did have a conversation with Owen about this type of thing a couple months ago also. [20:48:21] consent box for email access looks like this, all in plain text except the "Miraheze Phabricator" text, which is bolded. [20:48:22] In order to complete your request, Miraheze Phabricator needs permission to access information about you, including your real name and email address, on all projects of this site. No changes will be made with your account. [20:49:01] It's more about ensuring least privilege, expectations are valid, not something horrid we don't want to be associated with [20:49:20] We don't want lockbit having login with Miraheze to access ransomware breaches [20:49:31] We don't want CU being able to played with by a login app [20:49:47] And we don't want an app posting your email publicly if you didn't know about it [20:49:49] Orange_Star: ^ [20:50:19] the consent box doesn't say what they will do with that info [20:50:29] only that they will have access to it [20:50:36] So you check the process that would happen before [20:50:45] they may or may not publish your email on Twitter [20:50:45] https://phabricator.miraheze.org/T10270 for example could be approved, technically, it just expired and then a lot happened, I got busy, and then stepped down, so never got to following up with that one. But I reviewed the code also which looked fine, and email is fine with user consent, and talked with Owen about it also. [20:50:48] Like toolforge requires you have privacy warnings [20:51:26] CosmicAlpha: that's a very valid use [20:55:18] Yes, but for other's without a really valid use case would definitely be declined. It is a case-by-case basis, that it should have some discretion to the reviewing user, and no policy can cover every case, it can cover specific invalid and valid, but there will always be one not covered and so for that it should still have some leeway there. Just my opinion anyway. T&S should also be consulted for ones where it has any privacy [20:55:18] information in particular. [20:56:10] I intent to leave the details to the reviewer [20:56:20] Orange_Star: the GMFJ ICO decision I shared with Owen is probably the biggest impact here [20:56:29] RfC is for basic stuff like no requesting insane grants [20:56:30] And that would imply we're fine and not liable [20:58:09] Orange_Star: yeah but like from an actual perspective of data rules [20:58:18] If we've been honest about what's being shared, that's fine [20:58:46] GMFJ argued with me that once data left them, they were no longer responsible for what happened with it [20:59:27] I challenged that because they promised that my mobile number would never be used without initial contact from a recruiter via SMS or email [20:59:48] I said recruiters had failed to do so and when asked to stop didn't [21:00:03] Oh, do I need to create a phab task to ask for consumer approval? [21:00:24] The ICO ruled that GMFJ had to take reasonable measures to ensure that any conditions within their privacy policy regarding information sharing must be complied with [21:00:37] And asked them to improve [21:00:52] MarkusRust: Unless you want a new consumer no [21:01:16] well I created a new one today 😄 [21:01:26] They ruled on a separate point that a specific part of GMFJ's response broke the law because they inadvertently disclosed my data to other users when asked to restrict processing [21:01:37] Orange_Star: is that interesting? [21:02:47] yes [21:03:07] Orange_Star: I can dig up the full decision if you want [21:03:14] Will have to email though [21:03:23] not needed, that's good enough [21:03:50] I don't see any reason to not approve MarkusRost's OAuth consumer request [21:05:39] [1/2] Only because it's the localhost testing version 😅 [21:05:39] [2/2] The production version I'll create when I'm done coding should probably be checked a bit more closely due to the permissions requested [21:05:53] I'm inclined to approve [21:06:54] Overall, I personally don't care about OAuth consumers sharing my email publicly, my personal email is publicly available for everyone to see, but other users may not want that, and while the consent box may clear us of legal liability, I would still like to have consumers requesting email access to pass a CSP review (but without the actual adding to CSP step) [21:07:53] identity only without email we can be more permissive about approving, as long as it's directly related to Miraheze (Proposal 3) [21:08:01] Agent: Click the approve button then [21:08:04] @MarkusRost Approved [21:08:16] thanks 🙂 [21:08:48] np [21:09:50] Orange_Star: I agree that those OAuth consumer requests should go under scrutiny [21:09:56] A CSP like review would be useful [21:12:57] [1/2] @Agent while I agree that no PII is an important factor for approval, I think the trusted user and localhost consumer are more important arguments here. [21:12:57] [2/2] A consumer with delete and block can still do a lot of damage after all [21:14:09] (also what does CSP stand for exactly?) [21:14:17] Content Security Policy [21:14:33] ah, didn't find any results on the wiki [21:14:35] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP [21:21:34] https://meta.miraheze.org/wiki/Requests_for_Comment/OAuth_policy is now open, thanks everyone for the suggestions [21:24:10] that was my thousandth edit in Meta btw :) [21:27:23] I only have 6 edits on Meta and 4 of them were test edits [21:28:15] oh and that's all the edits I ever did on Miraheze [21:38:37] @Agent I made a new request: https://phabricator.miraheze.org/T10806 [22:22:27] heh, my account is nearly 7 years old, and I've only made about 3000 edits globally (2500 of which are on meta)