880974 - adding a tinyurl.com link is blocked as spam at wiki.mozilla.org

Status: RESOLVED FIXED

(Websites :: wiki.mozilla.org, defect)

Description

[Wayne Mery (:wsmwk)]

tinyurl.com is blocked, which I've been using for years.
https://wiki.mozilla.org/Thunderbird:Bug_Queries has 27 such items.

Why is tinyurl now being blocked (not sure when it started)? And if tinyurl will not be whitelisted, which URL shortener can be used which is assured to not be blocked in the future?

Comment 1

[Kohei Yoshino]

I couldn't find any issues with those links. Who is blocking tinyurl.com?

BTY, Mozilla has a contract with bit.ly. You can shorten *.mozilla.org URLs to mzl.la/something by using bit.ly.

Comment 2

[Kohei Yoshino]

You can also use bugzil.la:
http://www.squarefree.com/2010/01/14/shorter-urls-for-bugzilla-mozilla-org/

Comment 3

[Wayne Mery (:wsmwk)]

Sorry. It seems my report can be improved.  Existing links work OK. To reproduce my issue is necessary to add a tinyurl.com link to the wiki.

1. edit https://wiki.mozilla.org/Thunderbird:QA_TestDay:2013-06-12 or https://wiki.mozilla.org/Thunderbird:Bug_Queries
2. add 
  * list of [http://tinyurl.com/mlzmwzr Thunderbird+mailnews bugs] ~530
3. save

result:

Spam protection filter
Home » Thunderbird:Bug_Queries?title=Thunderbird:Bug_Queries&action=submit	

The text you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.

The following text is what triggered our spam filter: Array

Comment 4

[Kohei Yoshino]

Oh I see. Now I can confirm the issue.

Comment 5

[Alison Wheeler [:AlisonW]]

There should never be a need to use a link-shortener on a wiki page; the link can be entered in full with no ill-effects. The reason for normally blocking shorteners is that it is not clear to the reader (or wiki admins) where the link goes and, thus, whether it might be spam. 

If you feel that there is a special usecase for having the ability to not use full links please re-open this bug with details.

Comment 6

[Wayne Mery (:wsmwk)]

Thank you for your comments.  My response below

(In reply to AlisonW from comment #5)
> There should never be a need to use a link-shortener on a wiki page; 

"never" is a strong word.  Clearly there was a reason the shortener was used, but perhaps not obvious.

> the link can be entered in full with no ill-effects. 

long bugzilla query URLs of several hundred character make wiki virtually unreadable when editing and therefore very difficult to maintain. 

> The reason for normally blocking shorteners is that it is not clear to the reader (or wiki admins)
> where the link goes and, thus, whether it might be spam. 

This makes some sense. Was there some announcement on this point?

On the other hand, bit.ly links are being accepted, so why not tinyurl.com?
Further, existing tinyurl.com links in wiki still work.

> If you feel that there is a special usecase for having the ability to not
> use full links please re-open this bug with details.

I do feel there is a legitimate usecase - and the reason they were used in the first place ... long bugzilla query URLs make wiki virtually unreadable when editing and therefore very difficult to maintain. 

Two examples from https://wiki.mozilla.org/Thunderbird:Bug_Queries ...

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=MailNews%20Core&product=Thunderbird&product=Toolkit&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bugidtype=include&field0-0-0=short_desc&type0-0-0=anywordssubstr&value0-0-0=charset%20mime%20lang%20unicode%20utf&field0-1-0=short_desc&type0-1-0=notsubstring&field0-2-0=short_desc&type0-2-0=anywords&field1-0-0=product&type1-0-0=equals&value1-0-0=thunderbird&field1-0-1=component&type1-0-1=anywordssubstr&value1-0-1=mailnews%3A%20imap%20pop%20%20nntp&field1-0-2=component&type1-0-2=equals&value1-0-2=networking%3A%20news&list_id=6842338

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywords&short_desc=biff%20alert%20notify%20notification%20alerts%20notifies&product=MailNews%20Core&product=Thunderbird&resolution=---&bugidtype=include&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=crash%20protocol%20quota%20scam%20leak%20sound%20button%20%20litmus%20extension%20assert%20addon%20passw%20ldap%20compos&field0-1-0=component&type0-1-0=nowordssubstr&value0-1-0=attach%20compos%20address%20rss%20migra&field0-2-0=short_desc&type0-2-0=nowords&value0-2-0=news&list_id=6842340

Surely people with wiki accounts can be trusted to not put up junk and malicious links on mozilla wiki pages?

Comment 7

[Wayne Mery (:wsmwk)]

It gets even worse when dealing with such long URLs in tables, as in quite *impossible* to properly set up and manage with long URLs.

I also now vaguely recall encountering URLs containing characters that have literally caused table formatting problems.  Too long in the past for me to recall an example.

Comment 8

[Alison Wheeler [:AlisonW]]

Thanks for the info and examples.

As you say, I probably shouldn't use 'never' but I'd prefer to see if we can find an alternative option first to retain a level of security re link shorteners. This will hopefully apply to all shorteners eventually.

As regards "Surely people with wiki accounts can be trusted to not put up junk and malicious links on mozilla wiki pages?" whilst it would be lovely to believe this, MozillaWiki has an open registration policy, thus there is no implicit or explicit trust engendered by the existence of an account.

To link to a single Bugzilla report you can use: {{Bugzilla|bug number}} eg {{Bugzilla|880974}} 

I'll update you shortly re Bugzilla searching

Comment 9

[Alison Wheeler [:AlisonW]]

The 'offending' line in the https://wiki.mozilla.org/Spam_blacklist page is

> \b(?:mobile|really)?tinyurls?\.(?:co\.uk|com|ru|tw|us)\b

It doesn't exist in the (shorter overall) MediaWiki:Spam-blacklist version.

So far as I can see, only "tinyurl.com" probably needs to be allowed, so I am changing the blacklist to permit that particular variation; the others should remain blocked (does that work for everyone?)

Revised block therefore is

> \b(?:mobile|really)?tinyurls\.(?:co\.uk|com|ru|tw|us)\b
> \b(?:mobile|really)?tinyurl\.(?:co\.uk|ru|tw|us)\b

This is now in place and tested both ways.

Comment 10

[Wayne Mery (:wsmwk)]

tinyurl works. thanks!

Comment 11

[Alison Wheeler [:AlisonW]]

looks like the wrong status was picked when it was resolved last year. Closing.