MediaWiki version statistics

Some kind people at Qualys have surveyed versions of open source web apps present on the web, including MediaWiki. Here is the relevant page from their presentation:
Image (1) MediaWiki-versions-2010-07-30.png for post 3823
For the original see:

And the press release:

They make the point that 95% of MediaWiki installations have a “serious vulnerability”, whereas only 4% of WordPress installations do. While WordPress’s web-based upgrade utility certainly has a positive impact on security, I feel I should point out that what WordPress counts as a serious vulnerability does not align with MediaWiki’s definition of the same term.
For instance, if a web-based user could execute arbitrary PHP code on the server, compromising all data and user accounts, we would count that as the most serious sort of vulnerability, and we would do an immediate release to fix it. We’re proud of the fact that we haven’t had any such vulnerability in a stable release since 1.5.3 (December 2005).
However in WordPress, they count this as a feature, and all administrators can do it. Similarly, WordPress avoids the difficult problem of sanitising HTML and CSS while preserving a rich feature set by simply allowing all authors to post raw HTML.
If you are running MediaWiki in a CMS-like mode, with whitelist edit and account creation restricted, then I think it’s fair to say that in terms of security, you’re better off with MediaWiki 1.14.1 or later than you are with the latest version of WordPress.
However, the statistics presented by Qualys show that an alarming number of people are running versions of MediaWiki older than 1.14.1, which was the most recent fix for an XSS vulnerability exploitable without special privileges. There is certainly room for us to do better.
We have a new installer project in development, which we hope to release in 1.17. It includes a feature which encourages users to sign up for our release announcements mailing list. But maybe we need to do more. Should we take a leaf from WordPress’s book, and nag administrators with a prominent notice when they are not using the latest version? Such a feature would require MediaWiki to “dial home”, which is controversial in our developer community.
Tim Starling, Lead Platform Architect

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

12 Comments
Inline Feedbacks
View all comments

GIven that a list of websites uysing each version of Mediawiki exists, perhaps it would be best to contact site owners via any publically available email address, reminding them to upgrade?
Wordpress does the advantage that it is *extremely* easy to upgrade. There is just a single link in the admin control panal labelled “upgrade”. You click, it upgrades. No further action required.

First, I’m curious as to how those numbers reflect the real world. I mean, according to that there is maybe a thousand or two installs of MediaWiki, tops? And are they unique hosts? or domain names? Or what? Wikia uses 1.15.4 (as a base), and they’ve got a lot of domains. Obvious the Foundation itself is excluded from these numbers too. Also, another major difference. If you don’t upgrade WordPress, you _will_ get compromised. MediaWiki… you’re safer (not saying you shouldn’t, simply that it is much less likely). Complacency is bad, but even still, WordPress has been hit numerous times… Read more »

I think that as long as such a feature would be configurable, it is a perfectly acceptable feature to dial home at regular intervals. Likely MediaWiki would require a privacy policy for that feature though.
Having said that, i’m not sure how many people will actually take action after being notified, if the upgrade process wasn’t a “click this button” type of upgrade. I know I once stopped using software, simply because it too often tried to tell me I needed to upgrade.

Is it controversial in our developer community? Has any developer stated that a “dialing home” feature with a reasonable privacy policy and config option to disable it is a bad idea?
I imagine it just needs to be implemented?

Interesting and ironic that the WikiMedia Technical Blog uses WordPress.org. I would be curious why you didn’t use MediaWiki, though there may have been exogenous factors.

Jon : First, I’m curious as to how those numbers reflect the real world. I mean, according to that there is maybe a thousand or two installs of MediaWiki, tops? And are they unique hosts? or domain names? Or what? Wikia uses 1.15.4 (as a base), and they’ve got a lot of domains. Obvious the Foundation itself is excluded from these numbers too. It’s a sample, the numbers are relative to the sample size, they’re not absolute. The PDF indicates that they scanned the root path on 1 million .com domains, randomly selected from a list of 87 million domains.… Read more »

I think mediawiki’s lack of a true admin control panel is part of the problem. Even if there were a “dial home” feature, if it were located on a new special page, most people wouldn’t even know to look at it. Besides the difficulty in the actual upgrade process, the absence of a centralized admin management area is probably the biggest barrier to use of the software.

I’d echo what Respendent said. Wikis in general follow the power law in terms of number of users & number of edits – a very small number of high profile sites with huge volume, typically run either by active community groups/foundations or by corporations, and a long tail of much smaller wikis, typically run by individuals, with typically much less content, fewer edits, and fewer administrative resources. It would be good to see a graph of age-of-MediaWiki-release-being-used versus number of users & edits, but I’d expect that there would be correlation there – i.e. smaller wikis running much older releases… Read more »

The strange thing is there’s already a fairly straightforward user preferences CP, so the fact that there’s no similar all-in-one admin CP just strikes me as strange. Extension management and usergroup permissions are probably the most annoying things to configure right now because of this. Having to manually edit the localsettings file each time seems so unnecessary. I do realize Tim and other MW devs have limited time and resources, but if there’s one thing they could do to increase usage and lower the number of insecure installations, an admin CP would be an excellent place to start.

I’d also like to add in response to this post’s actual subject that the fact that it took so long to release 1.16 may have skewed the numbers due to admins waiting for a gold release to upgrade. I know I didn’t want to bother with the 1.15.x interim releases once I installed it the first time, especially after seeing the major changes 1.16 would bring. But then again I am fairly lazy.

Respendent : I think mediawiki’s lack of a true admin control panel is part of the problem. Even if there were a “dial home” feature, if it were located on a new special page, most people wouldn’t even know to look at it. Besides the difficulty in the actual upgrade process, the absence of a centralized admin management area is probably the biggest barrier to use of the software. I agree here. Though openness is one thing, intuitive management for a (technical) person is another. Some kind of control panel, only visible to certain users would certainly be a hugh… Read more »

Excellent, what a website it is! This webpage provides helpful facts to us, keep it up.