1

Création du hashtag qui me rendit célèbre : #lmi pour Long Mais Intéressant

LMI

Aujourd’hui c’est vendredi et j’ai décidé de passer à la postérité du Web.

Comment ? C’est très simple : je viens d’inventer un acronyme doublé d’un hashtag Twitter qui, à n’en pas douter, fera bientôt le tour du Net francophone (oui, il ne faut douter de rien dans ces cas-là, c’est même à ça qu’on les reconnaît).

Ne vous faisons plus attendre et levons le voile sur ces trois lettre d’or qui me rendront célèbre à défaut d’être riche :

LMI ou #lmi pour Long Mais Intéressant.

Allez-y, vous pouvez d’ores et déjà l’utiliser partout où il vous semble bon. Il va sans dire que c’est placé sous licence libre (celle que vous voulez). Et ne me remerciez pas, c’est pas la peine, c’est cadeau.

J’en profite pour présenter d’emblée mes plus plates excuses au Laboratoire des Matériaux Inorganiques, au Luthier Mercantile International, au Linux Mark Institute, sans oublier Le Monde Informatique, parce que, soyons lucide, mon LMI va nécessairement leur faire de l’ombre…

Oups, désolé, mais j’ai un petit SMS à envoyer à Monique… tap, tap, tap : « Alors t’as trouvé ça comment hier soir ? », clic, envoyer. Voilà, je reviens vers vous.

Comment m’est venue cette idée de génie ?

Tout simplement à force de lire et d’entendre un peu partout que les articles du Framablog « c’est long mais intéressant ».

Et pour le dernier en date, ça n’a effectivement pas loupé comme on peut le constater sur l’illustration ci-dessus.

Notez que c’est mieux qu’un « c’est long et chiant ». Mais à ce moment-là la logique veut qu’on n’en parle pas.

Notez également, et c’est plus subtil. que c’est toujours mieux qu’un « c’est intéressant mais long ». A priori on peut penser que c’est équivalent, mais entre un « c’était pénible mais ça valait le coup » et un « ça valait le coup mais c’était pénible », mon cœur ne balance pas.

Toujours est-il que dans une petite semaine (pas plus), ce sera la gloire absolue : un article Wikipédia dédié à ma création ! Oui, oui, Comme TINA ou MDR !

Il y aura bien, au début, une petite guerre d’édition entre wikipédiens de la première heure peu rompus aux joies du microblogging et ceux qui ont édité l’article. Mais les premiers céderont bien vite devant les seconds quand ils verront mon hashtag caracoler en tête des trending topics. D’autant que l’article sera sourcé puisqu’il suffira de faire un lien vers ce billet !

Le « long » n’est pas une constante du Net. Bien au contraire il varie constamment, mais toujours dans le même sens. Plus le Web avance, plus le long devient court. Aujourd’hui la limite est fixée à 140 caractères, après ça peut éventuellement être intéressant mais c’est déjà trop long.

Qu’en sera-t-il demain ?

Oh, mais Monique vient de répondre à mon SMS… Je regarde : « LMI » !




La promiscuité sans fil des réseaux WiFi publics

David Goehring - CC-BySe connecter à un Wifi public dans un parc, une gare ou un café [1] pour accéder à Internet, c’est un peu comme passer par la salle d’attente du médecin avant une consultation. Dans les deux cas, vous avez confiance en votre destination [2], mais vous êtes au préalable enfermé dans un espace avec des étrangers, tous plus ou moins malades.

En effet, le WiFi d’un café vous connecte, comme la salle d’attente, avec votre entourage direct, sans que vous ayez rien demandé. Or, si votre dossier médical est confidentiel, il suffit de faire tomber ses papiers dans une salle d’attente pour que toutes les personnes présentes puissent les lire, et il suffit de se connecter (via un WiFi public) à un service qui n’utilise pas le protocole HTTPS pour que votre entourage connecté puisse s’immiscer dans votre session et votre intimité.

