La peur d’une planète WebKit

Le 5 mars 2013 —

Excellent article de John Siracusa, qui revient sur les plaintes de certaines personnes (Mozilla en tête) suite à l’annonce d’Opera d’utiliser WebKit.

Juste un détail qui m’a choqué et qui nuit un peu au raisonnement global :

Autant je méprisais Internet Explorer pour Windows, et ce qu’ont fait sa stagnation et sa dominance au Web, je ne pense pas que ce soit une analogie historique correcte pour Opera. WebKit n’est pas un navigateur Web.

Certes WebKit n’est pas un navigateur Web, mais Opera ne rejoint pas WebKit mais le projet Chromium et absorbe ainsi bien plus que la seule technologie WebKit.

Paul Irish en parle dans WebKit for Developers :

Cela veut dire que WebGL, Canvas, les formulaires HTML5, les implémentations graphiques 2D – tout ça sera commun sur Chrome et Opera maintenant.

Je ne suis pas contre cette idée d’adopter Chromium mais il y a quand même une grande différence à ne pas oublier. Et dans ce cas on se rapproche un peu plus de l’historique Internet Explorer, même si ce ne sont pas les parts de marché d’Opera qui vont faire trembler la planète Web.

Les employés de Yahoo! ne peuvent plus travailler à distance

Le 4 mars 2013 —

Dans un mémo publié il y a quelques jours par AllThingsD, Marissa Mayer annonce à ses employés qu’ils ne pourront plus travailler à distance et devront se rendre obligatoirement dans les bureaux de la société chaque jour.

Nous ne devons être qu’un Yahoo!, et cela commence par être physiquement tous ensemble.

Je suis un grand partisan du télétravail puisque moi-même je n’ai jamais connu de bureaux autres que celui qui est chez moi. À ce propos je vous conseille le prochain livre des fondateurs de 37Signals, REMOTE, qui parle de leur organisation de travail.

Cette annonce de Marissa Mayer a fait réagir Richard Branson :

Pour travailler efficacement avec d’autres personnes, vous devez vous faire confiance. L’essentiel est de faire confiance aux gens pour qu’ils finissent leur travail peu importe où ils sont, sans supervision.

En voulant critiquer la décision de Yahoo!, Branson explique précisément leur problème : Mayer n’a pas assez confiance dans cette immense maison de retraite pour sites Web qu’est devenue Yahoo!. Et le seul moyen de retrouver cette confiance est de se réunir pour repartir à zéro.

Chromebook Pixel et le syndrome du bras de gorille

Le 22 février 2013 —

À l’occasion de la sortie par Google de son Chromebook Pixel, je me permets de vous reparler d’un syndrome très connu des ergonomes, qui s’appelle le bras de gorille (Gorilla Arm Syndrom). Wired en parlait en 2010 lorsque Steve Jobs indiquait qu’Apple ne voulait pas s’engager sur ce terrain :

Apple Screen Multitouch

Nous avons fait des tonnes de test utilisateur, et il s’avère que ça ne fonctionne pas. Les surfaces tactiles ne peuvent pas être verticales. Cela vous donne une super démo, mais après une courte période vous commencez à fatiguer et après une longue période, vos bras n’en peuvent plus.

La fatigue musculaire n’est en effet pas à négliger, et les gens qui ont tenté d’utiliser un iPad à la place de leur ordinateur portable traditionnel le savent bien, comme un utilisateur de iSource, professeur, relatant son expérience :

Je dois dire qu’à la fin de la journée j’étais vraiment embêté par la lenteur que j’avais à atteindre l’écran pour sélectionner quelque chose plutôt que juste cliquer avec une souris.

D’ailleurs, sur la page de présentation du Chromebook Pixel, on peut voir cette étrange image qui présente l’utilisation de l’écran tactile de l’ordinateur portable avec un bras incliné n’importe comment, pour atténuer l’inconfort que cela représente, à la limite du Photoshop Disaster :

Image officielle

Avec un montage de votre serviteur, voilà ce que donnerait l’image si on utilisait l’écran comme indiqué sur l’image précédente (que je n’appellerai pas photo car il s’agit clairement d’un montage) :

Montage

Là c’est sûr qu’on n’aura pas mal au bras mais plutôt au poignet.

JS : Supprimer le lag des clics sur mobile avec FastClick

Le 21 février 2013 —

Vous avez sûrement déjà remarqué que lorsque vous visitez un site Web sur un appareil mobile, il y a un petit délai entre le moment où vous tapez sur un lien et le moment où le « clic » est pris en compte. C’est un temps généralement de 300 ms volontairement rajouté par le navigateur pour éviter les clics involontaires.

FT Labs, le laboratoire des nouvelles technologies du Financial Times, a sorti un script JavaScript très simple qui se nomme FastClick et qui supprime ce délai.

Une fois le script fastclick.js ajouté sur votre serveur, son utilisation est des plus aisées :

