I oppose using w.wiki domain for shortening labs URLs. Labs does not follow WMF term of use and privacy policy, in particular you can load arbitrary 3rd party script (though this is being phased out) and redirect labs URL to arbitrary external URL.

Since there's some use case for shortening labs URLs, let's make a new domain (probably cs.w.wiki or labs.wiki) which points to an independant labs-hosted service.

I would love if we could use a URL shortener for Wmflabs

In T231518#5471564, @Vojtech.dostal wrote:

I would love if we could use a URL shortener for Wmflabs

Looks like someone once attempted to provide a url shortening service at wmflabs.org: https://tools.wmflabs.org/durl-shortener/. Assuming that wasn't shut down for ToU or security issues, I'd think it'd be fairly trivial to set up such a service under wmflabs.org which only allowed redirects to other wmflabs.org urls. tools.wmflabs.org/tool/shortid isn't quite as nice w.wiki/shortid, but certainly better than the url mentioned within the task description.

What about https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects, @sbassett?

@Urbanecm That'd be functionally equivalent in some ways, though seems to have originally been for a different purpose. Also, editing Hiera configs and using the Horizon tool isn't quite as user-friendly as the UI for w.wiki (and most other url shorteners) IMO.

Yeah, but can serve as a start.

As I said in the recently-merged ticket:

"If the whole tools subdomain cannot be whitelisted, there should be a whitelist on a tool-by-tool basis"

What sort of criteria and restrictions would we have to impose on such a
whitelisted tool?

Also what happens if a tool gets whitelisted and then fails to keep up high standards? Do we break all the links?

In T231518#5721207, @Krenair wrote:

What sort of criteria and restrictions would we have to impose on such a
whitelisted tool?

The objection, above, was "Labs does not follow WMF term of use and privacy policy"

So, presumably, the criteria would be to follow WMF term of use and privacy policy.

Well yes. The question is then what actual requirements and restrictions
does that create? For example, do we have to conceal UAs from the tool? Do
we need to restrict who can be a maintainer of the tool to people with NDAs?

Strong oppose for reason stated in T142068: Possible to circumvent shortening URL list by Special:Search (someone please make this task public); In particular development of Labs tools are not subject to security review of any kind.
I suggest T232240: New service to shorten wmflabs URLs instead.

I guess the biggest risk here is phising potential, whether directly or via an open redirect?

I generally agree with the whole, we should just use another domain for labs shorterner argument, to be safe

Another domain is fine for me. About the privacy/security implications: now people are using alternatives like bit.ly and tinyurl.com over which we have zero control in terms of privacy implications. So i guess anything we can create/control ourselves would be better.

I can create a project in cloud vps and install url shortener there. Is there anyone who wants to help maintaining it for the future?

In T231518#5722865, @Ladsgroup wrote:

I can create a project in cloud vps and install url shortener there. Is there anyone who wants to help maintaining it for the future?

Count me in.

Note we don't need MediaWiki backend in a new system.

Also a new service may be helpful for shortening longer query URL (T220703: Increase the max length of URL to be shortened) in production domain.

In T231518#5722865, @Ladsgroup wrote:

I can create a project in cloud vps and install url shortener there. Is there anyone who wants to help maintaining it for the future?

Sure, I'll help too.