Les coupables ? Les sites conservant à votre place des éléments de votre vie privée d’une part, et proposant d’autre part et sans la protection du petit cadenas qui dénote de l’utilisation du protocole HTTPS, de « garder votre session ouverte » grâce à un cookie. Si vous y prenez garde, ce n’est pas le cas des services en ligne de votre banque.

Toutefois, si l’auteur est assez pessimiste dans son petit billet complémentaire (reproduit ici à la suite du premier) face aux moyens de protection à notre disposition, il existe plusieurs extensions Firefox pour limiter les risques sans trop se compliquer la vie, citons (sur les bons conseils de Goofy) HTTPS Everywhere, et Force-TSL. De plus, il me semble également assez simple de se connecter, où qu’on soit, d’abord à un VPN personnel, ou directement en SSH sur son serveur à soit (voir l’extension Foxyproxy de Firefox), pour surfer ensuite l’esprit tranquille et sans laisser de traces locales, comme si on était à la maison. D’ailleurs, votre WiFi chez vous, il est protégé comment ?

Quand le berger prévient les moutons à New York City

Herding Firesheep in New York City

Gary LosHuertos – 27 octobre 2010 – TechnologySufficientlyAdvanced.blogspot.com
Traduction Framalang : Goofy, Pablo, cheval_boiteux

On a beaucoup parlé de Firesheep ces derniers jours. Cette extension gratuite pour Firefox récolte pour vous les cookies qui sont envoyés depuis un réseau WiFi non protégé n’utilisant pas le protocole SSL. Vous la mettez en route, elle collecte les cookies de Facebook, Twitter et de 24 autres sites (par défaut). Ensuite, vous pouvez voler l’identité d’un compte et obtenir l’accès sous cette identité.

L’extension n’a rien de scandaleux en elle-même. Si vous êtes un développeur un peu compétent, vous savez depuis longtemps que cette faille existait, n’est-ce pas ? Mais quid du reste du monde ? Tous ces gens qui n’ont jamais entendu parler de cette nouvelle menace si facile d’accès, qui n’ont pas été alertés par leurs amis, qui ne regardent pas Engadget, ni Slashdot, ni ABC Pronews7 à Amarillo ?

Je me suis dit que j’allais faire passer le message et aider les béotiens après leur travail, puisqu’il y a un grand Starbucks tout près de chez moi. J’y suis allé, j’ai acheté un peu de nourriture malsaine, j’ai ouvert mon portable et lancé Firesheep. Moins d’une minute plus tard, j’avais cinq ou six identités disponibles dans le panneau latéral. Trois d’entre elles étaient sur Facebook.

Absolument rien de surprenant ; Firesheep n’est pas magique, et tous ceux qui vont au Starbucks savent qu’un tas de gens y mettent à jour leur statut Facebook sans faire attention, tout en sirotant leur café au lait. J’ai pensé que j’allais y passer un peu plus de temps, j’ai donc écouté un peu de musique, parlé à quelques amis, et le plus important (mais pas le plus simple) je n’ai navigué sur aucun site avec le protocole standard HTTP (et surtout pas sur Facebook évidemment).

Environ une demi-heure plus tard, j’avais récolté entre 20 et 40 identités. Puisque Facebook était de loin le service le plus représenté (et qu’il détient plus d’informations personnelles que Twitter) j’ai décidé d’envoyer aux utilisateurs des messages depuis leur propre compte, pour les avertir des risques auxquels ils s’exposaient. J’ai fait un modèle de message sympa qui précisait la localisation du Starbucks, la nature de la vulnérabilité, et comment y remédier. J’ai envoyé des messages aux 20 personnes autour de moi.

J’ai nettoyé le panneau latéral, retiré mes écouteurs, et j’ai attendu. J’ai entendu quelqu’un marmonner un juron pas très loin, et me suis demandé si mon message en était la cause. Pendant le quart d’heure suivant, je n’ai entendu strictement personne parler de ce qui venait se passer (pourtant ceux qui fréquentent les Starbucks ne sont le plus souvent pas du genre à tenir des conversations discrètes). Pourtant, j’ai pu vraiment constater une nette chute du nombre d’identités que je pouvais récolter quand j’ai relancé Firesheep.

