Microsoft : vers une version web de Skype [06.08.2012 18:02 - AZ]
Microsoft a présenté au W3C CU-RTC-Web, sa proposition pour WebRTC, un système de communication en temps réel (audio / vidéo) sans plug-in. Une version différente de celle de Google qui ouvre la voie à une version web de Skype.

Matthew Kaufman, qui a dirigé les travaux autour de cette proposition, explique à GigaOM que Microsoft a pris son temps pour éviter tout problème majeur. Mozilla et Opera avaient par exemple été obligés de désactiver WebSockets de leurs navigateurs après la découverte d'une faille de sécurité dans ce protocole de communication entre serveur et client. Une politique à l'opposée de celle de Google, qui a déjà inclus des briques de WebRTC dans la version publique de Chrome.
La proposition de Microsoft a comme particularité de ne pas être liée à un codec, ce qui n'est en soit pas une surprise. La firme de Redmond avait en effet indiqué ne vouloir prendre en charge aucun codec vidéo open-source dans Windows 8 tant qu'un standard clair ne se dégageait pas face au codec propriétaire H.264 (qu'elle soutient, comme Apple d'ailleurs). Les propositions de Google et de Mozilla utilisent le codec libre VP8. L'approche de Microsoft a l'avantage de la flexibilité : elle permet au développeur de choisir son codec en fonction de son cahier des charges.
Quoi qu'il en soit, la proposition de Microsoft est un signe en faveur d'une version web de Skype. Matthew Kaufman est connu comme un spécialiste du streaming vidéo HTTP certes, mais aussi comme un ancien de Skype (et un des co-inventeurs du hoax du monoxyde de dihydrogène). L'utilisation de WebRTC permettrait à Skype de fonctionner sans plug-in ni client « lourd », simplement dans le navigateur.
Ces sociétés assurent que ce standard, Encrypted Media Extensions, n'est pas un système de DRM : il s'agit pourtant d'un système très clair de protection anti-copie avec un module CDM de déchiffrement du contenu exécuté non pas par le navigateur, mais au niveau du firmware ou par une puce. Ce brouillon du standard prévoit aussi un nouvel ensemble d'API HTMLMediaElement et JavaScript pour la gestion de l'audio et de la vidéo protégées en HTML5.
Cette proposition génère de nombreux débats au sein du W3C, aussi bien pour des raisons éthiques (le rôle du W3C ne serait pas de définir un standard privateur), que techniques (ces protections seraient illusoires et risqueraient d'entraîner un jeu du chat et de la souris défavorable à l'évolution à long terme du Web).
Apple intègre de manière récurrente de nouvelles fonctionnalités de mise en page pour les CSS, avant de les proposer au W3C pour standardisation, ce qui peut amener de nombreuses modifications (comme ce fut notamment le cas pour Webkit-gradient). Les sites web qui embrassent avec trop de précipitation ces nouvelles fonctions poussent les autres navigateurs à intégrer ces fonctions à la hussarde, soit en se faisant passer pour Webkit, soit en intégrant les fonctions CSS en question sous la dénomination de webkit. Ces deux approches ne sont pas sans poser de problèmes, d'autant qu'elles participent à asseoir encore plus l'hégémonie de Webkit en engageant un cercle vicieux.
Le problème ne vient pas tant de Webkit ni même de sa popularité que du manque d'efforts des créateurs de sites, qui se contentent de la seule compatibilité avec Webkit pour les terminaux mobiles, étant donné qu'il représente de loin la plus large population (il est intégré à iOS, Android et Symbian comme moteur de rendu HTML par défaut). Le problème rappelle les affres d'Internet Explorer 6, et ça n'est d'ailleurs pas la première fois que ce parallèle est fait (lire Safari Mobile, l'IE 6 des temps modernes ?).
Il faut toutefois le nuancer en rappelant que contrairement à IE6, Webkit n'est pas propriétaire et fermé, et que ses nouvelles fonctions sont proposées au W3C pour standardisation. Il n'en reste pas moins que les pratiques de certains sites, qui ne proposent pas de fonction de recours pour les autres navigateurs, et que certains navigateurs, qui n'implémentent pas ces fonctions proprement, pourront amener de nombreux problèmes à l'avenir et rompre la compatibilité avec les évolutions futures du standard CSS, tout en bloquant le W3C dans ses latitudes.
Afin d'éviter pareil écueil, il est donc primordial de sensibiliser chacun à ce problème : les développeurs de navigateurs se retrouvent actuellement contraints de procéder à ces implémentations impropres dans la mesure où la majorité des sites mobiles ne supportent que Webkit. Il faut donc rétablir la balance de toute urgence en exhortant les créateurs de sites à intégrer les balises CSS standard, et à proposer des alternatives aux balises propres à Webkit pour que nul ne soit laissé sur le bas côté de la route, tout en relâchant la pression sur les développeurs de navigateurs mobiles alternatifs. Daniel Glazman incite tous les internautes à faire passer le mot pour sensibiliser le plus grand nombre.
Le W3C a lancé un appel à antériorité sur un brevet et une demande de brevet soumis par Apple face à la spécification Widgets W3C. Membre du W3C et soutien intéressé du libre, Apple a des intérêts contraires face aux standards du Web, entre promotion des spécifications W3C (qui évitent son enfermement) et protection de sa propriété intellectuelle (lire : W3C et iPhone : les intérêts contraires d'Apple).La demande de brevets 11/432,295 et le brevet 7,743,336, signés John O. Louch, Scott Forstall et Eric Steven Peyton, concernent les widgets et peuvent interférer avec la définition du standard Widget W3C proposé par Opera pour créer de petites applications (HTML5, JavaScript, CSS, SVG) multiplateforme et multiécran (smartphone, PC, téléviseur connecté). Avec cette recherche d'antériorité, le W3C tente de faire invalider les brevets d'Apple, afin d'éviter que la firme de Cupertino ne puisse demander des royalties sur les technologies construites à partir du standard Widget W3C.
Impossible de nier que comme Mozilla, Opera, Google ou Microsoft, Apple a joué un rôle de premier plan dans l'évolution du Web ces dernières années, de WebKit au développement, soutien et support de nombreuses spécifications W3C. Mais entre la définition de standards libres et ouverts et la défense de son portefeuille de brevets, Apple a toujours été pris entre deux feux. Haavard Moen, développeur chez Opera Software, remarque un nouveau louvoiement d'Apple, qui n'est pas sans ralentir la définition d'un standard important proposé par Mozilla et Opera, Touch Events.Lors de la définition d'une nouvelle spécification, le W3C met souvent en place un Patent Advisory Group (PAG), un comité chargé d'évaluer l'impact de la propriété intellectuelle des membres sur le futur standard. À plusieurs reprises, Apple a présenté à la dernière minute ses brevets et demandes de brevet, ralentissant les travaux d'autant plus que ces documents n'étaient pas pertinents. Ainsi en 2009, la définition de la spécification Widgets W3C avait été l'occasion d'un véritable feuilleton, Apple bloquant la promulgation de ce standard en vertu d'un brevet sur la mise à jour automatique de contenu.
Le problème réside dans le fait que la définition d'un standard libre et ouvert jette de facto la propriété intellectuelle des membres du W3C dans le domaine public, sans contrepartie financière. En 2009, le brevet d'Apple avait été contourné et jugé peu pertinent. En 2010, deux demandes de brevets de la firme de Cupertino, là encore présentées à la dernière minute, avaient été recalées après avoir retardé les travaux : une n'avait rien à voir avec la spécification, l'autre ne s'appliquait pas. L'histoire se répète cette année, cette fois avec trois brevets et une demande de brevets, une nouvelle fois soumis à peine un mois avant la date limite.
S'il est encore difficile de juger de la pertinence de ces brevets dans ce cas précis, on peut noter la régularité dans l'effort d'Apple : campée dans une position défensive vis-à-vis de sa propriété intellectuelle, la firme de Cupertino en vient à adopter une posture paradoxale, à mi-chemin entre soutien (certes intéressé) et rejet complet du libre. C'est l'iPhone et ses 200 brevets qui provoque ce flou : en 2009, il fallait éviter de favoriser Palm, qui venait de présenter le Pre ; en 2011, il s'agit de faire attention à ne pas diluer la préséance d'Apple dans le domaine du tactile. Affaire à suivre, donc.
Le W3C, l'organisme de standardisation du Web, a présenté aujourd'hui un brouillon d'une spécification standard de la fonction « Do Not Track » inventée par Mozilla : la Tracking Preference Expression.L'objectif est de mieux protéger la vie privée des utilisateurs, en leur offrant un plus grand degré de contrôle sur les données exploitées par les sites Web qu'ils visitent. « Do Not Track » est déjà intégré à Firefox, Safari et Internet Explorer : cette fonction permet à l'internaute de spécifier de manière définitive aux sites web s'il accepte ou non que ses informations de navigation soient traitées par les annonceurs afin de recevoir des publicités ciblées ou de connaître ses déplacements entre les sites.
Google, qui tire l'essentiel de ses revenus de la publicité, tarde à l'adopter, ce qui ajoute à l'intérêt des autorités américaines pour les pratiques de la firme de Mountain View en matière de protection de la vie privée (lire : Google et Opera bloquent sur Do Not Track). L'effort de standardisation du W3C peut être interprété comme une volonté d'éviter l'intervention étatique, et donc de poursuivre cahin-caha « l'auto-gestion » du Web par ses grands acteurs. Le groupe de travail mis en place regroupe ainsi Apple, Google, Opera, Facebook, Microsoft et Mozilla, en plus de l'EFF et de l'Université de Stanford.
La Tracking Preference Expression devrait permettre aux utilisateurs de définir leurs préférences pour des types de sites : tous les réseaux sociaux seront ainsi logés à la même enseigne, et refuser le ciblage publicitaire sur Facebook le désactivera aussi sur Google+. Pour éviter le suivi par cookies, cette fonction pourra offrir un profil utilisateur aux sites : le site ne stockera plus un cookie avec les préférences linguistiques d'un utilisateur, mais saura adapter la langue en fonction du profil annoncé. Enfin, si un site devait ne pas respecter les préférences de l'utilisateur, le navigateur pourrait immédiatement l'avertir. La recommandation finale devrait être présentée à la mi-2012.
Le calendrier est d'ores et déjà tracé : la première version "dernier appel" sortira en mai prochain, celle-ci contiendra l'intégralité des fonctionnalités finales. Une deuxième version "dernier appel" sera proposée d'ici la fin 2011, tenant compte des remarques faites sur la première. Au deuxième semestre 2012, viendra l'heure des retours des développeurs de navigateurs, donnant lieu à des milliers de tests.
Le W3C escompte que cette phase (qui inclura une version "Candidate recommendation" et au moins deux navigateurs capables d'obtenir des résultats similaires en partant du même code) s'étendra jusqu'au premier trimestre 2014. S'en suivra une période de six semaines pour les derniers tests, suivi par la mise au point de la promotion du nouveau standard, qui devrait donc être finalisé durant le second semestre 2014. Il restera aux développeurs de navigateurs d'implémenter ces fonctions et de toutes les supporter pleinement, sans compter les éditeurs de sites internet.
Un représentant du W3C note que le tableau des résultats est trompeur à certains égards, un résultat de 0% lors d'un test étant présenté comme ne correspondant à "aucun résultat".
La représentante d'Opera juge les résultats affichés pour son navigateur comme partiellement erronés et souligne que cette série de tests HTML5 est largement incomplète. Et d'interroger : “Publier des résultats non vérifiés à partir d'une suite largement incomplète sans un gros message d'avertissement, est extrêmement stupide. Pourquoi cela a-t-il été fait ?”

Son homologue chez Apple a rebondit sur un autre détail, le mélange entre des versions récentes et pour certaines en alpha ou beta (IE, Opera et Firefox) avec des versions finales comme Chrome et surtout Safari. Elle ajoute “Ce ne serait pas une si grande affaire si cette page de résultats passablement erronés n'avait pas été présentée comme 'Officielle' et reprise en tant que tel par la presse”.
Le représentant de Microsoft suggère alors qu'Apple fournisse les résultats de la plus récente version de Safari, ce à quoi sa consoeur réplique de manière légèrement cinglante qu'il suffit de télécharger la dernière build en date du WebKit, accessible à tout un chacun. Elle suggère également de remplacer la mention "officiel" par "non officiel" et d'ajouter un texte précisant les limites de ces tests.
Chose à laquelle un autre participant, indépendant des éditeurs, convient, précisant que la publication de cette suite de tests n'a pas de sens en l'état “Pour dire les choses de manière réaliste, cette suite n'est même pas complète à 0,1%”.
Enfin, un autre participant vient s'excuser, et explique que ces tests ont été simplement transmis sur une liste publique, mais qu'il n'était pas spécialement prévu qu'ils se retrouvent aussitôt publiés. Indiquant qu'à son goût des tests supplémentaires devraient être conduits. Et lui aussi au passage de s'interroger sur l'échantillon choisi des navigateurs.
Pour l'heure la page est toujours en ligne.
Le premier problème est celui de l'implémentation du HTML5 dans les différents navigateurs : seules les dernières versions de développement intègrent les fonctions les plus avancées. L'inertie du marché des navigateurs risque aussi de retarder l'adoption de la plateforme HTML5 : Internet Explorer 6 et 7, pour ne citer qu'eux, représentent encore plus d'un tiers des connexions, et ils ne seront jamais compatibles avec les technologies les plus modernes. « Le HTML5 ne va pas mettre Flash à la retraite de sitôt », reconnaît Le Hegaret, mais « l'industrie se rend compte que le HTML5 va arriver ».
« De moins en moins de sites utiliseront Flash », car le gel des fonctions de la plateforme HTML5 devrait être opérationnel mi-2011. A cette date, le principal problème sera donc l'interopérabilité, le support plein et entier par les différents navigateurs. La route est pourtant semée d'embûches : si des fonctions aussi importantes que WebSockets ou Canvas 2D sont prêtes, des fonctions beaucoup plus importantes aux yeux du grand public et des acteurs des médias sont loin d'être prêtes.
C'est évidemment le cas de tout ce qui touche à la vidéo : entre H.264, OGG et WebM, rien n'est encore réglé, et les ayants-droits sont encore frileux à l'idée de laisser leurs flux vidéo en clair et sans DRM, là où Flash les encapsule. Enfin, il manque à HTML5 un environnement de développement intégré : Le Hegaret rappelle que le salut pourrait venir d'Adobe, dont les produits supportent le HTML5.
L'article a été relié sur Twitter par Anne van Kesteren d'Opera, puis l'affaire a été reprise en des termes non moins polémiques par différents sites, qui hurlent à la conspiration et à la confiscation de l'intérêt public au profit des intérêts privés d'Adobe, en dépit du soutien affiché et réitéré du standard HTML5 par ses diverses instances dirigeantes.
Naturellement Adobe est montée au créneau très vite pour tenter de rassurer : elle n'a aucune intention de bloquer le futur standard et n'a fait part que d'inquiétudes légitimes au sujet de la manière dont les différentes technologies concernées sont adoptées. Difficile cependant de se faire entendre au sein de cette cacophonie.
Mais si on s'attache à regarder les faits de manière dépassionnée, il s'avère que les reproches de Ian Hickson ne sont pas tout à fait fondés : les objections d'Adobe n'ont jamais été mises sous le sceau du secret dans la mesure où elles étaient publiques dès le 5 février. D'autre part, le W3C a toute latitude d'outrepasser toute objection et de poursuivre son avancée, Adobe n'a donc aucun moyen de bloquer le HTML5 si tant est que là était son objectif.
Il semblerait que l'enjeu de cette tempête dans un verre d'eau soit surtout une question de jeux de pouvoir : parmi les éléments qui posent problème, on trouve notamment les RDFa, qui permettent d'ajouter des métadonnées au sein du code HTML. Cette fonction est le pendant du W3C aux Microdata mises au point par le WHAT-WG, le groupement d'éditeurs de navigateurs qui avait jeté les bases de ce qui allait devenir le HTML5 avant que le W3C ne récupère ses travaux. Récemment les membres du W3C ont voté pour séparer les Microdata des spécifications de HTML5. Or il se trouve que Ian Hickson peut s'enorgueillir de quelque paternité sur les Microdata… La polémique pourrait donc être issue d'un ressentiment personnel.
On peut cependant s'interroger sur la légitimité de listes de discussion privées au sein d'un organisme qui se voue à décider du bien public par le biais d'un standard ouvert et libre. Mais étant donné que certains membres du W3C sont des entreprises il peut s'avérer nécessaire de leur garantir une certaine confidentialité, sur des sujets technologiques parfois sensibles, pour bénéficier de leur collaboration. Une chose est sûre, le secret aura été le combustible qui aura permis à ce feu de paille de prendre, et Adobe aura sans doute quelque difficulté à corriger le tort qu'elle a subi.
Le SVG va pouvoir connaître un nouvel essor, puisque la firme de Redmond a fait savoir qu'elle avait demandé à rejoindre le groupe de travail qui s'y consacre au sein du W3C. On devrait donc voir le format géré par Internet Explorer à terme, ce qui devrait favoriser son utilisation sur le net à l'avenir.
Il est intéressant de noter que l'affichage de WebGL se fait par le biais de
canvas, la fonction dédiée au rendu 2D paramétrique dans HTML 5 (voir notre une : Comment HTML 5 va changer la donne). La progression naturelle voudrait qu'une fusion des deux standards s'opère dans le future, bien que chacun soit poussé par deux organismes séparés (W3C pour le HTML 5 et donc Khronos Group pour WebGL). Pour l'heure WebGL ne supporte que les cartes capables de gérer le standard OpenGL ES 2.0, les puces GMA d'Intel ne sont donc pas de la partie.Il s'agit donc de jeter les premières bases de ce nouveau standard, mais difficile d'évaluer la popularité dont il bénéficiera tant que tous les navigateurs ne le supporteront pas. D'ici là il faut toujours en passer par des plugins propriétaires (tels que Shockwave ou Unity) pour afficher des contenus 3D dans une page web sur tous les navigateurs. Le Khronos Group espère fournir une première version publique de WebGL pour le premier semestre de 2010.
Ian Hickson, un employé de Google qui travaille sur ces questions, récapitule les raisons de ces désaccords : concernant la vidéo, deux codecs tiennent la corde, Ogg Theora et H.264.
Apple refuse d'implémenter Ogg Theora dans QuickTime par défaut (tel qu'utilisé par Safari), en citant une absence de support matériel et un terrain incertain concernant d'éventuels brevets.
Google a implémenté H.264 et Ogg Theora dans Chrome, mais ne peut fournir la licence du codec H.264 aux distributeurs tiers de Chromium (la version open-source de Chrome), et pense que le rapport qualité par bit d'Ogg Theora n'est pas encore satisfaisant pour le volume de données géré par YouTube.
Opera refuse d'implémenter H.264, à cause du coût obscène des licences concernées.
Mozilla refuse d'implémenter H.264 car elle ne pourrait obtenir une license pour ses distributeurs tiers.
Microsoft quant à elle n'a fait aucun commentaire sur leur intention ou non de supporter le tag <video> propre à HTML 5.
On le voit donc, c'est un peu la cacophonie et ça n'aidera pas à établir in standard. Apple a besoin d'un codec qui puisse être décodé par une puce pour que ses iPods et iPhones soient capables de lire de tels formats, ce qui est le cas du H.264 mais pas d'Ogg Theora.
En l'état, Ian Hickson suggère de laisser de côté ces considérations en attendant qu'un standard s'impose de lui-même : selon lui, sur la durée soit les questions de licence autour de H.264 finiront par disparaître d'elles-mêmes lorsque les brevets expireront, soit des puces viendront à être mises à disposition pour le décodage d'Ogg Theora, ajoutant en outre qu'il suffira d'observer la situation avec Chrome pour se rassurer quant à d'éventuels problèmes de brevets.
En attendant, voilà qui ne simplifiera pas l'adoption d'HTML 5, puisque les développeurs web devront fournir leurs vidéos dans tous les formats supportés par chacun des navigateurs pour s'assurer qu'elles soient accessibles par tous les utilisateurs. Mais il est vrai que le W3C a encore beaucoup de temps devant lui pour régler ces questions, la finalisation de HTML 5 n'étant pas prévue avant 5 à 10 ans.
Sur le même sujet :
- Adobe confiant face à HTML 5
Voilà que le feuilleton connaît un nouvel épisode alors que le groupe de travail qui avait été constitué pour trouver une solution fait un appel aux contributions : le W3C demande à ce qu'on lui communique des utilisations relevant du brevet d'Apple précédant son dépôt afin de contourner le problème (ou prior art comme le veut l'expression consacrée).
Le consortium répond également indirectement aux inquiétudes d'Opera concernant cet épineux problème (voir Brevet & W3C : Apple s'entête), en précisant que l'enquête ne retarde en rien les travaux sur le standard des widgets, qui se poursuit parallèlement. Tout au plus en empêche-t-elle sa promulgation en tant que standard tant qu'une solution n'est pas trouvée.
En outre, le W3C précise qu'Apple fait partie de la commission d'enquête, désireuse qu'elle est de trouver une solution tout en conservant sa propriété intellectuelle, dont la défense est également au cœur des préoccupations du consortium (un tel standard, dans l'état, jetterait de facto le brevet d'Apple dans le domaine public). D'un point de vue diplomatique, donc, pas de discorde et tout va pour le mieux.
Une lente évolutionDepuis l'avènement du Web, il n'y a eu que peu de changements radicaux. Nous sommes partis de simples pages HTML codées en "dur", puis nous avons eu les contenus dynamiques grâce au cumul de PHP et MySQL, et plus d'interactivité avec Javascript. Le mélange des trois technologies a abouti à Ajax, pour des pages plus réactives encore. Les feuilles de style permettent de faire évoluer le design d'un site plus simplement, et les flux RSS nous gardent informés des nouveaux contenus.
Au regard des ans, le Web avance à un train de sénateur, comparé aux autres branches de l'informatique. L'organisme qui régule les standards du web, le consortium W3C, s'est d'ailleurs vu remis en question précisément pour son inertie, poussant les développeurs de navigateurs à s'allier pour créer le WHATWG, dont les travaux ont d'ailleurs servi de base de travail pour HTML 5, en chantier depuis maintenant plus de cinq ans. Il faut dire qu'il n'est pas aisé d'effectuer une transition technologique dans le domaine des standards du web : la multitude de machines susceptibles de consulter une page web, mais également les capacités des systèmes d'exploitation ou encore la mise à jour des divers navigateurs n'y aident certainement pas.
>> Lire la suite
1 / 2 >>






Mai 2013
