fplanque: Techno

Symbian, depuis sa création (sur la base d'Epoc, OS du Psion) l'avait clairement pressenti: l'assistant numérique personnel au sens large se déclinera sous deux formes principales: le PDA tel qu'on l'a connu jusqu'ici (Palm, PocketPC) qui tient presque dans la main et se manipule avec l'autre main (stylet, mini-clavier...) et le smartphone: qui tient vraiment dans une main et se manipule facilement avec les doigts de la même main.
Pour éviter la surcharge d'appareils divers, on pouvait envisager d'intégrer le téléphone au PDA et munir celui-ci d'une oreillette... mais pas très pratique à manipuler... surtout pour décrocher lorsqu'on vous appelle. Alternative: un casque bluetooth... mais on reste loin de la facilité à manipuler un smartphone (quasiment le même form-factor qu'un téléphone classique).
Voilà pourquoi il faut s'attendre à ce que les ventes de PDA restent marginales par rapport aux smartphones à venir.
Microsoft l'a bien compris en lançant son OS spécialisé Smartphone (embarqué en l'occurrence dans le SPV - son photo vidéo - de Orange). Il ne s'agit pas de Pocket PC mais bel et bien d'un OS optimisé pour le format du smartphone. Et c'est là que Microsoft est malin! Bien plus que Handspring qui avec le Tréo propose un smartphone hibride (à base de Palm OS) trop gros pour être pratique en utilisation téléphone.
Et PalmOS a un sérieux problème ici: il doit d'urgence décliner son OS dans une version embarquable sur un format plus proche d'un téléphone classique! C'est de là qu'il faut attendre 90% des revenus! Encore une fois, le PDA classique ne s'adresse qu'à une clientèle restreinte de businessmen ou de passionnés (bref ceux qui ne peuvent se contenter d'un clavier à 16 touches, voire d'un système de reconnaissance vocale en anticipant sur les progrès à venir de cette technologie...)
Microsoft joue sur les deux tableaux... il a économiquement raison! Et son principal concurrent n'est donc pas PalmOS comme on pourrait le croire mais plutôt Symbian et son chef de file: NOKIA !

Si j'en crois quelques témoignages trouvés sur le net; il semblerait que sentry.exe ait été installé par Morpheus (c'est à dire il y a assez longtemps déjà!!). Evidemment l'installeur de Morpheus ne prévient pas et il n'y a pas non plus d'icône dans le panneau de contrôle Add/Remove pour désinstaller ce spyware (je l'accuse parce qu'il essaye de se connecter au net sans que je ne lui ai rien demandé!)
Morpheus n'est pas le seul à oeuvrer ainsi (bien qu'à ma connaissance WinMX, par exemple, soit bien plus civilisé...) Mais ce qui me parait tout de même abbérant, c'est que quand c'est Kevin Mitnick qui entre sur votre système à votre insu, on le met en prison. Quand c'est une société commerciale, celà semble parfaitement légal!

J'ai trouvé deux nouvelles saloperies dans mon arbo windows: sentry.exe et sharedprem.exe. Cette vermine n'est pas détectée par Ad-aware ou Spybot Search & Destroy. Connaissez-vous un outil capable de détecter plus que ceux là... ? Pour l'instant il faut les supprimer à la main et les déréférencer de la section Run automatique de la registry.

[Ce post a été déterré de mes archives 1999]

Aujourd'hui j'ai été initié au terrible secret de fabrication de la déplorable médiocrité des traductions de nos logiciels quotidiens! En effet, dans le cadre d'un recrutement de chef de projets, nous avons aujourd'hui reçu un candidat ayant précédemment travaillé dans une SSII de traduction industrielle. Et non des moindres, puisqu'il était en charge de la traduction en français d'un environnement de développement assez connu permettant de réaliser des programmes Windows en disposant "visuellement" des objets et en tapant quelques lignes de Basic... (oui oui on parle bien de la même chose)!