C’était un soulagement — en voilà qui avaient compris le message. Avec un peu de chance, ils allaient alerter leurs amis, mettre à l’abri leur femme et leurs enfants. J’ai de nouveau nettoyé le panneau latéral, et après une vingtaine de minutes de conversations impromptues j’ai vu que cinq identités que j’avais déjà croisées étaient revenues dans mon troupeau.

C’était assez surprenant. Avaient-ils reçu le premier message ? Je me suis mis sur leur compte avec leurs identifiants, et en effet ils l’avaient reçu. L’un d’entre eux était même sur Amazon.com, site contre lequel j’avais mis en garde dans mon premier message. Je l’ai choisi pour première cible : j’ai ouvert sa page perso sur Amazon, j’ai repéré un truc sur lequel il avait récemment jeté un coup d’œil et lui ai envoyé un mot : « non, c’est pas sérieux » sur Facebook depuis son propre compte, avec un clin d’œil sur ses goûts musicaux.

J’ai encore une fois effacé les identités, attendu dix minutes, et lorsque j’ai à nouveau rassemblé mon troupeau avec Firesheep, il était parti. Mais il y en avait encore quatre qui restaient là. Peut-être, me suis-je dit, qu’ils ont cru que c’était un message d’avertissement automatique les ciblant au hasard (bien que j’aie mentionné leur localisation dans un rayon d’une trentaine de mètres). Donc, un dernier message était nécessaire.

J’ai bricolé un très court message (le premier était peut-être trop long ?) et je l’ai envoyé aux quatre, une fois encore avec leur propre compte :

« C’était vraiment pas une blague l’avertissement sur la sécurité. Je n’enverrai plus d’autre message après celui-ci –– à vous de prendre sérieusement en main votre propre sécurité. Vous êtes au Starbucks XYZ connecté de façon non sécurisée, et absolument n’importe qui peut accéder à votre compte avec l’outil approprié nécessaire (et disponible à tous). »

Vingt minutes ont passé, et tous les quatre utilisaient encore Facebook frénétiquement. Encore une fois, j’ai envisagé qu’ils auraient pu ne pas recevoir le message, mais en vérifiant leur compte j’ai vu qu’ils l’avaient bel et bien reçu.

Voilà ce qu’il y a de plus choquant à propos de la sécurité sur Internet : ce n’est pas que nous soyons tous scotchés sur un réseau global qui tient avec des bouts de sparadrap et laisse béants d’horribles failles de sécurité ; ce n’est pas non plus qu’un outil librement disponible puisse récolter des cookies d’authentification ; et ce n’est toujours pas qu’il y ait des gens pas du tout au courant de l’un ni de l’autre. Ce qui est absolument incompréhensible, c’est qu’après avoir été averti d’un danger (et sur son propre compte !) on puisse tranquillement ignorer l’avertissement, et reprendre le fil de ses activités.

Mais enfin j’ai tenu parole et n’ai pas envoyé d’autre message. J’ai rangé mon matériel, fait un petit tour dans le café, et reconnu plusieurs personnes auxquelles j’avais montré leur vulnérabilité. Je n’avais pas laissé d’indices sur ma propre identité, moins par crainte de rétorsion que parce que l’intrusion dans la vie privée est encore plus traumatisante quand elle est commise par un étranger complet, dont on n’a pas la moindre chance de découvrir l’identité.

En revenant chez moi, j’ai réfléchi à ce que cette expérience révélait de notre société. Peu importe le nombre de mesures de sécurité que nous procurons au monde entier, il y aura toujours des gens qui laisseront la porte ouverte, même s’ils ont été victimes d’une intrusion. Le maillon le plus faible de la sécurité c’est et ce sera toujours la décision de l’utilisateur.

De retour dans mon appartement, j’ai commencé à m’installer — et c’est le moment où je me suis rendu compte que pendant toute la soirée j’avais eu la braguette grande ouverte. La preuve par neuf finalement : nous nous baladons tous avec des vulnérabilités qu’il nous reste à découvrir.

Addendum

Herding Firesheep Addendum

