Protocol-relative URLs; GSoC updates; bad news for SMW fans; brief news

Using the "secure server" protocol, https, to communicate with a website (web server) has long been considered a must when editing from unsecured networks and from locations considered insecure. Using https encrypts communications between a user's computer and the Wikimedia servers (for example), preventing the interception of plaintext username-password combinations during a browsing session. In the fallout from the release of the Firesheep Firefox extension (see previous Signpost coverage), however, it became clear that many felt this solution alone to be insufficient, since editors often forgot to switch from http to https when the need arose. As a result, there were calls to make https the default for all editors and, in preparation for such a switch, the process of making Wikimedia more https-friendly began.

This week, work on switching to https took a leap forward with the introduction of "protocol-relative" URLs onto a test wiki. This means that instead of internal links (both hyperlinks and file references, for example for images) pointing to locations prefixed with specific protocols, they will now not specify a protocol. The user's browser is then expected to fulfil the request using the same protocol it used for the originating page: links on a page loaded using the https protocol will point to the https (secure) site, while links on an http page will point to the http (insecure) site. According to the Wikimedia Foundation blog, the benefits are obvious:

Of eight students selected earlier this year to receive funding from Internet giant Google to work on MediaWiki, seven are still with the project. This week their progress so far was published on the Wikimedia blog, including links to the project pages maintained by each student. Projects this year include Ajax login screens, citation archives and user script customisation.

In addition to factual information, the post also disclosed thoughts from the students about what they had learned so far. "True learning can happen only in an open environment and with a highly supportive community", noted Akshay Agarwal, whilst fellow student Devayon Das commented that "A 30 second chat with a community member can save you 30 minutes of scratching your head in frustration". Salvatore Ingala chose to highlight the importance of unit tests (see previous Signpost coverage): "unit testing is boooooring, but ends up saving you a lot of time!", he wrote.

LWN.net, a news site for Linux and other open source projects, recently carried a post addressing Semantic MediaWiki (for more information about SMW, see previous Signpost coverage). Its final paragraph concluded that:

However, volunteer developer Simetrical used the opportunity to clarify that SMW's adoption by Wikimedia projects was not just unclear, but impossible:

In unrelated news, those interested in SMW can now follow the project on Twitter or open-source alternative identi.ca (more information).

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.

How you can help

Give your views on <math>

This week, developers appealed for views on the rendering options available for <math>-tags. Does it affect you? Comment now!

• Sumana Harihareswara, the Foundation's Volunteer Development Coordinator, investigated how the open source project Launchpad handles its own development workflow to see if MediaWiki could learn any lessons from it. Her report succeeded in drawing some useful comparisons, although by its own admission the learning process will be hindered by the fact that MediaWiki relies on a subtle interplay between paid and volunteer developers while Launchpad has only a very small volunteer developer community (wikitech-l mailing list). In unrelated news, Harihareswara also called for developers due to be present at this year's Wikimania conference to help plan coding "sprints" (wikitech-l mailing list).
• Email notifications will no longer be sent to unconfirmed email addresses, to prevent accusations of spam (bug #17866).
• This week saw the first testing of a new release system, known as "Heterogeneous", which will enable different WMF wikis to run different versions of MediaWiki software. This would allow for selective testing of new versions, for example, on right-to-left wikis (more software developments).
• Wikimedia has joined the Unicode Consortium as a liaison member, putting it in the same category as the GNOME Foundation and Mozilla. Membership, which is free but requires approval, allows Wikimedia to contribute to official discussions relating to the Unicode character encoding standard (wikitech-l).
• There was a discussion on the wikitech-l mailing list following the news that the "default assignees" for different categories of Bugzilla bugs had been reset to wikibugs, the "no-one in particular" superuser.
• 5 bot tasks were approved this week, but a number of proposals are still open, including one that would see a bot tag files as eligible for being moved to Wikimedia Commons.

← Previous "Technology report"

Next "Technology report" →

In this issue

25 July 2011 (all comments)

Wikimedian in Residence interview

News and notes

In the news

Recent research

WikiProject report

Featured content

Arbitration report

Technology report

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

I'm going to switch to using the secure Wikipedia servers right away. I hope HTTPS reaches all users soon. --Nathan2055^talk 00:11, 26 July 2011 (UTC)[reply]

I tried using it a few times in the past, but gave up because of the annoying way in which my browser keeps issuing warning notices every time a new page loads. — Cheers, JackLee ^–talk– 12:09, 26 July 2011 (UTC)[reply]

It's worth noting that the dfevelopment work noted above would make those warnings a thing of the past (that is, if they are what I think they are -- "This page contains insecure items"). - Jarry1250 ^{[Weasel? Discuss.]} 14:32, 26 July 2011 (UTC)[reply]

Google Chrome adds a bar to the top of each page saying "Insecure script has been blocked." and gives an option to load anyway. It's annoying, but not as annoying as Mozilla Firefox's dialogs. --Nathan2055^talk 16:47, 26 July 2011 (UTC)[reply]

I used the secure servers for a long time, but occasionally I'd have long delays in page loading and it'd drive me nuts, probably not because of the overhead of HTTPS, but because the secure server infrastructure hasn't been scaled up fully yet. Dcoetzee 22:38, 1 August 2011 (UTC)[reply]