Last modified: 2011-03-13 18:04:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6891, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4891 - Spam filtering should be able to follow redirects
Spam filtering should be able to follow redirects
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Talk:S...
:
Depends on:
Blocks: 4462
  Show dependency treegraph
 
Reported: 2006-02-06 13:28 UTC by Stewart Gordon
Modified: 2011-03-13 18:04 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Stewart Gordon 2006-02-06 13:28:53 UTC
I often use http://www.tinyurl.com/ to shorten the URLs of external sites linked
to from Wikipedia.  This is useful for stopping the diffs from being too wide to
be readable.

However, tinyurl.com and other link-shortening services have just been added to
Wikipedia's spam blacklist.  Of course, it can't be helped that some people will
try to use it to bypass Wikipedia's spam filter in order to link to bad sites
(pornography, malware, etc.).  However, it's quite straightforward to stop this
abuse of these services, short of banning links to URL redirectors altogether.

When a link to a URL redirection domain is entered into a page, MediaWiki should
follow the link to find out what it redirects to.  If the destination of the
redirect is on the blacklist, then veto the link.  If it isn't, then allow it.

Following every link to see if it redirects somewhere might put more load on the
server than is desirable and slow down the process of saving a wiki page. 
Therefore we probably should have, as well as a blacklist, a 'redirect list' of
domains in which to follow redirects.
Comment 1 ssd 2006-02-06 13:39:41 UTC
As stated in the mailing list, link redirectors present the
following unavoidable hazards:
* (As you stated) we don't know where the link goes.
* It places an external dependance on wikipedia.
* The link could be changed by a third party without our knowlege.
* The user has no way of knowing the link target until it is too late.

Only the first of these problems is fixable by following the link.
The best solution to this would be for mediawiki to follow the link, and REPLACE
it with the target.  What advantage is there in mediawiki doing this replacement
vs. the user just not using the link redirector in the first place?
Comment 2 Stewart Gordon 2006-02-06 13:57:09 UTC
(In reply to comment #1)
> As stated in the mailing list, link redirectors present the
> following unavoidable hazards:
> * (As you stated) we don't know where the link goes.
> * It places an external dependance on wikipedia.
> * The link could be changed by a third party without our knowlege.

That's true of URL redirectors such as cjb and shorturl, which are designed for
creating a memorable, stable URL for a website.  The point of tinyurl, OTOH, is
to produce URLs that permanently redirect to the same place.

Besides, the content of any webpage can change, whether it's been linked to
directly or via redirection.

> * The user has no way of knowing the link target until it is too late.

Not quite true.  For example, http://validator.w3.org/ can be used to expand
such links before visiting the site.

> Only the first of these problems is fixable by following the link.
> The best solution to this would be for mediawiki to follow the link, and REPLACE
> it with the target.  What advantage is there in mediawiki doing this replacement
> vs. the user just not using the link redirector in the first place?

Do you have a better idea for solving the problem of diffs becoming too wide?
Comment 3 ssd 2006-02-06 14:04:43 UTC
I'd also like to point out that wikipedia has a built in link redirector.  If
you say [http://url/] it replaces it with a small integer, or [http://url/
label] replaces it with a label.  But you knew that.

As to the diff problem -- I suggest you file a separate bug report for that.  A
better solution would be to fold the URL.  (Does html have the inverse of NBSP?
 This could use a NSPBR.)
Comment 4 Stewart Gordon 2006-02-06 16:24:49 UTC
You mean like a place where the line may be broken, but which doesn't otherwise
produce a space?  I think the nearest you'll get is ­ (soft hyphenation
hint) but it seems that hardly any browsers support it (apparently some ignore
it and others render a visible hyphen even where it doesn't break the line).  We
could also work some CSS magic to reduce the spaces to zero width, but that's a
dirty trick that'll break if CSS is disabled....
Comment 5 ssd 2006-02-06 17:04:32 UTC
Closest bug I could find in a hurry is Bug 1229.
Discussions of changing diff behavior should probably go there?
Comment 6 Brion Vibber 2006-02-06 21:16:52 UTC
I'm inclined to WONTFIX this; third-party redirectors are inherently unstable and 
untrusted.

Diff behavior is not relevant, that's a separate issue.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links