Gary LosHuertos – 04 novembre 2010 – TechnologySufficientlyAdvanced.blogspot.com
Traduction Framalang : Siltaar, RaphaelH, Goofy

À la suite du billet précédent, je me suis dit qu’en voulant faire court j’avais omis quelques informations. Ceci sert donc d’addendum à mon précédent billet, et a été rédigé de la manière la plus courte possible.

Le message original envoyés aux clients était le suivant :

Comme vous utilisez Facebook sans chiffrement dans un Starbucks, votre compte a été compromis. Je ne suis qu’un amical client du Starbucks qui a souhaité vous prévenir de cette vulnérabilité.

Vous pouvez en apprendre davantage en cherchant des informations sur « Firesheep ». Il n’y a pas vraiment de solutions disponibles pour protéger votre compte Facebook lorsque vous êtes connectés à un réseau public, et je vous recommande donc simplement de ne pas vous y connecter lorsque vous êtes dans un Starbucks. Cette faille affecte également Twitter, Amazon.com, Google (mais pas Gmail), et quantité d’autres services.

Votre mot de passe n’a pas été compromis. Vous déconnecter de Facebook est tout ce que vous avez besoin de faire.

Pour préciser mes motivations, laisser un compte Facebook sans protection ne signifie pas seulement que quelqu’un peut regarder vos photos, vos coups de cœurs et messages. Un compte Facebook compromis donne à quelqu’un d’autre l’accès à votre identité, lui permettant de se faire passer pour vous auprès de vos amis, ruinant potentiellement des relations. S’il est possible de rattraper les choses ensuite, le temps et l’énergie que ça demande sont importants, surtout pour quelqu’un qui a beaucoup d’amis. Quelqu’un envoyant un faux message à l’un de vos amis n’est peut être pas un gros problème, mais un faux message envoyé à 500 de vos amis est déjà plus gênant. D’autant plus qu’il peut y avoir des collègues de travail, des membres de votre famille, ou des clients dans ces 500 personnes.

Concernant la légalité de mes actions : ça n’était pas l’objet de mon article. On peut toujours spéculer sur fait que je finisse en prison, mais c’est hors sujet par rapport à ce dont je parle dans mon billet : les sites non protégés comme Facebook et Twitter sont dangereux pour leurs utilisateurs. Il semble plus intéressant de consacrer son énergie à faire passer le mot plutôt que de troller sur mon éventuelle incarcération.

Enfin concernant ce que les utilisateurs peuvent faire, la meilleure réponse à l’heure actuelle est : rien. Ne vous connectez pas aux réseaux non protégés pour utiliser ces sites web, ou bien utilisez une application qui n’utilise pas d’authentification par cookie non protégée (pour ce que j’en sais, l’application Facebook pour iPhone ne le ferait pas). Assurez-vous que votre réseau WiFi domestique est chiffré en WPA, voire en WPA2 (le WEP est trivialement déchiffrable). Si vous utilisez Facebook au travail sur une connection sans-fil, vérifiez le chiffrement du réseau. La faille de sécurité ne vient pas seulement de Firesheep, elle vient du manque de protection des connexions. La menace la plus grande vient des outils automatisés qui existent depuis des années [3].

Notes

[1] Crédit : CarbonNYC David Goehring Creative Commons By

[2] Et le sujet ici, n’est pas savoir si cette confiance est bien placée…

[3] Voir la magie des Google Cars expliquées par PCINpact ou ZDNet par exemple…




Le contrôle des redirections

Kudumomo - CC BySi les redirections [1] sont à peu prêt aussi vieilles que le web, elles n’étaient, jusqu’à l’apparition des micro-blogs, que rarement utilisées, mises en place par les connaisseurs, lors du déménagement d’un document important.

