Mise à jour de la base de données, veuillez patienter...

Voilà. Le W3C continue sa poussée en intégrant officiellement le draft de norme sur les DRM dans le groupe de travail HTML. Le draft s'appelle EME (Encrypted Media Extensions): http://www.w3.org/TR/encrypted-media/. C'est une API permettant de standardiser l'interfaçage des navigateurs et des systèmes de DRM. Dans la pratique, vous ne pourrez pas enregistrer les vidéos. Le navigateur passera le contenu chiffré au module DRM qui se chargera de décoder les trames.

Histoire de bien foutre le bordel: Notez que ce standard n'impose pas un système de DRM particulier, mais juste une API. Ce qui veut dire que chacun va se fendre de son petit système de DRM, qui sera différent d'un vendeur à l'autre, d'un système d’exploitation à l'autre, d'un site à l'autre, d'un navigateur à l'autre. De quoi - en plus d'être emmerdé par les DRM - morceler un peu plus le web. Vous trouviez que c'était déjà le bordel entre MPEG4, WebM/VP8, OGG/Theora, MP3 et Vorbis ? Vous n'avez encore rien vu. Le plus beau, c'est que ça n'empêchera même pas le piratage des œuvres. (C'est pas comme si la TOTALITÉ des DRM existants avaient été cassés, hein ?).

Certes, cette norme est uniquement orientée vidéo, mais après la vidéo, que croyez-vous qu'il va se passer ? Il y a plein de monde qui attend à la porte pour avoir sa petite couette confortable de DRM: Les photographes pour empêcher la "copie" de leurs photos, les maisons de disque pour restreindre l'écoute, les agences de presse et maisons d'édition pour empêcher le vilain copier-coller, les webmasters neuneus pour "protéger" leur code HTML/javascript.

Vous croyez que je plaisante concernant le code HTML et javascript ? Pas du tout: Il y a déjà un groupe de travail au W3C sur le sujet. Imaginez un monde où votre navigateur ne va plus exclusivement vous obéir, mais va - sur certaines de ses fonctions - obéir à des tiers. Imaginez le jour où vous ne pourrez même plus enregistrer une image ou voir le code source d'une page HTML. (Si ça se réalise, je présume que ces restrictions concerneront également les extensions pour navigateurs, ce qui les empêcherait d'accéder au contenu de la page... oh regardez, POUF, plus de vilain AdBlockPlus qui vient nous arracher le pain de la bouche, la vie est bêêêêêllle !). Les membres du W3C sont déjà en train d'y réfléchir.

