The need for both #OpenID and #OAuth

Many words have been used on the merits of OpenID and OAuth. There are many misconceptions and many of those have everything to do with perspective. In order to get a better understanding I asked on the Wikitech mailinglist a use case for OAuth. The answer I received helps.

OpenID is an identity management system. It allows users to authenticate to one site using another site as their identity. A use case for this is, for example, using your Facebook account to log in to Wikipedia. This may be useful, as it would allow users to more easily register for Wikipedia

OAuth is a third-party authentication and authorization system that allows outside applications to do stuff on behalf of a user. The reason for this is because currently toolserver applications, etc. authenticate to Wikipedia using a plaintext username and password, which is extremely insecure for a number of reasons I will not elaborate on here.

When you read the answer, there are some observations to make. The most obvious is how do you assure that the software that is to use OAuth will be secure. Given the power of many Toolserver tools how do you make sure that only trusted people make use of the Toolserver functionality.

Enter OpenID, it does provide identity management. OpenID is able to provide more information than just "this is indeed the indicated identity" as part of the "OpenID Attribute Exchange". When the Wikimedia Foundation implements OpenID as a service, it will be possible to identify the users that have a "bot flag" on the user profile. 

As it is, the Toolserver tools are not necessarily secure. With OAuth it will become even less secure to run the software because it will be the software itself that includes the authorisation to run, never mind its configuration, never mind how it is used or by whom. When OpenID authenticates users, it becomes possible to ensure that only people with a bot flag can run Toolserver software on the production Wikimedia projects.

To make the use of the Toolserver tools secure, it is necessary to complement OAuth with OpenID. Oauth in isolation will make the Toolserver tools easier to use but it does not make them more secure to run.
Thanks,
      GerardM

#Wikimedia Commons, a relevant history

A long long time ago when Commons the wiki was created, it was only a dream. The dream was to have one place where all the images could be shared freely among all the Wikimedia Foundation projects.

It was a dream with really practical implications. At that time sharing a picture meant uploading the same picture to another wiki. At that time removing a picture because of a copyright violation was removing it on one wiki and perhaps on one or more wikis as well. This was an inexact process with inadequate results. The dream of Commons was to store a file once and use it on any wiki. The dream of Commons was that administrative procedures would be significantly enhanced because everything could be done once and everything could be done right.

Commons was created and it took several months before pictures on Commons were available on the WMF projects.

Today Commons fulfils much of this promise. Media files are shared on all the WMF projects, you can even enable this functionality on external MediaWiki wikis. Most of the duplicate files have been deleted and a single copy only exist on Commons. Nowadays the administrative procedures are much more effective. Everybody involved in Commons will agree it is not perfect, far from it but, Commons is thriving nonetheless.

This notion of adventure that existed in the Wikimedia Foundation seems dead. I am convinced it should be revived. There are some signs that it is possible ... in things like moving towards agile development ...

More later
Thanks,
     GerardM

a #threat assessment for #Wikipedia

The people who take care of mail send to Wikipedia are often informed that Wikipedia is not secure; "everybody can edit Wikipedia". This is actually intentional because Wikipedia is the encyclopaedia that everybody can edit. The real risk is when people do not recognise they are invited to edit. This is a genuine issue and it is something that receives a lot of attention.

When you consider security for Wikipedia, the people most at risk are its editors. There are several threats they are exposed to. Several of these are issues computer security can deal with.

• threat to the anonymity of a registered user
• threat to user credentials

When the potential threats are evaluated, it is important to realise that the severity of these threats is not obvious. It matters considerably where you reside, what your ethnicity is or what your belief system is. It is important to minimise any threats because once people no longer feel free to contribute it will damage the "neutral point of view" that gives Wikipedia much of its relevance.

With the implementation of SSH it has become considerably more difficult to learn what a person is doing when working on Wikipedia. This has been a real improvement. However, user credentials and particularly passwords are considered not really secure. Read for instance what Wired had to say about them. It is explained that improvements can only be expected when changing the infrastructure of online security. This will probably do a whole lot more good than lecturing people about how they should change their behaviour.

The question is if the WMF is open for such considerations. So far the talk is about "Nascar" ?!?! to me this sounds remarkably like bikeshedding and is very much beside the point.

Thanks,

     GerardM

#OpenID for the USERS of #Wikipedia, PLEASE

Again a discussion about the use of OpenID for the Wikimedia projects flared up. From my perspective the one perspective missing is the one of a computer user who is fed up with the failed security that is provided by passwords.