Dans ce contexte, quand Kevin Gilbertson proposa en 2002 le premier service en-ligne de rétrécissement d’URL (TinyURL.com), permettant de créer à la demande, une redirection depuis une une adresse courte vers l’adresse de son choix, il n’eut qu’un succès modéré. L’initiative tomba presque dans l’oubli, et ce n’est qu’une demi-décennie plus tard, avec l’essor de Twitter que ce service rencontra d’un coup un large public. En effet, le principe de Twitter étant de proposer un blog dont les billets sont plus courts que des SMS, pouvoir réduire une URL devint un enjeu de taille, si j’ose dire. En effet, d’une part certaines URL sont simplement trop longues pour être gazouillées, et d’autre part, une fois l’adresse collée dans un micro-billet il ne reste plus beaucoup de place pour en expliquer l’intérêt.

TinyURL.com fut donc dans un premier temps directement proposé depuis l’interface du site de microblogage pour aider à la rédaction des messages. Puis devant le succès rencontré par cet intermédiaire, de nombreux concurrents vinrent occuper leurs parts de marché, tel que Bit.ly, qui se démarqua par les statistiques offertes sur l’utilisation des liens courts qu’il produit.

Et progressivement, chaque gros acteur du web se mit à proposer son propre service de rétrécissement, pour faire plaisir à ses utilisateurs avec un service techniquement trivial, ne pas dépendre d’un tiers et enfin pour mettre la main, chacun, sur sa parcelle de statistiques d’usage !

Car utiliser un raccourcisseur d’URL revient en fait à ajouter une barrière de péage d’autoroute entre les personnes auxquelles vous communiquez le lien court, et le document que vous souhaitiez porter à leur attention. Bien sûr, c’est une barrière pour laquelle tout le monde est abonné (pour l’instant), et elle ne fait que ralentir un peu le trafic, mais surtout, elle identifie au passage qui l’a franchi, quand et combien de fois.

Or, si cette information était jusque là collectée par l’émetteur du document de destination seulement, elle n’était pas aussi facilement recoupable et monnayable que si c’est un acteur central qui collecte toutes les visites effectuées suivant les recommandations des millions d’utilisateurs de Twitter, de Facebook ou de Google…

Et puis, d’un point de vue pragmatique, au-delà de la seconde d’attente ajoutée après le clic, ou du respect de la vie privée, un autre problème se pose, celui de la pérennité de ces étapes intermédiaires. Aujourd’hui, TinyURL.com se vante de servir des milliards de redirections par mois, mais ce service, qui n’est pas géré par une entreprise, est voué à disparaître, car son nom (qui avait besoin d’être explicite au début) est trop long pour être efficace aujourd’hui. Or, quand les serveurs de TinyURL seront éteints, c’est plus d’un milliard d’adresses qui, d’un coup, ne mèneront plus à rien.

Alors, quand on voit avec quel empressement les entreprises se sont mises à proposer ce gadget en apparence anodin, on peut avoir envie de ne pas se laisser enfermer nous non plus par une compagnie particulière, de suivre cet exemple en s’installant chacun son raccourcisseur d’URL à soi. Après tout, ça ne sera qu’une corde de plus à mettre à l’arc de la NoBox.

Toutefois, la question de la pérennité des redirections mises en place reste posée… En ce premier novembre, il est presque de bon ton de se demander ce qu’on fera du serveur personnel d’un défunt.

Mais pour l’heure, place au détail de l’enfer des redirections vers lequel on nous mène, et qui transforme progressivement le web en maison qui rend fou des 12 travaux d’Astérix… [2]

Le web se dirige-t-il vers un cauchemar de redirections ?

Is the Web heading toward redirect Hell?

22 septembre 2010 – Royal.Pingdom.com
(Traduction Framalang : Zitor, Barbidule, Daria, Goofy, Siltaar)

Google le fait. Facebook le fait. Yahoo le fait. Microsoft le fait. Et bientôt, Twitter le fera.

Nous parlons de la manie qu’ont tous les services web d’ajouter une étape intermédiaire pour échantillonner ce sur quoi nous cliquons avant de nous envoyer vers notre vraie destination. Ça dure déjà depuis un certain temps, et c’est progressivement en train de devenir un enfer de redirections. Cela a un coût.

Du trafic déjà en trop

