humani nil a me alienum puto

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 26 novembre 2008

oh, ce qu'ils n'ont pas osé faire !

RealBasic : via une google ad, je découvre cet IDE+compilateur crossplatform win/linux/mac (toutes versions de mac), qui... réinvente VB6  >_<". Et là normalement, il faut troller à mort, mais voilà, après un coup d'oeil, c'est simplement épatant (j'aime particulièrement le debug pas à pas où l'on peut visualiser le contenu d'une image !). Et je suis bien embêté pour me moquer, maintenant, parce que chiotte, c'est quand même du basic avec des Dim et autres saloperies. N'empêche, c'est manifestement carrément meilleur que le Visual Basic de m$ (même à l'exécution : pas besoin d'une dll de réinterprétation, la plaie absolue de VB pour filer ses programmes à quelqu'un d'autre), et c'est par des texans (ouch !) qui vous traduisent le site ouèbe dans votre langue sans qu'on ait rien à lui dire.

Purée, y'a des gens qui en 2008 codent un compilateur propriétaire complet from scratch, avec une IDE complète (qui n'est pas un plugin eclipse), avec des features puissamment clickodromesques (pareil que sous VB, on construit sa fenêtre en WYSIWYG), pour... du Basic. Va me falloir un certain temps pour m'en remettre...

lundi 8 septembre 2008

google se prendrait-il pour une pomme ?

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  :)   )

dimanche 31 août 2008

le business n'a pas d'oeil

O'Reilly m'envoie ça par mail il y a 5 jours, dans l'espoir peut-être que j'y claque mon DAF (voyons, 3500€, j'en prends ensuite pour 4 mois de dédit, ah, avec le billet d'avion, ça va dépasser 6 mois, hhmmm).  Dans l'absolu, c'est très drôle :

Learn How to Obtain iPhone Forensic Data

A Two-day O'Reilly Developer Workshop for Security Professionals
September 16-17, 2008 • Burlington, Massachusetts

The Apple iPhone retains an enormous amount of user data, including voicemail, email, images, and more. The need for knowledge about this rapidly emerging area is intense. O'Reilly's iPhone Forensics Developer Workshop will supply you with this sought-after and valuable information.

Are you an IT or security professional who is looking for ways to manage sensitive data on employee iPhones?

Are you with a law enforcement or government agency and need to process iPhones for evidence?

This highly specialized two-day forensics workshop will teach you how to recover, process, and remove sensitive data stored on the iPhone, iPhone 3G, and iPod Touch. Register now!

    * $3500.00 for general enrollment.
    * $2500.00 for vetted law enforcement professionals and government employees.

Led by author and data forensics expert Jonathan Zdziarski, you'll learn how to:

    * Determine what kind of evidence is stored on the device
    * Prepare an environment for iPhone forensics
    * Break v1.x and v2.x passcode-protected iPhones to gain access to the device
    * Build a custom recovery toolkit for the iPhone
    * Interrupt iPhone 3G's "secure wipe" process
    * Conduct data recovery of a v1.x and v2.x iPhone user disk partition, and preserve and recover the entire raw user disk partition
    * Recover deleted voicemail, images, email, and other personal data using data carving techniques
    * Recover geotagged metadata from camera photos
    * Discover Google map lookups, typing cache, and other data stored on the live file system
    * Extract contact information and other data from the iPhone's database
    * Collect desktop trace and establishing trusted relationships to owners' desktops
    * Use different recovery strategies based on case needs

Jonathan Zdziarski, the original iPhone hacker, developed this workshops based on the contents of his new book, iPhone Forensics (O'Reilly Media, September 2008). As a part of your enrollment, you'll receive a copy of the book to help you follow the workshop presentations. You'll also receive a USB drive containing the forensics toolkit Zdziarski uses.

Space is limited, so register today to secure your spot in this valuable workshop.

Je ne sais même pas trop si c'est vraiment légal. En France en tout cas, j'aurais un très gros doute : intrusion dans un système et contournement de protection "efficace" (le fameux terme de DADVSI), à des fins différentes de l'interopérabilité, il vaut mieux espérer que l'auditoire soit effectivement composé de bon nombre d'informaticiens de la policie scientifique, histoire de se couvrir...

Nous retiendrons en tout cas que non seulement le système de sécurité de l'iPhone, qui consiste surtout à être incompatible avec tout ce qui existait avant (dans l'absolu, pour récupérer mon agenda, je le fais facilement en passant mon téléphone en mode portable, et en utilisant un soft sous KDE qui envoie les bonnes commandes AT ; idem pour les SMS), a tellement de fuites que des pampers n'y suffiront pas, mais en plus on fait du business sur leur dos en apprenant à tous ceux qui voudraient contourner cette sécurité de merde (mais assez pour décourager le Kevin avancé moyen) comment s'y prendre. Et pas qu'un peu : même le mot de passe tombe aux oubliettes (et sans fer à souder ?).

