Page MenuHomePhabricator

Short URL Shortcuts: Whole domain components need to be predetermined, not just the sister components
Open, Needs TriagePublic

Description

There is the ability to make one's own subdomains from within the sisters when one is creating a shortcut. This is going to be so abused for political statements and by LTAs once they find its availability. See http://w.wiki/34X

There should either be checklist for all full domains/sister wikis, or checking that a url exists prior to creating the shortcut.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 16 2019, 8:05 AM
Jc86035 added a subscriber: Jc86035.EditedApr 16 2019, 8:45 AM

I don't think a checklist would be easily maintainable. Perhaps a three-character limit for arbitrary subdomains, plus a separate whitelist (or alternately one regular expression with both)?

In any case, the main issue is probably the data after the domain name (e.g. https://en.wikipedia.org/wiki/YOUR TEXT HERE). There's virtually no way of completely preventing that without disallowing legitimate links, although a check on whether the URL is a 404 could prevent some low-effort spam. (You'd still have to allow arbitrary section links and Wikidata queries, at minimum.)

Regarding the URI PATH component there seems to be a legit use case for allowing arbitrary pages here such as "Hey friend, when you are ready create that page here: https://w.wiki/32m"

Xaosflux renamed this task from Shortcuts: Whole domain components need to be predetermined, not just the sister components to Short URL Shortcuts: Whole domain components need to be predetermined, not just the sister components.Apr 16 2019, 11:10 AM

I don't think a checklist would be easily maintainable. Perhaps a three-character limit for arbitrary subdomains, plus a separate whitelist (or alternately one regular expression with both)?
In any case, the main issue is probably the data after the domain name (e.g. https://en.wikipedia.org/wiki/YOUR TEXT HERE). There's virtually no way of completely preventing that without disallowing legitimate links, although a check on whether the URL is a 404 could prevent some low-effort spam. (You'd still have to allow arbitrary section links and Wikidata queries, at minimum.)

The lists already exist in a form, these are existing wikis with known targets which change in a known means, and under the controls of the developers. https://noc.wikimedia.org/conf

This is going to be so abused for political statements and by LTAs once they find its availability.

Sure, anything can be abused. They also could just do https://en.wikipedia.org/wiki/This_is_something_not_constructive or whatever. What vulnerability is there in allowing fake domain names?

This is going to be so abused for political statements and by LTAs once they find its availability.

Sure, anything can be abused. They also could just do https://en.wikipedia.org/wiki/This_is_something_not_constructive or whatever. What vulnerability is there in allowing fake domain names?

Who said anything about vulnerability? We spend enough time clearing up after vandals and LTAs so giving them yet another avenue to abuse is not encouraging. Now we have created a new tool that is set to be managed by stewards, an elite group of limited numbers of busy people. Brilliant.

So if you are going to allow any free text in subdomain names, and in page names, then are we going to need to ensure that we are utilising title blacklist to protect from abuse? Where currently we have vandals that are untraceable, and unpreventable.

Personally I would have liked for us to only generate shortcuts to existing pages, which I had presumed was the purpose of the generation of shortcuts, though that was not clearly part of any conversation that shortcuts had no relationship to what pages existed.