Requests for Comment/Interwiki links editing

Interwiki links are links that allow wikis to link pages from other wikis. There is a global Miraheze interwiki which is the default for all wikis, as well as local interwikis for each wiki. Users are not allowed to edit their own interwiki, and this is due to the fact that interwiki can be used for phishing, spam and other malicious uses, since the links appear as any other wiki page.

Proposal 1
Create a new group called "interwiki-admin". This group will be able to edit local interwiki upon request, but not the global list which will remain restricted to Meta administrators. Interwiki admins may edit any interwiki where they are a bureaucrat, but naturally should not edit any other interwikis without a request from a bureaucrat there.

Interwiki admins are required to check every link before they add it to interwiki, to make sure it is not malicious.

Rights and Eligibility criteria

interwiki-admin is voted on by users. However, the following conditions must be met in order for the user to be eligible to be voted. If these conditions are not met, the user may not be a candidate for 'interwiki-admin' and any support votes will not matter. A candidate must:


 * Have at least 1000 total global edits on Miraheze (on more than one wiki) ( Note: These edits may not consist of directly copy/pasting content from other wikis, they must be edits done by the user )


 * Have had their Miraheze account for at least 2 months
 * Be involved in some way in community matters (in discussions on Community Noticeboard, etc.)

Revocation

If an interwiki-admin adds any malicious site to interwiki, they can immediately be revoked without warning.

Support

 * 1) as proposer. Reception123  (talk) ('C' ) 06:58, 23 July 2018 (UTC)
 * 2) Seems good to me.-- 10:18, 23 July 2018 (UTC)
 * 3) MacFan4000 (Talk Contribs) 15:20, 23 July 2018 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | Talk | P mail.svg | Discord color D.svg  &#32; 18:43, 23 July 2018 (UTC)
 * 5) —AlvaroMolina (✉ -  ✔ ) 20:45, 24 July 2018 (UTC)
 * 6) Sounds ok to me.  21:27, 24 July 2018 (UTC)
 * 7) I agree with this, even though I do not seem eligible to have this user right at this time. Joey717 (talk) 08:48, 26 July 2018 (UTC)
 * 8) Wiki1776 (talk) 13:31, 26 July 2018 (UTC)
 * 9) GethN7 (talk) 13:40, 26 July 2018 (UTC)
 * 10) Uncyclopedia has this need.--黑底屍 (talk) 02:02, 27 July 2018 (UTC)
 * 11) It would be better if the founder of a wiki automatically gets the right to edit the local interwiki table of their own wiki, but I guess bureaucracy is the catch of choosing a wiki farm. -- 11:04, 27 July 2018 (UTC)
 * 12) *I personally do not want any bureaucracy, as it is annoying for everyone to have to vote for users, then they get granted rights, etc. but this is (the way I see it) the only way that we can allow more users to have access to interwiki, rather than only sysadmins and Meta administrators. Again, this is for security reasons, not because we do not want to give rights to users. Reception123 (talk) ('C' ) 12:18, 27 July 2018 (UTC)
 * 13) Robkelk (talk) 16:06, 27 July 2018 (UTC)

Oppose

 * 1) I’ll be alone here. While I think this is a good idea in theory, I just can’t bring myself to support the concept of the original creators/founders/bureaucrats of a wiki having to ask permission from the stewards or an “interwiki-admin” in order to modify Special:Interwiki on their own wiki. That just seems to be global interference with local operations, and simply too much bureaucracy. I understand the security risks, but frankly, Miraheze is currently using a few features that have security risks if misused. In fact, any feature can have security risks if misused or abused. As such, if a user adds a malicious prefix to their interwiki, they/their wiki should suffer the consequences of either being destroyed by malware, or having their wiki taken down for violating the content policy. Also, I feel that a user should not have to request interwiki-admin only as a global permission - they should be able to have it locally just on one wiki (i.e. their own). Amanda Catherine (talk) 14:17, 26 July 2018 (UTC)
 * 2) * First of all, from a sysadmin point of view, if you know of any features that have security risks used at Miraheze, you are invited to please make them known to us at security[at]miraheze[dot]org. Second, since Miraheze is a wiki farm, and not individual wikis, a user can just visit wikis by using things like Gazetteer of wikis or Special:WikiDiscover, therefore, they should not have to deal with a wiki sysop or bureaucrat possibly inserting malicious links on Interwiki, either by accident or intentionally. Local interwiki would be useless if one has global interwiki. Reception123 (talk) ('C' ) 16:21, 26 July 2018 (UTC)
 * 3) ** I don't see why it's "therefore". Also, how "they should not have to deal with a wiki sysop or bureaucrat possibly inserting malicious links on Interwiki" is substantially different from dealing with possibility of inserting the same links in articles, templates, etc? TBeholder (talk) 00:03, 27 July 2018 (UTC)

