Depuis plusieurs années qu’on nous en rebache les oreilles, on commence à avoir l’habitude de ce fameux “Web 2.0″. Si l’auteur de la formule originale doit grandement se féliciter (ou se maudire de n’avoir pas su la faire breveter, c’est au choix), force est de constater que le terme est assez creux, et le plus souvent utilisé à mauvais escient. Que n’ai-je pas tenté d’expliquer à tel ou tel technophile exalté que non, le glisser-déposer n’était pas la trouvaille de l’année, même dans un site web.
En revanche, il y a différentes facettes du Web qui tendent à vraiment innover. La première, qui joue les arlésiennes depuis bientôt dix ans, c’est le Web sémantique. En gros, c’est un ensemble de technologies qui permet de rendre nos merveilleux contenus (photos de vacances, éloge des Bains-Douches, opinion puérile et mal épaulée sur l’interdiction de fumer dans les restaurants, …) un peu moins obscurs pour nos ordinateurs. En gros, car je n’ai pas l’intention de rentrer davantage dans le détail pour le moment. D’autant que l’autre partie de ce “Web 2.5alpha13rc2″ s’appuie ici et là sur les trouvailles du web sémantique.
Cet autre, c’est le “Web social”. Personnifié par Facebook, Twitter et deli.cio.us (pour n’en nommer que quelques-uns), sa caractéristique numéro un est de mettre les gens en relation. Ainsi, si je peux stocker mes marque-pages sur le site de deli.cio.us, je peux aussi voir ceux de mes amis, et eux voir les miens. Bien évidemment, des mécanismes sont prévus pour nous permettre de contrôler ce à quoi nos pairs accèdent.
Sa caractéristique numéro deux, et c’est malheureux (bien que compréhensible), c’est d’essayer de nous rendre captif. Forcément, ces services sont gratuits et vivent essentiellement de la publicité - et particulièrement de publicité ciblée. Il faut bien admettre que pour un bijoutier, savoir que sa réclame sera faite auprès de monsieur dans la semaine qui précède l’anniversaire de madame, ça n’a pas de prix. Or, un site comme Facebook sait précisément tout cela : les relations entre les gens (qui est la madame de monsieur, et vice et versa) et une partie de leurs informations personnelles (dates d’anniversaires, notamment). À partir du moment où les utilisateurs sont consentants, on voit mal qui pourrait y trouver à redire.
Il y a - en fait - plein de choses à y redire. On s’en serait douté. D’une part, on a la nette impression que certains utilisateurs ne sont consentants que parce que mal informés. Quand on voit que la procédure d’inscription à Facebook se conclut par un message du genre “confiez-nous vos noms d’utilisateur et mots de passe de messagerie, et nous ajouterons automatiquement vos contacts”, et quand en plus on sait que des gens répondent à cette injonction par l’affirmative, on se gratte la tête. Et je n’ai pas rêvé : pendant ma phase “anti-Facebook” avancée, des gens dont j’ai perdu toute trace (si ce n’est qu’ils traînent encore au fond d’une vieille liste de contacts MSN) m’ont envoyé des invitations à me joindre à eux sur le Livre. Deeply shocking.
Pour rappel (mais ce genre de rappel ne semble jamais vouloir devenir inutile, hélas) : on ne donne pas ses identifiants. Jamais. À personne. D’abord parce qu’on ne sait jamais vraiment ce que la personne pourrait faire avec le compte concerné. Ensuite et surtout parce que - et on est tous plus ou moins dans ce cas - les mots de passes se recyclent, développement durable oblige. Qui prend la peine d’avoir un mot de passe différent pour chacun des sites auxquels il adhère? Quel intérêt à choisir un mot de passe extrèmement compliqué si vous le donnez au monde entier?
Car ne rêvons pas : sauf cas très particuliers, rien ne vous prémunit contre le fait qu’un site garde une copie “en clair” de votre mot de passe. Et on ne parle même pas des risques d’une interception par un tiers commodément installé entre vous et votre interlocuteur. Parmi les cas particuliers qui limitent la casse, il faut citer - outre les plus célèbres exemple de cryptographie à clé publique - le cas OpenID. Celui-ci se base sur une idée assez ancienne : l’authentification centralisée. Je m’authentifie à un seul interlocuteur, et tous les gens qui auront besoin de vérifier mon identité viendront d’eux-même la lui demander.
Il y a quelques années, Microsoft avait fait couler beaucoup d’encre éléctronique avec sa solution Passport. À partir d’un unique compte Hotmail, vous pouviez vous authentifier auprès de tous les services compatibles Passport. C’est-à-dire peu. Pendant ce temps, la concurrence avait eu la même idée. Par exemple, Google a fait en sorte que votre authentification sur Google Mail se propage aux autres services de leur suite. Bien évidemment, un compte Google n’est pas un compte Passport valide, et réciproquement. On était en train d’assister à la revanche de la balkanisation du Web : la persianisation de l’authentification.
Fort heureusement, une solution est en train de percer : OpenID. Une solution “neutre”, ce qui dans le cadre du conflit larvé pour le contrôle des bases d’utilisateurs est un énorme avantage. N’importe qui (d’un peu calé quand même) peut proposer un service d’authentification. Et il existe des gens qui ont mis en place de tels services gracieusement. Donc n’importe qui peut accéder à un tel service. Et n’importe quel webmaster peut décider de reconnaître les comptes OpenID. Ainsi, toute personne munie d’un tel compte pourra l’utiliser plutôt que de spécifier un énième couple “login/mot de passe”.
J’entends déjà ceux qui me suivent depuis le premier paragraphe (et particulièrement le maniaque qui était encore éveillé au moment du quatrième) objecter qu’un tel système est dépendant de ses “fournisseurs”. En effet, si myOpenID - un fournisseur en vogue - décide de fermer boutique ou de changer ses conditions d’utilisation, ses utilisateurs sont dans la panade. Mais ce n’est pas une fatalité. D’abord, on l’a vu, parce que n’importe qui peut monter un fournisseur d’authentification, s’il n’a pas confiance dans ceux du marché. Cela n’est pas très compliqué, et peut se limiter à mettre en ligne quelques fichiers PHP.
Bon ok, cela peut s’avérer compliqué, surtout si l’on n’a pas la moindre idée de ce dont je parle. Pour ceux-là, il a été prévu un système encore plus simple : la délégation. Les identifiants OpenID ne sont ni plus ni moins que des URLs. Par exemple, je pourrais me présenter comme http://tartempion.net. Pas très sexy, mais extrèment pratique parce que ça permet d’utiliser de nombreuses ruses propres à ces étranges machins pleins d’obliques qu’on utilise tous les jours. Et notamment, ça permet de mettre en place des redirections. Si j’héberge mon site familial sur http://tartempion.net, mais que mon fournisseur OpenID est myopenid.com, je peux indiquer au premier que si “on me demande” je suis chez ce dernier. Dans le pire des cas, il s’agit de rajouter deux lignes (spécifiques à OpenID) dans un des fichiers de mon site. Dans le meilleur des cas, le concepteur de mon site à prévu et le coup et j’ai juste un champ à renseigner. Et ainsi, si je souhaite passer de myOpenID à Vidoo, il me suffira de modifier mon site pour que tous mes comptes continuent à fonctionner.
Ceci est bel et bon, mais ne nous voilons pas la face : le système est efficace, mais jeune. La triste conséquence en est que - selon les mauvaises langues - il y a plus de fournisseurs OpenID que de sites qui permettent d’utiliser un OpenID. C’est probablement éxagéré, mais il est vrai plusieurs sites “à gros traffic” n’ont toujours pas passé le cap : Facebook, Google, Hotmail, … Nul doute qu’il ne s’agit là qu’une question de masse critique et de temps.
L’autre gros écueil d’OpenID, c’est que s’il centralise l’authentification, il centralise aussi tous ses problèmes. Le fournisseur OpenID - qui est libre d’utiliser la méthode qu’il souhaite pour vérifier l’identité de ses utilisateurs - a une grosse responsabilité. Si quelqu’un usurpe votre OpenID, il est tout puissant. Ici, deux axes de réponse : profiter du fait que l’authentification est unique (par session) pour la rendre aussi solide que contraingnante. Toutes les méthodes qu’on rechigne à utiliser pour ne pas agacer l’utilisateur à longueur de journée, on peut envisager de les employer ici : il ne devrait pas y être soumis trop souvent.
L’autre grande parade aux usurpations, c’est l’idée bien connue qu’il ne faut pas mettre tous ses oeufs dans le même panier. De même qu’on recommande, faute d’avoir un mot de passe par site, d’en avoir un par groupe de site - groupes qu’on construit en fonction de la confiance qu’on porte aux sites. Ainsi, je ne vais clairement pas utiliser le même mot de passe pour ma banque et pour le blog d’un copain. C’est pareil pour OpenID : les services critiques et les autres ne devraient pas partager la même authentification, sauf à avoir une confiance absolue dans le fournisseur (ce qui n’est vraiment envisageable que si c’est soi-même, diront certains).
Enfin, une lacune d’OpenID, c’est son incapacité à gérer l’autorisation. Si il sait bien répondre “tel utilisateur est authentifié”, il est incapable de dire si cet utilisateur a des droits particuliers. Ceci oblige les sites à garder une gestion d’utilisateurs, pour pouvoir faire correspondre les OpenID à des profils d’utilisation. En l’occurence, il ne s’agit nullement d’un oubli ou d’une limite, mais d’une autre problématique qui a vocation à être traîtée par un outil complémentaire : OAuth.
Web social & libre