Il y a déjà beaucoup de redirections en place, auxquelles vous ne songez pas forcément. Par exemple :

  • Chaque fois que vous cliquez sur un résultat de recherche dans Google ou Bing, il y a un passage obligé par les serveurs du moteur de recherche pour analyse avant d’être redirigé vers le site réellement ciblé;
  • Chaque fois que vous cliquez sur un titre dans un flux RSS Feedburner, vous êtes aussi redirigé avant d’arriver à la véritable cible;
  • Chaque fois que vous cliquez sur un lien sortant de Facebook, il y a une étape intermédiaire passant par un serveur de Facebook avant de vous rediriger vers où vous voulez aller.

Et ainsi de suite, et ainsi de suite, et ainsi de suite. C’est, bien sûr, parce que Google, Facebook et les autres sociétés en ligne aiment suivre les clics et le comportement de leurs utilisateurs. Vous connaître est une vraie ressource pour ces sociétés. Cela peut les aider à améliorer leur service, à le monétiser plus efficacement et dans de nombreux cas, ces données elles-mêmes valent de l’argent. Au final ce suivi de clic peut aussi être bon pour les utilisateurs finaux, en particulier s’il permet à un service d’améliorer sa qualité.

Mais…

Les choses sont en train de déraper

S’il ne s’agissait que d’une seule étape supplémentaire, cela pourrait aller. Mais si vous regardez autour, vous vous rendrez compte que ces redirections sont en train de s’empiler, chaque service interceptant des informations sur le clic lors du cheminement vers la destination finale. Vous savez, celle que l’utilisateur a vraiment demandée.

Cela peut vite devenir incontrôlable. Nous avons vu des scénarios où les liens sortants de Facebook, par exemple, vous redirigent d’abord vers un serveur Facebook, puis vers un racourcisseur d’URL (par exemple bit.ly), qui à son tour vous redirige vers une URL plus longue qui elle-même génère plusieurs redirections avant que FINALEMENT vous parveniez à la cible. Il n’est pas rare qu’il y ait plus de trois redirections vers différents sites qui, du point de vue de l’utilisateur, sont du trafic superflu.

Le problème, c’est que ce trafic supplémentaire n’est pas gratuit. Cela rallonge le temps nécessaire pour atteindre l’objectif, et cela rajoute d’autres liens (au sens propre !) dans la chaîne, ce qui peut la briser ou la ralentir. Cela peut même faire apparaitre des sites comme indisponibles alors qu’ils ne le sont pas, simplement parce que quelque chose sur le chemin est tombé en panne.

Et il semble que cette pratique soit de plus en plus répandue sur le Web.

Un exemple récent de cette « mode de la redirection » : Twitter

Vous souvenez-vous de cette vague de raccourcisseurs d’URL qui est venue quand Twitter a commencé à devenir populaire? C’est là que commence notre histoire.

Twitter a d’abord utilisé le déjà établi TinyURL.com comme raccourcisseur d’URL par défaut. C’était un partenaire idéal pour Twitter et sa limite de 140 caractères par message.

Puis vinrent Bit.ly et une pléthore d’autres raccourcisseurs d’URL, qui voulaient eux aussi surfer sur le succès grandissant de Twitter. Bit.ly a rapidement réussi à remplacer TinyURL comme réducteur d’URL par défaut pour Twitter. Grâce à cela, Bit.ly a mis la main sur une foule de données : la liste d’une bonne partie des liens postés sur Twitter, et de leur popularité, chaque clic pouvant être tracé.

Ce n’était qu’une question de temps avant que Twitter ne veuille garder ces données pour lui seul. Pourquoi s’en priverait-il ? Cela lui permet d’avoir le contrôle total de l’infrastructure nécessaire à son fonctionnement, tout en récupérant des informations sur ce que les utilisateurs aiment s’échanger, et ainsi de suite. Twitter a donc créé récemment son propre raccourcisseur d’URL, t.co. Dans le cas de Twitter, cela peut parfaitement se comprendre.