Voilà comment je vois le web de demain: Les géants du Minitel 2.0 proposeront ça dans leurs services (par exemple une option dans YouTube pour empêcher l'enregistrement des vidéos, ou chez Flickr pour empêcher la copie des photos (spaceballs !⁽¹⁾). Et je présume que si votre navigateur n'est pas EME-compliant, vous ne pourrez pas lire ces vidéos ou voir ces photos. Soit vous acceptez les DRM, soit une partie du web ne vous sera plus accessible. Et comme ça sera W3C-compliant, ils pourront vous jeter avec dédain avec la bonne conscience d'avoir respecté les normes officielles du ouèbe. En intégrant EME au sein du groupe de travail HTML, c'est la voie dans laquelle s'est engagé le W3C.

Le W3C n’œuvre plus exclusivement pour un web ouvert. C'est terminé. Je pense que l'ouverture du web, l'interopérabilité, est condamnée à moyen terme. Vous vous demandez comment, comment le W3C a pu accepter ça ? C'est simple: regardez la liste de ses membres.
Bien plus criant: Regardez qui sont les éditeurs de cette nouvelle norme du W3C: David Dorwin (Google), Adrian Bateman (Microsoft), Mark Watson (Netflix). Vous leur faites vraiment confiance pour œuvrer pour le bien de tous ?

C'est triste, mais il est temps de prendre du recul par rapport au W3C. Quand il était encore jeune, internet n'était pas un tel enjeu économique et le W3C remplissait alors bien son rôle. Maintenant qu'internet est un lieu où se brassent des sommes absolument colossales, les membres du W3C ont des intérêts commerciaux bien trop importants et ils ne se gênent plus pour pousser le W3C dans la direction qui arrange leur business. En même temps, à quoi je m'attendais, franchement ?

Vous croyez que je vois tout en noir ? L'avenir nous le dira. Si j'ai raison, alors le web du futur pue des pieds. (Voilà, ça c'était pour les petits mots grivois de circonstance.)

Mise à jour 15 janvier 2013: Complément: La MPAA rejoint le W3C. Les spécifications qui ont abouti à la norme EME sont secrètes.

^{(1) L'allusion n'est pas facile à comprendre si vous n'avez jamais plongé dans le code HTML des pages de Flickr.}

Votre slogan est «Partager», mais vous ne voulez pas vraiment qu'on partage. Vous voulez nous garder à l'intérieur de votre cage dorée. C'est pour cela que vous avez passé votre temps à retirer de vos pages les liens vers les flux RSS, les cachant au fin-fond de votre site, ou les supprimant purement et simplement, en les remplaçant par des API propriétaires rabougries ou démentielles. ET BIEN MERDE.

Vous n'êtes pas "social" quand vous entravez le partage en retirant RSS. Vous êtes heureux de voir vos utilisateurs créer du contenu pour votre écosystème, mais vous ne voulez pas voir ce contenu sortir de chez vous - un contenu qui ne vous appartient même pas. Google Takeout est juste de la poudre aux yeux. Nous voulons que les données circulent, nous voulons RSS.

Nous voulons partager avec nos amis, en utilisant des protocoles ouverts: RSS, XMPP, peu importe. Parce que personne ne veut qu'on lui fourgue de force votre service avec votre application utilisant votre API. Les amis devraient pouvoir choisir les logiciels et services qu'ils veulent.

Nous sommes en train de reconstruire les ponts que vous avez volontairement détruits.

Sortez-vous les doigts du cul: Remettez RSS en place.

(Le même article en anglais là.)

Your catchword is «share», but you don't want us to share. You want to keep us within your walled gardens. That's why you've been removing RSS links from webpages, hiding them deep on your website, or removed RSS entirely, replacing it with crippled or demented proprietary API. FUCK YOU.

You're not social when you hamper sharing by removing RSS. You're happy to have customers create content for your ecosystem, but you don't want this content out - a content you do not even own. Google Takeout is just a gimmick. We want our data to flow, we want RSS.

We want to share with friends, using open protocols: RSS, XMPP, whatever. Because no one wants to have your service with your applications using your API forced-feeded to them. Friends must be free to choose whatever software and service they want.

We are rebuilding bridges your have wilfully destroyed.

Get your shit together: Put RSS back in.

(Same article in French here.)

Je suis issu d'une époque pré-ADSL où le top de la vitesse était le modem 56K. Soit environ 5 kilo-octets par seconde. Forcément, ça laisse des traces, comme cette obsession maladive d'optimiser les images. Je ne parlerai pas ici d'optimisation de la taille de vos fichiers JPEG (que ce soit en diminuant la résolution ou en jouant avec le pourcentage de qualité JPEG ; Il y a des outils pour ça). Je vais parler ici d'astuces pour donner l'impression que la page se charge plus vite.

L'astuce du pauvre

A l'époque des modems RTC, il était courant pour les pages web d'ajouter un attribut "lowsrc" aux balises images. L'attribut lowsrc est identique à src, mais pointe sur une image très basse résolution (généralement une image de moins de 10 ko). Exemple:

⋖img lowsrc="./media/9fdd3c24.chaton-low.jpg" data-original-source="http://sebsauvage.net/rhaa/chaton-low.jpg" src="./media/9bbfc6ad.chaton.jpg" data-original-source="http://sebsauvage.net/rhaa/chaton.jpg" width="1024" height="768">

Le navigateur ayant chargé rapidement la petite image spécifiée dans lowsrc, il affichait immédiatement la page, même si les images pleine résolution n'avaient même pas commencé à se charger (Bien sûr, n'oubliez jamais d'indiquer en complément width et height, hein ?). Certes cela faisait au final plus de données à télécharger, mais la page s'affichait malgré tout plus vite.

C'est tout l'intérêt de la vitesse perceptive par rapport à la vitesse effective. C'est purement psychologique, et vous voulez que l'internaute ai l'impression que la page se charge vite.

De nos jours, ce n'est plus trop utilisé. D'abord parce qu'on a des débits de folie, mais aussi parce qu'on a désormais le JPEG progressif.

L'astuce du riche

La particularité du JPEG progressif est que l'image est entièrement affichable même si on a reçu que 3% du fichier. L'image s'affiche alors immédiatement en entier, et se raffine peu à peu.

Message subliminal:

CONVERTISSEZ TOUS VOS JPEG EN PROGRESSIF S'ILS DOIVENT ÊTRE PUBLIÉS DANS UNE PAGE WEB.
Non vraiment j'insiste. Le JPEG progressif c'est bon, mangez-en. Dès que votre JPEG dépasse 10 ko, convertissez-le en progressif. Il n'y a aucune perte de qualité et le fichier sera plus petit (dans la majorité des cas).

Voici ce que donne le chargement d'un JPEG standard (non-progressif):

Et la même chose en JPEG progressif:

Du coup, avec toutes les images en JPEG progressif, le navigateur peut très rapidement calculer et afficher la page, même si votre joli JPEG de 2 Mo n'est pas encore chargé en entier. Toutes vos pages donneront l'impression de se charger plus vite, et ce, sans manipulation supplémentaire dans votre page (ni au niveau du code html, ni au niveau du javascript).

Le second effet kiss-cool, c'est que pour une même qualité JPEG, le progressif est généralement plus petit (Dans notre cas: 183 260 octets pour le standard, 176 202 octets pour le progressif, pour une qualité d'image strictement identique).

Le troisième effet kiss-cool que j'ai constaté (corrigez-moi si je me trompe), c'est que certaines LightBox javascript semblent obtenir plus rapidement la taille de l'image, et affichent donc plus rapidement les images dans les galeries (comme la mienne). C'est tout bénef.

Et là, c'est le drame...

Tout va bien ? Il y a encore un petit soucis. Rien n'est plus agréable que mettre un bon gros JPEG en fond d'une page web avec un background: url(...), n'est-ce pas ?

Mais là, mauvaise surprise: Les navigateurs se foutent royalement que votre JPEG soit progressif: Ils ne l'afficheront que lorsqu'il sera entièrement chargé (sauf Chrome). Du coup votre page va rester avec un fond noir pendant plusieurs secondes. Même si ce n'est pas sale, c'est assez laid. Mais on peut ruser.

En fait, dans background il est possible de spécifier plusieurs images. Par exemple, j'ai fait:

background: url("background.jpg") no-repeat, url("background-fast.jpg") no-repeat;

• background-fast.jpg est un petit jpeg en 640x480 de 20 ko. Le chargement sera quasi-immédiat.
• background.jpg est l'image pleine résolution: 1920x1080 et 545 ko.

Les navigateurs chargeront en premier les images spécifiées en fin de ligne (background-fast.jpg) et chargeront ensuite vers la gauche (background.jpg).

Le résultat ? L'image de fond semble s'afficher immédiatement, ce qui visuellement est bien moins perturbant. Vous pouvez voir le résultat dans cette page (Cliquez sur le bouton rechargement de page de votre navigateur en maintenant la touche MAJ enfoncée pour forcer le re-chargement de tous les éléments de la page). C'est quand même bien plus agréable.

Pensez à ceux qui ont des débits merdiques, et n'oubliez jamais:

Faites du JPEG progressif !

Vous pouvez convertir vos JPEG existants en progressif sans perdre en qualité.

Hello.

Hier j'étais à Paris. Ça a été l'occasion de rencontrer certains d'entre vous (Kevin Merigot, Hoper et sa femme, Tommy et tous les autres) . Ça a été vraiment très sympa :-) J'avoue que le petit comité d'accueil à la gare (avec les pancartes) était intimidant. Nous étions 15 au restaurant et - ah ! - je crois que Kevin aura une photo de moi à vous montrer ;o) Il a fait très chaud, et heureusement que le serveur a bien voulu nous remettre en salle parce que la terrasse était tout simplement insupportable avec les travaux juste à côté. Ça fait plaisir de pouvoir mettre un visage sur certains noms. Merci à tous. Nous avons squatté le restaurant presque jusqu'à 17 heures, à discuter de tout et de rien.

Je me suis éclipsé pour me rendre dans les locaux de Mozilla France, où j'ai été invité par FING à une discussion sur la réappropriation des données personnelles, avec des gens de chez Mozilla, de la CNIL, de CozyCloud, de Privowny et plein d'autres personnes intéressantes. J'ai enfin rencontré Stéphane Bortzmeyer (avec son T-Shirt Framasoft :).

Je ne peux pas vous rapporter la totalité de la discussion, alors voici quelques points clés:

FING a lancé une initiative afin que les internautes se ré-approprient leurs données personnelles: téléphonie, assurance, supermarchés et autres. Le but est de convaincre les acteurs de privés de donner aux internautes un accès brut à toutes les données les concernant, ce qui permettra par la suite aux internautes de les exploiter eux-même pour de nouvelles applications.

Il y a encore beaucoup de problèmes à résoudre: comment convaincre les acteurs privés et publiques ? Sous quelles conditions récupérer ces données ? (sachant que pour la plupart ce sont des opérations très manuelles lorsqu'elles sont demandées). Comment authentifier les utilisateurs ? (l'adresse email ou postale ne suffit pas). Sous quel format récupérer ces données ? (utiliser des standards existants ou utiliser le format brut fourni par l'entreprise ? Transformer les données ?). Comment les exploiter ? (quelles applications ? comment y accéder ? comment les déployer ?)

CozyCloud apporte un début de réponse: Ils proposent un cloud personnel - un silo de données personnel - où vous pourrez stocker toutes ces informations, et offre une plateforme qui permet de développer des applications pour exploiter ces données. Une sorte de Google AppEngine, mais ouvert et hébergé où vous le voulez. Il gère actuellement diverses applications: mail, contacts, agenda, notes, photos, flux RSS, ToDo, Bookmarks, nirc. (Actuellement les sources sont sur GitHub et tournent sous NodeJS. Pour simplifier l'installation, ils fourniront à terme des machines virtuelles.). Et vous pouvez développer de nouvelles applications pour CozyCloud, dans le langage de votre choix. L'intérêt de CozyCloud est que ces applications collaborent sur votre silo de données personnel qui peut être hébergé chez vous. Bien sûr cela pose aussi des questions sur le modèle de sécurité des applications. Mais l'ensemble est assez bien pensé.

Histoire d'avoir de la matière FING lancera une opération avec la poignée d'entreprises qui ont accepté de se prêter au jeu et 300 personnes volontaire au mois d'août, afin de voir un peu ce qui marche et qui ne marche pas, et comment tout le monde ressent l'expérience. Des concours seront probablement lancés pour inciter à la création d'applications innovantes.

Oui, tout cela est un peu effrayant: Voir toutes vos données, accumulées depuis tant d'années par les entreprises avec qui vous avez eu affaire doit donner le vertige. Mais c'est justement un bon moyen d'en reprendre le contrôle et de les exploiter au mieux, pour votre plus grand bénéfice (Imaginez un exemple tout simple: Surveiller l'augmentation des prix de votre supermarché habituel, et comparer avec d'autres). Mais les applications sont encore à imaginer.

Il se pourrait même que l'accès à vos données personnelles devienne un enjeu. Imaginez: Entre une entreprise qui vous donne le plein accès à toutes les données qu'elle stock sur vous et une autre qui refuse, à laquelle ferez-vous le plus confiance ? Vous avez deviné: Cela pourrait devenir un argument de vente majeur pour les entreprises, qui année après année perdent la confiance de leurs clients (malgré les trombes de cartes fidélité). (Pourquoi croyez-vous que Google a créé Google Takeout ?)

Il y a encore beaucoup de questions, beaucoup de problèmes à résoudre et d'expériences à réaliser avant de concrétiser tout cela, mais c'est prometteur.

Privowny de son côté propose une extension Firefox pour protéger votre vie privée: Non seulement il bloque les traqueurs (à l'image de Ghostery dont je vous rebat les oreilles), mais en prime il permet de tracer quelles information vous avez donnée à qui: numéro de téléphone, adresse postale, etc. Vous voulez savoir à quels sites vous avez donné votre numéro de téléphone ? Privowni vous affichera la liste (bien sûr il n'enregistrera qu'à partir du moment où il est installé).

En prime, il vous affiche les centres d'intérêt que les réseaux publicitaires ont identifié chez vous, et propose aussi un service d'email jetable permettant de ne pas avoir à donner son adresse email réelle (et prochainement aussi des numéros de téléphone jetables, pour éviter d'avoir à donner son véritable numéro de téléphone).

Toutes ces données sont chiffrées côté client avec un système clé publique/clé privée. Privowny ne peut donc pas voir le contenu des données chiffrées. Vous pouvez à tout moment choisir de chiffrer ou non une donnée, ou l'effacer. Vous pouvez également à tout moment exporter la totalité de vos données au format jSon et tout effacer chez Privowny. Côté business model, Privowny envisage des services payants supplémentaires (modèle freemium). Un exemple ? Si vous voulez effacer ou rectifier une donnée vous concernant, Privowny se chargera pour vous de faire la démarche auprès de l'entreprise. Privowny réfléchit également à l'ouverture des sources de son service.

Il sera intéressant de voir comment tout cela évolue.

Quant aux locaux de Mozilla France, c'est la grande classe.