Comments
Discussing privileges before policy is not a very solid approach. First, if the proposed target site is merely not “malicious”, then should an interwiki editor add it because a couple of wiki editors want it? Second, what namely does “malicious” mean? On July 23 wiki.example.net points to some site with innocuous static HTML pages. But the same hour the link is added to the interwiki table a baddie steals the password for DNS control panel for example.net (or even cracks the server ns.example.net). On July 24 we see wiki.example.net pointing to a site ridden with trojans. How should an interwiki editor guard against domains with poor security? Incnis Mrsi (talk) 08:48, 23 July 2018 (UTC)
 * Even if many users want it, for security reasons it should not be added by the interwiki admin. This is a definition for malicious, but what I mean in this case specifically is any site which contains anything that can do harm to a user's computer (such as spam, phishing attempts, anything like that). The latter example you give is something that no one can be aware of (even the Meta sysops and sysadmins currently managing interwiki). The latter example should be reported by users, and then the interwiki administrator can remove it, rather than having to wait for a Meta sysop or sysadmin (which could take more time). Reception123 (talk) ('C' ) 09:12, 23 July 2018 (UTC)
 * Ironically, this reply of the proposer—with a https: link to Wikipedia—casts a doubt on feasibility of the interwiki mechanism on Mirahese. Can this mess be managed at all if not every sysadmin is willing to use it even for the most popular sites? Perhaps this job should be more about watching the health of linked sites and removal of dubious records rather than adding scores of new records? Consequences of poor security of sites and domains can’t be predicted for each individual case—look, even [//commons.wikimedia.org/w/index.php?title=MediaWiki:Common.js&action=history&offset=201807 Wikimedia Commons was cracked not a long time ago]—but guards against unreliable domains would be helpful. First of all, rather than wait for users’ reports about each link to a dangerous site, a guideline should mandate that If the linked site is down for a considerable time, is parked, or the domain is manifestly put for sale, than the interwiki record is subject to removal. Incnis Mrsi (talk) 15:11, 23 July 2018 (UTC)

Responses to your questions: 1. There could be a new page for handling requests, and they would be handled by all users (including interwiki-admins) who have the right to change interwiki. 2. Yes, translating and wiki creation helps the community. 3. That is to be decided, but most likely a new page called "Requests for global rights". 4. Answered in 1. Reception123 (talk) ('C' ) 12:23, 23 July 2018 (UTC)
 * I agree with the draft, but have several questions.
 * Who will handle interwiki requests (and when will they be handled), before everything is settled? (Like the one I made on Stewards' noticeboard)
 * Are translation and wiki creation works included in your definition of "being involved in some way"?
 * And additionally, are translation works counted as edits (it's NOT a copy, but still, it's based on other contents in English)?
 * Where should a user make a request for interwiki-admin permission?
 * Where should an interwiki request be made after this user group is created? (ex. stewards' noticeboard, Phab, or create a new page specified to this kind of requests, etc.)
 * -- 10:18, 23 July 2018 (UTC)
 * I see. Thanks for your response.-- 12:32, 23 July 2018 (UTC)
 * Yes, that guideline is a good idea. Reception123 (talk) ('C' ) 19:39, 23 July 2018 (UTC)
 * Just to clarify, this will be a sysadmin managed group? MacFan4000 (Talk Contribs) 19:04, 25 July 2018 (UTC)
 * What do you mean "sysadmin managed"? If you mean if they are appointed by sysadmins, no, appointment is done by a community vote (since Meta sysops have interwiki delegated too). Reception123 (talk) ('C' ) 19:46, 25 July 2018 (UTC)
 * I mean who assigns the perms? Stewards, sysadmins etc. MacFan4000 (Talk Contribs) 19:50, 25 July 2018 (UTC)
 * For requesting prefixes, I think Community noticeboard is a good place. MacFan4000 (Talk Contribs) 19:56, 25 July 2018 (UTC)
 * As a community elected role, stewards. John (talk) 20:33, 25 July 2018 (UTC)
 * Community noticeboard should be good for requesting new prefixes; if the number of requests becomes large, a new page dedicated to requests can be created. Reception123 (talk) ('C' ) 07:12, 26 July 2018 (UTC)


 * Question: Would local bureaucrats/founders be eligible to automatically hold this right on their own wiki? It makes no sense for a user to have to make a request to themselves in order to change the interwikis on their own wiki. Amanda Catherine (talk) 14:01, 26 July 2018 (UTC)
 * No. We have already stated that that would be a security risk, as someone could add a prefix that links to a malicious site. MacFan4000 (Talk Contribs) 14:05, 26 July 2018 (UTC)


 * This takes a security feature from the local admins and creates hassle. Practically, the local admins are the people most likely to be actually interested in a random site having shortcut on their interwiki and thus aware of its current status, since they wanted a shortcut for it on their wiki in the first place. If they have access to the interwiki: whenever one of these often-used sites is hacked, any one local OR global admin could under one minute, with no hassle, issue a temporary block for the compromised site simply by rewriting one interwiki shortcut. If they don't have access to it: they'll need to run and ask mommy, wait to be noticed, and all this will take many times longer than it takes to open the page and rewriting one line even in best case scenario (but of course security features should not be planned for the best case scenario), and increase in the time the shortcut points at an often-linked compromised site increases risk for the users. TBeholder (talk) 00:37, 27 July 2018 (UTC)
 * Also, this discourages using interwiki at all, because for a local admin it will look like more hassle than necessary, because you'll be surprised how many people just don't like being treated like schoolkids "on suspicion" like above, or because a single "community organizer" will be able to block or redirect an ideologically impure BadSite at will, while they cannot undo it. Speaking of which, the requirements look like it's a seat for "community organizers" more than sysadmins. TBeholder (talk) 00:37, 27 July 2018 (UTC)
 * And couldn't it be allowed "partially"? I mean they can edit it but only add Wikis from Wikimedia (.wikipedia.org,.wikinews) Wiki1776 (talk) 02:33, 27 July 2018 (UTC)
 * Security must be put first, this may create a hassle, but we cannot risk that users are redirected to malicious websites from Miraheze. I am requesting the addition of interwiki-admin in the hope that users who are trusted can easily get access to interwiki, as opposed to only Meta admins and sysadmins having this access.
 * I don't think that's possible, but if it is, then sure. Reception123 (talk) ('C' ) 04:50, 27 July 2018 (UTC)