Page MenuHomePhabricator

Add *.wmflabs.org to w.wiki shortener
Closed, DeclinedPublic

Event Timeline

Husky created this task.Aug 29 2019, 7:15 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 29 2019, 7:15 AM

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

Legoktm closed this task as Declined.Sep 7 2019, 12:43 AM
Legoktm added a subscriber: Legoktm.

It's all but impossible to verify *.wmflabs.org has no open redirects or security issues. Adding it to the whitelist would get rid of the privacy/security promise of w.wiki, in that the destination is trusted. We don't trust *.wmflabs.org in the same way.

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.

@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"

Pigsonthewing reopened this task as Open.Dec 8 2019, 3:07 PM

Reopening, as this ticket did not address the whitelist I suggest in my merged ticket.

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

Bawolff added a subscriber: Bawolff.Dec 8 2019, 3:33 PM

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

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

Husky added a comment.Dec 9 2019, 10:18 AM

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?

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.

Bugreporter added a comment.EditedDec 9 2019, 9:13 PM

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.

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.

Legoktm closed this task as Declined.Dec 10 2019, 8:28 PM

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"

All code on the currently whitelisted domains goes through some form of code review or security review whether by us or a trusted upstream like Debian (if you find a domain where that isn't the case, it should be removed from the whitelist). There is currently no mechanism available in Toolforge to facilitate that. I suggest the best way forward is for you to explain which tool has too long URLs, and work with the maintainer to figure out how to shorten them. Or alternatively, move it into MediaWiki in some way.

If someone wants to set up a separate URL shortener, see T232240. w.wiki won't be whitelisting those domains at this time.