Voici comment il procédait (selon une tradition qui se transmet de collaborateur en successeur depuis la nuit des temps de la localisation): un outil "très astucieux" commence par extraire toutes les chaines de caractères de tous les fichiers source et ressource du projet complet (je parle bien de l'environnement de développement complet!). Il en génère ensuite un fichier Excel dans lequel on retrouve le nom du fichier source, la position, le texte en anglais... reste une colonne vide pour le texte en français! Le gros du travail consiste alors à traduire les chaines de caractères ligne par ligne avant que le "très astucieux" outil ne réintègre ces traductions aux sources!!!

Moi: Mais... et le contexte?
Lui: Comment ça le contexte?
Moi: Oui, une même phrase, ou pire: un mot isolé n'a pas forcément la même traduction selon le contexte!!??
Lui: Oui, mais c'est rare... et dans ce cas, les testeurs nous le signalent lors de la phase de tests.
Moi: Ah? Et les testeurs passent par tous les écrans en comparant l'anglais et le français pour voir si le sens est respecté? Ils provoquent également l'affichage de tous les messages d'erreur?
Lui: Je ne sais pas... je n'ai pas participé aux tests.
Moi: Et vous même, quand vous traduisez, vous vous basez sur votre expérience en programmation?
Lui: Je ne suis pas programmeur!
Moi: Ah? Et ça ne pose pas de problème pour traduire un environnement de développement?
Lui: Vous savez, un logiciel reste un logiciel. D'ailleurs, sur les logiciels bureautiques [du même éditeur] les traducteurs ne sont pas non plus forcément des utilisateurs avancés, mais ce n'est pas un problème. Ce qu'on demande aux traducteurs, c'est de traduire, pas de refaire l'interface!
Moi: Passons à autre chose...

Après cette discussion, j'en suis à me demander comment les logiciels traduits en français arrivent tout de même à séduire certains utilisateurs...

Hum... probablement ceux qui ne parlent pas anglais, ne lisent pas les messages d'erreur par principe et n'ont jamais tenté d'ouvrir les options avancées, voire ne serait-ce que l'aide en ligne!

[Ce post a été déterré de mes archives 1998]

Exemple concrêt:

1. Un utilisateur souhaite transmettre son numéro de carte bancaire à un serveur de manière sécurisée.
2. L'utilisateur doit chiffrer son message (en l'occurence son numéro de carte) grâce à une clé. Et le serveur doit déchiffrer le message grâce à une clé.
3. Si on utilisait une méthode de chiffrement simple (symétrique), l'utilisateur et le serveur devraient au préalable se mettre d'accord sur une clé de chiffrement/déchriffrement secrête et connue d'eux seuls afin que personne d'autre ne puisse déchiffrer le message.
4. Cet échange de clé secrête n'est pas possible par Internet, car si on pouvait se transmettre secrêtement une clé, on pourrait directement se transmettre secrêtement le numéro de la carte bancaire. On tourne en rond...
5. La solution consiste à utiliser une méthode de chiffrement asymétrique: le chiffrement se fait avec une clé et le déchiffrement se fait avec une autre clé. Bien sûr, pour toute clé de chiffrement il n'existe qu'une seule clé de déchiffrement possible. Ces clefs fonctionnent donc exclusivement par paires.
6. Le serveur définit donc une paire de clefs. Il en garde une secrète (la clef privée). Il en donne une autre à tous ses utilisateurs (la clef publique).
7. Dès lors, tout utilisateur peut chiffrer son message avec la clef publiquer et l'envoyer en toute confiance au serveur qui sera le seul à pouvoir le déchiffrer car il est le seul à posséder la clef privée, indispensable au chiffrement.
   
   Note: en réalité, le browser va chiffrer une clef master aléatoire qu'il va envoyer au serveur qui est le seul à pouvoir la déchiffrer avec sa clef privé. Cette clef master est ensuite utilisée pour chiffrer à la fois les messages envoyés au serveur et les messages reçus du serveur. Toutes les informations échangées entre le browser et le serveur sont ainsi cryptées.
8. Mais ça ne suffit pas. En effet: que se passe-t-il si jamais une personne malveillante diffuse une fausse clef publique? Le message chiffré envoyé par l'utilisateur ne sera plus déchiffrable par la clef privée du serveur. Par contre il sera déchiffré facilement par le pirate qui possède la clef privée correspondant à la fausse clef publique.
9. Il est donc indispensable que l'utilisateur soit sûr d'utiliser la BONNE clef publique.
10. Pour être sûr, il dispose d'un certificat émis par une Autorité de certification et qui certifie que la clef est la bonne.
11. Mais comment être sûr que le certificat n'est pas un faux? Réponse: parce qu'il est signé électroniquement par une aurtorité de certification (AC) connue à l'avance. (Une liste d'AC est préenregistrée 'en dur' dans le browser Web).
12. La signature électronique fonctionne sur le même principe: l'AC chiffre le certificat avec sa propre clef privée et l'utilisateur déchiffre le certificat avec la clef publique de l'AC. Rappelons qu'il connait cette clef publique à l'avance car les AC et leurs clefs publiques sont préenregistrées dans le browser Web.