C'est qu'en lisant leur BD sur leur nouveau navigateur qui aurait déjà quelques facheuses manies (faire un logiciel libre avec un tel contrat, aussi, c'est très fort ! Déjà que ça jasait par avance...), je me dis que leur bouillie entre commercial et technique me rappelle franchement ce que Apple a l'habitude de faire en terme d'enfumage. Bref, passons sur les méthodes expéditives de spyware "pour votre bien" (on dirait du Jobs) ou encore sur le "sure, we could ship a proprietary browser and hold it in" (bonne chance couillon ! Ou alors ils veulent dire qu'ils aurait tout pu coder en interne ? Je me marre encore plus !), et concentrons-nous sur l'aspect bassement technique.

Comme Apple, Google est tombé amoureux de KHTML. Enfin, de Webkit, le successeur justement issu du passage de KHTML par les mains d'Apple, et adopté à présent par Trolltech/Nokia (mes lecteurs savent combien c'est important). On s'amuse au passage de voir que les Google mail ou Gmaps restent incompatibles avec Konqueror, basé sur KHTML et bientôt sur webkit (en fait à l'heure actuelle il y a très peu de différence, maintenir deux branches n'a donc plus d'intérêt), non pas par impossibilité de support, mais parce que Google se chie dessus (il suffit de trafficoter l'URL de google maps pour retrouver une interface AJAX complète). Mais ce n'est pas la seule chose pompée de KDE : car les concepts super-révolutionnaires présentés font furieusement penser à l'organisation de... Konqueror !

Par exemple, dès le début, on nous parle de processus séparés pour la gestion du html, de telle sorte qu'en cas de plantage, le navigateur en lui-même n'est pas affecté (cette affirmation sera à remettre en perspective : la communication par mémoire partagée peut avoir des incidences imprévues au moment du codage, et ce n'est pas parce que Konqueror plante rarement qu'il ne plante jamais). Mieux encore : les plugins aussi sont dans des processus séparés. Eh bien chers amis inventifs de google : dans Konqueror, même les cookies sont gérés dans un processus séparé, et ça fait longtemps qu'un plantage de Flash n'a aucun impact sur la navigation, contrairement à une daube mal dégrossie du nom de Firefox. Et ce depuis plus de six ans déjà... (je me demande si cette organisation ne date pas même de la première implémentation de Konqueror, donc plus de 10 ans)

Mais ce qui me chagrine, c'est cette histoire de V8. On commence par nous dire que pour être sécurisé et ne pas affecter les performances, on chargera le Javascript dans une machine virtuelle (un autre concept de Konqueror, original, hein ?), ou "sandbox". Mais pour aller plus vite, ça compile ledit code Javascript en langage machine. Et là, déjà, on a un problème. Surtout que ça enfonce le clou : le processus est mis dans une "jail" (je garde le terme en Anglais, ce n'est pas pour rien). Mais on nous dit pourtant que pour les autres plugins propriétaires (on pense très fortement à Flash, what else ?), il sera impossible de les enfermer, sauf à ce que les éditeurs (Adobe, quoi) mettent des hooks pour ce faire.

Au début, je pensais "machine virtuelle = code interprété", avec au niveau de l'exécution finale un contrôle ("non, coco, tu ne redimensionnes pas la fenêtre, t'es pas chez toi"). Mais la compilation non pas en bytecode (à la Java, qui n'a absolument pas inventé le concept non plus, mais comme Apple avait déjà initié le mouvement depuis Lisa...) mais en langage machine. Et on nous spécifie bien que le tout tourne dans un seul processus par onglet (mais là, clairement, c'est n'importe quoi). Surtout, si ledit code est exécuté directement sur la machine, je vois mal comment faire le tri entre les bonnes instructions, et celles visant clairement à mettre en défaut la sécurité : le seul moyen est de passer par l'OS et du jail, systrace, ou autre armement lourd de ce type disponible sur les BSD ou Linux. Or non seulement Chrome tourne sur cette vulgaire passoire de windaube, mais en plus ils nous disent bien que leur pauvre modèle de sécurité à deux sous ne peut pas être utilisé (outre le fait de n'être disponible que sous Vista, bonjour la portabilité !).

Une autre idée serait alors de mettre une couche de virtualisation maison sous le binaire, qui attraperait en vol les instructions read ou write tendancieuses : mais alors, pourquoi compiler en code machine ? (surtout à l'heure des CPUs huit-coeurs, même les ARM font peur maintenant...) C'est tout de même la meilleure manière de se tirer une balle dans le pieds ! Surtout que le buffer overflow n'est jamais bien loin (et que la seule manière de l'empêcher est d'avoir... les mécanismes dans le noyau dont nous avons parlé plus haut). Sauf que ce serait aussi possible alors d'enfermer les plugins, open source ou pas, et manifestement ce n'est pas le cas. Bref, ça sent l'enfumage, ou alors la magie noire, mais ça je ne crois pas trop.

(mon ancien stagiaire qui vient de passer a déclaré : "ils ont pris de la drogue, ou un commercial" ; c'est beau l'héritage culturel  :)   )