Du grand n'importe quoi. Comme toujours.

mercredi 28 novembre 2007

le buzz et le neurone

10.000 aurait déjà été écoulés en France, sans que cela soit encore en vente. 60.000 sont attendus pour les quelques semaines, et 100.000 avant la fin de l'année. Vendus avec un accord d'exclusivité illégal, verrouillé illégalement, et avec de fortes ventes liées illégales, pour 2h de communication à 50€, mais rien n'est encore officiel, et le buzz monte. Orange s'apprête à vendre l'iPhone. Comme pour l'iPod, le bidule est technologiquement plus pauvre que la concurrence, mais plus joli, c'est sûr -- plus pratique, cela reste à voir. Il est fermé, opaque, beaucoup trop cher, le business model est a priori lamentable.

Mais le buzz est là. L'objet de mode, de la tentation. Je suis navré de me rendre toujours compte que le neurone est toujours un concept étranger au consommateur abruti -- que l'on appelle "citoyen", parfois, c'est selon ce qu'on veut lui faire avaler. Ce soir, ce sera donc la folie sur les Champs-Élysées, paraît-il. C'est lamentable. Apple est en train de battre m$ sur son propre terrain, avec des produits différents, où ces derniers ont totalement échoué (entre Zune, wma, et windaube mobile) ; ils ne valent vraiment pas mieux. Mais c'est surtout les neuneus prêt à sacrifier -- tout en râlant sur le pouvoir d'achat en baisse, blabla, soyons-en sûr -- 1200€ la première année minimum (et au moins 600 les suivantes) pour passer des coups de fil avec un produit pauvre et fermé au possible, qui me fendent le coeur.

mercredi 3 octobre 2007

openMoko Neo rulezzz