Cela est bel et bon, mais voici maintenant la partie la plus intéressante qui est la plus pertinente pour cet article : d’ici la fin de l’année, Twitter va rediriger TOUS les liens vers son raccourcisseur d’URL, y compris les liens déjà raccourcis par d’autres services comme Bit.ly ou Goo.gl, le raccourcisseur de Google. En canalisant tous les clics vers ses propres serveurs, Twitter va acquérir une connaissance précise de la façon dont son service est utilisé, et de ses utilisateurs. Cela lui donne le contrôle total sur la qualité de son service. C’est une bonne chose pour Twitter.

Mais qu’arrive-t-il quand tout le monde veut un morceau du gâteau ? Redirection après redirection après redirection avant d’arriver à notre destination ? Oui, c’est exactement ce qui se passe, et vous aurez à vivre avec ce trafic supplémentaire.

Voici ce à quoi le partage de liens pourrait ressembler une fois que Twitter aura commencé à soumettre tous les clics à son propre service :

  1. Quelqu’un partage un lien goo.gl sur Twitter, il est alors transformé en un lien t.co.
  2. En cliquant sur le lien t.co, l’utilisateur est alors redirigé vers les serveurs de Twitter pour convertir le lien t.co en lien goo.gl et se voit réorienté dessus.
  3. Le lien goo.gl dirige l’utilisateur vers les serveurs de Google pour y être résolu et ré-orienter enfin l’utilisateur vers la cible qu’il souhaitais atteindre.
  4. Rien n’empêche cette cible de n’être à son tour qu’une nouvelle redirection…

Vous en avez la tête qui tourne, hein ?

Encore plus de niveaux de redirection ?

Il y a un an, nous avons écrit un article sur les inconvénients potentiels des raccourcisseurs d’URL, et il s’applique parfaitement à ce scénario plus général avec de multiples redirections entre les sites. Les conséquences de ces redirections sur les performances, la sécurité et la confidentialité sont les mêmes.

Nous soupçonnons fortement que le chemin pris par Twitter (échantillonner et enregistrer les clics avant expédition vers la cible, avec ou sans raccourcisseurs d’URL) laisse présager des pratiques à venir chez les autres services Web qui ne le font pas déjà.

Et même quand les services principaux ne le font pas, de plus en plus d’intermédiaires et d’applications tierces, comme les raccourcisseurs d’URL, apparaissent tous les jours. L’autre jour, le fabricant d’antivirus McAfee a annoncé la version-bêta de McAf.ee, un raccourcisseur d’URL « sécurisé ». C’est peut-être super, qui sait, mais à la lumière de ce que nous vous avons dit dans cet article, il est difficile de ne pas penser : quoi, encore une autre niveau de redirection ? Est-ce vraiment vers cela que le Web évolue ? Est-ce vraiment ce que nous voulons ?

Notes

[1] Ce mécanisme du protocole HTTP permettant de faire rebondir la navigation vers une autre page au chargement d’une URL.

[2] Crédit photo : Kudumomo (Creative Commons Parternité)




Geektionnerd : Twittic Fail

Avec un peu de retard cette semaine, voici le traditionnel billet Geektionnerd, qui revient cette fois sur le « virus » d’un nouveau genre ayant frappé le site web Twitter.com la semaine dernière.

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Cette faille de sécurité se matérialisait par un « tweet », donc un message textuel de 140 caractères maximum, perdu dans le flot des autres messages du genre sur le site Twitter.com, et ne comportant dans sa partie visible que des cases noires à la place des lettres. Bien loin d’êtres inquiétantes, ces cases noires attisaient la curiosité des lecteurs, car de nombreux tweets artistiques profitent en effet des possibilités offertes par Unicode pour afficher des dessins, des partitions de musique ou encore cacher des messages… Seulement là, au survol des cases noires par la souris, un code JavaScript en partie embarqué dans le tweet s’exécutait, postant le tweet malicieux sur votre compte à votre place, et exposant ainsi vos amis. Le « virus » s’est alors répandu très vite, et jusque sur le compte Twitter de Framasoft…

Moralité, en tant que défenseur du logiciel libre, Framasoft vous recommande de suivre son compte Identi.ca plutôt que son compte Twitter 🙂

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)