Month: January 2008

We’ve got a semi-experimental mobile portal for Wikipedia, based on the Hawpedia code using Hawhaw, that’s been up for a while.

I’ve updated it to the current version of the code, which seems to handle some templates better, as well as producing proper output for iPhone viewing. :)

Today’s fancy phones with their fancy browsers (the iPhone, Opera Mini, etc) can do a pretty good job handling the “real web” in addition to the stripped-down limited “mobile web” of yesteryear, but there are different pressures, which one should take into account when targeting mobile devices.

Screens are small, bandwidth is low. Wikipedia articles tend to be very long and thorough, but often all you need for an off-the-cuff lookup is the first couple paragraphs. The WAP gateway splits pages into shorter chunks, so you don’t have to wait to download the entire rest of the page (or wait for the slow phone CPU to lay it out).

Even on an iPhone capable of rendering the whole article and the MonoBook skin in all its glory, I find there’s some strong benefits to a shorter, cleaner page to do quick lookups on the go. (Especially if I’m not on Wifi!)

The biggest problem with the Hawpedia gateway today is that it tries to do its own hacky little wiki text parser, which dies horribly at times. Many pages look fine, but others end up with massive template breakage and become unreadable.

Long-term it may be better to do this translation at a higher level, working from the output XHTML… or else in an intermediate stage of MediaWiki’s own parser, with more semantic information still available.

Did a security release yesterday: MediaWiki 1.11.1, 1.10.3, and 1.9.5. I noticed that some of the output formats for api.php are susceptible to HTML injection through a longstanding problem with Internet Explorer’s content-type autodetection.

We’ve had protection against this in action=raw mode for years, but it didn’t make it into the API as nobody had quite noticed that some output formats were vulnerable. JSON and XML-based formats aren’t, but PHP serialization and YAML don’t escape strings as much as we might like.

If the format lets you pass some raw HTML tags, and you can stick an additional fake path after the script name in the URL (as allowed by most configurations), MSIE opens up a big XSS hole on your site.

Path components in URLs are supposed to be opaque; the HTTP content-type header is the only thing that’s supposed to specify what kind of resource you’re loading. Microsoft thinks it knows better, though — if it recognizes one of several pre-defined “extension”s at the end of the “filename” on the URL, it sniffs the file’s actual content to try to determine the file type. If it sees certain HTML tags, it’ll interpret it as HTML — even for valid GIF and PNG files!

(Rumor is that last hole has finally been fixed in recent Windows security updates; GIF and PNG headers will override the HTML detection. I haven’t tested to confirm this though.)

For “raw” and “API” type stuff where we have to pass through user data, we can protect against the autodetection by ensuring the URL hasn’t been tampered with. Having both an unrecognized URL and an unrecognized content-type keeps the content sniffy away… That’s why you currently get a ‘403 – Forbidden’ if you just toss ?action=raw on the end of a page URL.

Stumbled on this (via a comment at [1]). Definitely something to keep an eye on. :D

Per bug 12655…

On our newer, Ubuntu-based Apache configuration we’ve been using sSMTP as a minimal local SMTP sending agent. This emulates the ‘sendmail’ binary and simply passes messages off to a hub server with no local queuing… but it’s not without its problems.

sSMTP forces the message’s ‘From’ header and the SMTP envelope sender address to be the same, which causes some problems for us when that ‘From’ address is a user’s offsite e-mail:

• Servers which validate SPF records may reject the messages outright
• In case of delivery problems, bounce messages will be sent back to the user, possibly including the recipient’s address which is supposed to be kept private.

As a workaround for such configurations I’ve introduced a config var $wgUserEmailUseReplyTo. When set, a wiki-specific address is used as ‘From’, and the user’s address is put in ‘Reply-To’.

This is uglier — you don’t see a clean ‘Sender’ column in your mail client — but mails will get through and private data won’t get tossed around inappropriately.

In the long term I’d like to see us either dump sSMTP (a local-only postfix or something would work fine) or patch it to let the envelope sender be set separately.

I’d like to revive some interest in improving support for mobile browsers.

Extremely limited WAP-based browsers are at least sort of served by the experimental WAP gateway, but there are a lot of smartphones and other handheld devices that get on the “real” web with greater or lesser degrees of success, and I’d like to see us improve the default look & feel of MediaWiki on them.

At the moment I think we can roughly divide the mobile browsers into two categories:

• Those that render much like a full desktop browser and let you zoom as necessary (iPhone/Mobile Safari, Opera Mini, …?)
• Those that have very limited CSS and JavaScript or strip a lot of stuff down (Opera Mini in “mobile view” mode, most others?)

At the moment, all I’ve got access to are an iPhone and the Opera Mini simulator applet, so that’s what I’ll be putting the occasional bit of time into. These already pretty much “just work”, but the UI can be very awkward due to the desktop-size layout; I’d like a cleaner handheld stylesheet that lets most pages be legible when you get to them.

If you’ve got another device and you’d like to help testing and developing for it, please stake your claim.

Alternatively if you’ve got a spare device you can donate to us, that’d be great too! (Especially if it doesn’t need a service subscription to get on the net…)