L'iPhone, c'est le mal. Et pas juste parce que ce sont ces voleurs sans foi ni loi de Apple, les mecs qui font croire qu'ils ont même inventé le feu (récemment, Celui me sortait innocemment qu'Apple avait inventé la souris ; non non, ils l'ont juste volé à Xerox...), alors qu'ils ont toujours un espèce de kernel étrange mixé entre du Mach, du Step, et du BSD, ce qui ressemble surtout à rien du tout dans l'absolu. Au passage, je me suis amusé récemment à voir l'étendu du lavage de cerveau même parmi les windowsiens confirmés en quête de rédemption linuxienne en la personne de mon cousin, qui me confiait à quel point il avait été épâté de voir que lorsque l'on branche une imprimante sur Mac, hop, ça marche tout de suite, pas besoin de drivers ; sauf qu'en fait, Mac a depuis 2 ou 3 ans viré son ancien système casse-tête (qui était une plaie absolue) pour intégrer CUPS, le service d'impression bien connu des gens sous BSD et Linux, puisque toutes les distribs l'ont inclus par défaut depuis des années ; mieux encore, avec le système KDE d'impression, on atteint des sommets en terme de maniabilité, parce qu'il faut bien avouer que CUPS est un peu brut de fonderie (imprimez avec Firefox, et tentez la même opération avec Konqueror, la différence est de taille... Quant à la gestion des imprimantes, y'a pas photo) ; bref, il s'extasiait d'un truc qu'il connaissait pourtant déjà sous Linux, c'est très fort.

CUPS est d'ailleurs un bon exemple du revirement partiel de Apple, puisque la firme a racheté le copyright et le développeur principal, et investit ses fonds sur un projet aussi libre que Webkit, issu de KHTML, le moteur html de Trolltech/Konqueror, qui apparemment est plus propre et plus efficace, et devrait être réintégré à la place de KHTML lui-même. Ce qui devrait en toute rigueur, grâce aux développement effectués sur l'iPhone, bouleverser totalement le paysage des navigateurs embarqués, qui pour l'instant représentent une plaie béante (trop lourds, trop coûteux, un opera plante sans cesse, un webfront de chez Access coûte 200K$ de licence plus les royalties de 1 ou 2 $ par device, plus les coûts de SDK etc, pour un résultat à faire rire jaune...). Tristan est d'ailleurs passablement à côté de la plaque sur le sujet (sur les motivations des opérateurs ; mais aussi sur "l'expérience mobile", à l'heure où l'on parle d'écrans de téléphone de plus de 600px de large, et même de console de jeu encore plus larges, voire même de télé sur set top box), mais je puis vous affirmer que gecko n'est pas près de voir un appareil mobile vu sa consommation mémoire et CPU inexpliquable (enfin, Telefonica -- pour ne pas les citer -- a tenté l'expérience avec un Mozilla -- et c'était il y a peu, pourquoi ne pas avoir mis au moins un Konqueror ? C'était sur une box de télénum, ce fut un échec sanglant, zarb non ?).

Bref, si je tire sur Apple encore une fois, c'est pour sa politique envers les consommateurs qui encore une fois sont pris pour des cons. Vous me direz, il ne fallait pas être bien fûté déjà pour s'acheter un iPod alors que la concurrence fait beaucoup mieux pour beaucoup moins cher (au fait, vous savez pas quoi, l'interface de l'iPod, elle vient de chez Samsung, c'est une commande officielle...). Cette fois-ci, ils s'en prennent aux gens qui osent délocker leurs téléphones pour ne pas être rackettés par l'Opérateur Officiel choisi, AT&T aux US, et, l'a-t-on appris récemment, Orange en France très bientôt. Ces foutus clients non seulement dépensent 600$ (soit... 600€, on n'arrête pas le progrès libéral) pour un téléphone certes joli avec une interface graphique qui brille (mais apparemment un poil complexe à explorer), et en retard technologiquement (mais bon, Apple vend bien des lecteurs mp3 sans écran comme des petits pains... Comment faire du neuf avec du très très vieux, parce que même mon lecteur de cassette audio avait un écran, faut pas déconner), mais en plus ils ne veulent pas obéir à la violation de toutes les lois anti-concurrentielles qui soient, vous imaginez ! Scandale !

Donc, après la découverte des mille et une façon de délocker le bousin (pour un device vendu comme infaillible, blablabla, comme c'est drôle ; vous me direz "rien n'est infallible" ; ça ça reste à voir les enfants, je sors d'un projet qui avait un peu le même but, et je ne pense pas que l'on puisse détourner les 2 ou 3 clefs de chiffrage, les file system write only ou sans exécution possible, et les protection de pile et d'exécution mémoire sans avoir recours à beaucoup de magie noire), ça va sévir ; et aux menaces de garanties qui vont tomber et autres firmwares rendant inopérant la bestiole, les utilisateurs veulent répondre par une class-action, on nage en plein délire (après tout, pourquoi filer son pognon à Apple en premier lieu, hein ?).

Nokia fait le malin de son côté et pond une pub sur l'ouverture (toujours via Tristan) ; y'en a qui ferait mieux de se taire, avec leur Symbian tout pourri ; et même les N770 et N800, y'a quand même pas mal de soft propriétaire dedans (tiens, opera par exemple... Mais plus embêtant, la reconnaissance d'écriture, ballot ; d'ailleurs, ce qu'il y a de plus sujet à bug sont les trucs proprios, on essaiera de s'étonner).

En réalité, l'espoir vient d'OpenMoko, avec son Neo 1973. Le téléphone est quasi-entièrement ouvert (quelques exceptions pour cause de GPS proprio, et de stack GSM protégée par la loi, histoire de ne pas donner le droit au cotoyen lambda de faire du brouillage de comm', me semble-t-il), ce qui comprend même l'électronique, et la possibilité d'acheter pour pas bien plus cher une malette de développement fournissant en sus (et entre autres) une véritable sonde J-Tag (ce qui permet d'injecter directement du code dans la CPU et de faire booter ce que l'on veut dessus ; par exemple, là, je développe avec un port qui a la même gueule sur des box de télé numérique, sauf que pour le grand public, on ommet de souder le bidule, pas fous les mecs).

Bref, la comparaison entre les spécifications brutes de l'iPhone et du Neo1973 donnent le second avec un certaine avance. Évidemment, l'interface de l'iPhone troue le cul, le challenge est élevé. Mais voilà, openMoko est basé sur enlightenment, directFB, et d'autres soft développés auparavant par trois pelés deux tondus surdoués, qui en 2004 faisaient déjà des merveilles dont Apple n'a pas encore idée 3 ans plus tard. Les vidéos qui commencent à circuler mettent alors l'eau à la bouche, mais patience. Enfin, il faut bien comprendre quelque chose : openMoko est un projet certes mené par une boîte privée taïwannaise, mais surtout ouvert et surtout communautaire, ce qui veut dire que l'on peut déjà acquérir la bête à prix réduit (mais la version finale est différente du point de vue hard que celle d'il y a 6 mois, moins puissante, il fallait donc être vraiment motivé, ou avoir des intérêts directs), et que dès su'il sera répandu un tout petit peu, des tas de développeurs comme moi vont s'empresser de rajouter plein de fonctionnalités dans tous les sens ; pour le moment, on peut toujours attendre sa sortie d'ici quelques jours, et le commander sur le net s'il n'est pas encore sorti effectivement dans les magasins de France (les mêmes qui n'auront aucun scrupule à faire bouffer de l'iPhone à tout le monde) dès qu'il sera sorti. Il n'y a qu'à voir l'effervescence autour de Maemo sur N770/N800 pour s'en convaincre aisément...

En attendant, on peut aller sur le site du Neo, et éviter de mettre ses économies dans un énième machin fermé. Ce qui est certain, c'est que moi je n'attendrai pas plus de 2 jours après sa sortie pour le commander, après avoir longuement hésité, j'adore mon N770, et franchement l'openMoko sur un autre registre lui met complètement la pâtée ^^.