<script type='application/javascript' src='/path/to/fastclick.js'></script>
<script type='application/javascript'>
window.addEventListener('load', function() {
    new FastClick(document.body);
}, false);
</script>

Le résultat est immédiat et appliqué à tous les liens de votre page.

Si vous ne souhaitez pas que certains liens utilisent FastClick, ajoutez la classe needsclick à la balise <a> correspondante.

Ξ Le moment zéro de vérité

Le 20 février 2013 —

Un article de Allison McCann sur l’état de la publicité en ligne telle qu’on va la voir de plus en plus avec toutes les solutions de Native Advertising qui se développent, et les difficultés à venir pour l’utilisateur :

Les techniques de publicité ciblée et sociale employées par Google et Facebook ne sont pas forcément une mauvaise chose — une publicité plus pertinente et moins intrusive rend forcément nos vies plus simples. Mais pendant que Google et Facebook continuent d’affiner leur utilisation de deux plus grands ensembles de données sur le comportement humain, nos limitations cognitives peuvent devenir encore plus apparentes.

L’article revient entre autres sur les multiples façons d’afficher une publicité sur Facebook et Google et les différents équilibres à trouver pour que la publicité apparaisse au bon endroit et au bon moment.

Triste de voir que presque tous les commentaires de l’article se contentent de dire « installez AdBlock », mais j’imagine qu’il ne faut pas s’attendre à plus venant des lecteurs de BuzzFeed.

Un système de WebHooks GitHub avec PHP

Le 19 février 2013 —

Je viens d’ajouter sur GitHub un script PHP que j’ai créé pour gérer les commandes à exécuter après un push sur nos dépôts GitHub de Beta&Cie.

Le dépôt est ici : betacie/webhooks

Il nous permet de personnaliser les commandes à exécuter sans avoir à utiliser les hooks locaux de Git (qui ne sont pas modifiables par les développeurs, par définition), et de renvoyer éventuellement les retours des commandes pour du debug.

Les fichiers de configuration sont en YAML et ressemblent à ça :

emails:
  - john@acmewebsite.com
master:
  - /usr/local/bin/composer install
  - php ./app/console doctrine:schema:drop --force
  - php ./app/console doctrine:schema:update --force
  - php ./app/console doctrine:fixtures:load -n
  - php ./app/console assets:install web --symlink
  - php ./app/console assetic:dump --env=staging --no-debug
  - php ./app/console cache:clear --env=staging

J’utilise les bibliothèques PHP Spyc et SwiftMailer, via l’utilisation de Composer.

Non, Twitter ne filtrera pas votre timeline.

Le 18 février 2013 —

Apparemment un article d’un « consultant social media » français fait beaucoup parler de lui grâce à son titre accrocheur : Twitter : tous les Tweets ne seront plus visibles à partir du 20 Février !

C’est ainsi qu’à grands renforts de paragraphes sensationnalistes, une personne qui n’a jamais utilisé l’API de Twitter ni ne comprend son fonctionnement basique se permet de dire que nous allons nous voir censurés dans les 48 heures sans crier gare.

Ne vous faites pas influencer par les « consultants social media » qui font du linkbait pour attirer l’utilisateur moyen.

Évidemment, la réalité est toute autre, et il suffit de comprendre un peu l’anglais et lire le billet original qui s’appelle Introducing new metadata for Tweets.

Comme personne n’a l’air de vouloir en faire une traduction précise, la voici :

  • De nouvelles méta-données vont être ajoutées aux tweets retournés dans l’API : la langue du tweet et un filtre d’intérêt.
  • Le filtre d’intérêt ne sera disponible que pour l’API streaming, c’est à dire que l’API classique n’aura pas du tout cette donnée disponible.

Et comme personne n’a pris la peine d’en expliquer les implications correctement, les voici :

  • La recherche Twitter utilise déjà ces scores que Twitter calcule depuis très longtemps (ainsi que la langue détectée).
  • Ils n’étaient pas disponibles aux développeurs et encore moins dans les filtres de l’API Streaming, ce qui est maintenant le cas.
  • Il n’est jamais mentionné que cette nouvelle méta-donnée sera utilisée sur Twitter en dehors de la recherche.

Twitter n’est pas exempt de reproches et ce n’est pas moi qui vais les défendre.

Mais je pense que ce genre de paramètre va surtout être utilisé par de nouvelles applications comme les « murs Twitter » que l’on voit souvent dans les conférences. Pratique de n’afficher que les tweets les plus pertinents en les sélectionnant par leur langue et niveau d’intérêt, non ? Surtout que le calcul est en temps réel.

Il faut se rappeler que Twitter décourage la création et le développement de clients tiers, dernier exemple en date avec Tweetro et que l’on est à quelques mois de la suppression de l’API 1.0 actuelle.