The problem is that systemmanagers only consider security in isolation. It is the solution that is to be adopted for their system or systems. Obviously in a perfect world, a user will have a separate password for each website or program. The world is not perfect and most people use one or a few passwords for everything. The world is not perfect and passwords of many big websites have been uncovered by hackers. Consequently many passwords used by Wikimedia contributors can easily be guessed by the bad guy who are in the know.

The problem with passwords for a user is that they are unmanageable. Too many systems and websites, too many interfaces seriously impact the security wherever passwords are implemented to provide security. It is theatre and the fool is the part you have to play.

OpenID provides a serious alternative. It allows for a single place with a single password that authenticates to any and all websites and services that accept security in this way.  It is a serious alternative as long as any and all accept other OpenID. It will be really welcome when the WMF considers security for its 456 M users. It is obvious that a large percentage also frequent websites like LinkedIn and solidify the argument to implement OpenID.
Thanks,
     Gerard

#Font support by #Google and #Wikimedia

The quality of the Amiri font has been recognised by the Wikimedia Foundation for some time; it has been provided in the Web Fonts extensionn for some time and recently in an other bit of "read the whole article to get to the good news" it became part of a Wikimedia supported jQuery library for web fonts.

Google has also recognised the Amiri font; they make Amiri available through their "early access" program. Google supports multiple (freely licensed) Arabic fonts as web fonts. The biggest difference for me between the two programs is that the WMF library has your server provide the fonts while the Google offering has the fonts provided through the Google infrastructure.

Both Google and WMF support fonts for many scripts. The question is what they will do when the font has technical requirements that are more than usual.

Recently the Tuladha Jejeg font for the Javanese script was given a free license and the Wikimedia Foundation will assess if they will include it in their Web fontd extension. There may be a technical problem; it makes use of the SIL Graphite technology. The question is to what extend do browsers support this technology.

When Google is serious in supporting the rare scripts, the opportunity to support the Javanese script through the Tuladha Jejeg font may be reason enough to put some extra effort in enabling support for SIL Graphite.

<grin> One may hope for Google to do more good, we know they can</grin> <seriously> For the WMF there is hardly another option when they are to support Javanese </seriously>
Thanks,
      GerardM

#Internationalisation is more than conversion of numbers

A friend read my last blogpost and pointed me to a recent presentation about the current best of breed internationalisation for JavaScript. He had been testing the new jQuery internationalisation library published by the Wikimedia Foundation and was astonished that the one thing "everybody" does was missing.

His question was: "where is the conversion of numbers and dates?". Obviously MediaWiki "does" the conversion of numbers and dates, it is just not part of the library that enables what is most crucial for us in Internationalisation; the translation of the messages in more than 280+ languages.

My friend Andrew was thinking of extending the library with the conversion of numbers and dates. It makes sense to have them included however, forking this really new library at this early time is "evilish". Talking to Santhosh, the developer of this library is the thing to do. It is, because in this way any future improvements in the existing 280+ languages or the missing 6000+ languages will be shared by anyone who updates to this library.

YES, I know jQuery is Java and not JavaScript. But I also know that my friends at the Wikimedia Foundation support the localisation of their JavaScript.
Thanks,
      GerardM

#jQuery and #Internationalisation of YOUR application

There has been a lot of good news about jQuery this week.

• The Khan academy announced that they are providing training for computer science and they started with jQuery
• A Webmonkey report states that jQuery is installed on half the internet websites
• Hidden in a Wikimedia blogpost is the news of a library to provide a full i18n framework that supports parameter replacements and grammar-, plural-, and gender-dependent translations.

The news of this jquery.i18n library is wonderful news. As it is the same software as used for the internationalisation of MediaWiki, it represents the current knowledge of the 280+ languages that have their Wikipedia.

When your software is open source and when you adopt this library to implement internationalisation, you are that much closer to make use of that wonderful community at translatewiki.net. They are already doing a great job for many applications, why not yours?

Thanks,

      GerardM

Learning to type #Arabic; #Wikisource exercises

The one skill that makes it easy to use a computer is typing with ten fingers. Particularly when you learn a new script, you need to learn to type again. Learning this skill well means exercises.

I remember when I learned to type on a typing machine that I hated the futility of these exercises. Now that I need the skills to learn Arabic, I can think of exercises that are of use to everyone.

The WIKISOURCE for the Arabic language.

All Wikisources have the ProofreadPage extension installed. So all that is needed to tap in the vast pool of people that are learning to type Arabic is having pages ready using this tool.

My skill in Arabic is such that I can not easily find these. When I have, the Arabic Wikisource has its first volunteer that will exercise and do good at the same time.
Thanks,
     GerardM