Closed Bug 880974 Opened 6 years ago Closed 5 years ago

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

Categories

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

x86
Windows Vista
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
2014-Q2

People

(Reporter: wsmwk, Assigned: AlisonW)

References

()

Details

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?
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.
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
Summary: tinyurl.com is blocked as spam at wiki.mozilla.org → adding a tinyurl.com link is blocked as spam at wiki.mozilla.org
Oh I see. Now I can confirm the issue.
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.
Assignee: nobody → tech
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
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?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
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
Status: REOPENED → ASSIGNED
See Also: → 872958
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.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
tinyurl works. thanks!
Status: RESOLVED → VERIFIED
looks like the wrong status was picked when it was resolved last year. Closing.
Status: VERIFIED → RESOLVED
Closed: 6 years ago5 years ago
Target Milestone: --- → 2014-Q2
You need to log in before you can comment on or make changes to this bug.