Il est donc très important pour Twitter de montrer qu’il existe d’autre moyens d’utiliser l’API avec de nouveaux filtres et surtout de ne les proposer que dans l’API streaming, la seule API qui permet d’utiliser le flux Twitter global pour penser une autre utilisation que celle limitée par l’utilisateur actuellement identifié.

Ne vous faites pas avoir par le sensationnalisme bon marché des blogs high-tech français.

Posterous et le respect de l’utilisateur

Le 18 février 2013 —

Petite chronologie des évènements :

  • 22 février 2012 : Dans un e-mail à un utilisateur inquiet pour la pérennité du service, Posterous indique n’avoir aucune intention de vendre la société.
  • 12 mars 2012 : Twitter rachète Posterous, mais la société indique que le service restera en ligne et disponible sans aucun changement à prévoir et qu’une solution de sauvegarde des articles sera disponible « dans les semaines à venir ».
  • 27 décembre 2012 : Quelques « semaines à venir » plus tard, on peut enfin récupérer ses articles facilement depuis Posterous.
  • 21 janvier 2013 : La page d’inscription à Posterous donne une erreur 404, sans aucune explication sur le blog.
  • 15 février 2013 : Posterous annonce que le service va fermer le 30 avril, un an après avoir dit qu’il resterait en ligne quoiqu’il arrive.

Dommage pour les gens qui pensaient que les créateurs de Posterous étaient sincères.

En parlant de ça, un nouveau service, Posthaven, créé par des co-fondateurs de Posterous, s’engage à fournir pour $5 par mois un service de blogs qui restera en ligne pour toujours. Venant de leur part on peut leur faire confiance.

Ξ Première coupure de l’API Twitter 1.0 à prévoir

Le 15 février 2013 —

La première coupure de l’API 1.0 aura lieu le 5 mars 2013 de 18h à 19h heure française.

Une bonne occasion de vous forcer à changer quelques scripts pour être compatible avec l’API 1.1.

Javascript : Qu’est-ce que le XSSI et comment l’éviter

Le 14 février 2013 —

La beauté de l’AJAX vous permet de récupérer des données de manière asynchrone et de les afficher à vos visiteurs.

Mais qu’en est-il de la sécurité ?

Admettons que vous êtes un vilain pirate, et que vous souhaitez récupérer la liste des amis Facebook de votre cible. Facebook fait la plupart de ses requêtes avec de l’AJAX, pour notre exemple disons que l’URL AJAX pour récupérer les amis Facebook est :

https://www.facebook.com/ajax/getFriends.php

La sécurité par défaut des navigateurs nous empêche évidemment de faire directement une requête AJAX sur un domaine différent de celui du site qui est en train d’être visité. Si vous le tentez vous aurez une erreur du genre :

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

Heureusement car comme vos cookies sont toujours valides sur le domaine facebook.com, n’importe qui aurait accès à vos données en faisant de simples appels AJAX.

Cependant il existe un autre moyen pour une personne mal intentionnée de vous voler vos données JSON sans faire de requête AJAX. JavaScript a été créé pour être « si souple » qu’on peut même réécrire les fonctions de base. Ainsi vous pouvez tout à faire écrire :

function Object() {
    alert('Tiens tu viens de créer un objet !');
}

A priori rien de bien utile, sauf que dans le cas où l’on veut récupérer des données chargées côté client c’est un moyen très efficace. Au lieu de faire un appel AJAX, j’appelle le JSON comme un simple fichier JavaScript :

<script type="text/javascript" src="https://www.facebook.com/ajax/getFriends.php"></script>

Et si le JSON est censé me retourner un objet, la fonction que j’ai créée juste avant va être invoquée à la place de la fonction de base JavaScript. Ma fonction est innocente mais je vous laisse imaginer ce qu’on peut faire avec un this.

Cette technique est résumée par les initiales XSSI pour Cross-Site Script Inclusion.

Que faire pour éviter le XSSI ? Les services sensibles qui utilisent le JSON comme les services Google ou Facebook ont trouvé une astuce qui marche à tous les coups.

Comme le fichier JSON est chargé uniquement côté client, le pirate ne peut pas le modifier et compte sur le bon fonctionnement du moteur JavaScript pour lire le JSON comme un fichier JavaScript classique.

Donc, si le fichier JSON n’est pas du JavaScript correct impossible d’en récupérer ses données.

C’est pourquoi si vous regardez par exemple un fichier JSON renvoyé par Google Calendar, vous verrez en début de chaîne :

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],['remindOnRespondedEventsOnly','true'],['hideInvitations_remindOnRespondedEventsOnly','false_true'],['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]

Le while(1); entraînera une erreur Infinite Loop et le fichier JSON ne sera pas lu. D’autres sites rajoutent des caractères aléatoires pour entraîner une erreur de syntaxe, le principe est le même.

Comme le serveur d’origine fait une requête AJAX, il a accès à tout le contenu et peut facilement enlever ces premiers caractères pour parser le JSON ensuite, alors qu’un site malveillant ne le pourra jamais. Nous voilà protégés du XSSI.