programLyrique a écrit 54 commentaires

En effet.

J'avais envoyé le mail dont je parle fin Février.

Sinon, il y a quelques détails sur leur site dans un message daté du 25 Avril :

Part of these funds are planned to go towards buying the perks we promised our donors. We will be distributing surveys to our donors shortly to make sure which perks they want. Then we will budget accordingly.

We know donors have been waiting for their perks for a long time. We sincerely apologize for the long delay in perk fulfillment.

Peu après, les news sur l'avancée du travail de Redfox s'interrompent. L'équipe de développement communique peu sur le sujet, le reste de la communauté s'interroge. On apprendra quelques mois plus tard que Redfox a décidé de ne plus travailler sur le projet, car il a retrouvé du travail ailleurs, et que la période de travail que lui proposait Wildfire Games à l'issue de la levée de fonds lui semblait trop courte.

En effet, la communication de l'équipe a été plutôt catastrophique.

J'ai moi-même fait un don, et nous étions censés recevoir les perks en Décembre.
Les recevoir plus tard ou même pas du tout ne me gêne pas, mais j'aurais aimé être mis au courant (je leur avais envoyé un mail pour plus de renseignements, vue l'absence d'infos sur leur site, mais la réponse était plutôt du genre succincte).

Hulu a l'air de faire autrement :

FAQ d'Hulu :

Many companies use Virtual Private Networks (VPNs) or Virtual Private Servers (VPS) to monitor and secure their employees’ Internet traffic. Since they typically route all their Internet traffic through a central server, our system may determine that these are anonymous proxies. If you are having trouble accessing Hulu while using your work computer, you may want to contact your company’s network administrator for additional help.

On dirait qu'ils se basent sur le nombre de connexions venant d'une même IP.

d'autres vont même jusqu'à bloquer les VPN (comme Hulu récemment)

Comment peut-on bloquer les VPN ?

Avec une liste de VPN, et on bloque les IPs associés ? Dans ce cas, si on veut vraiment regarder, on se paye un serveur aux Etats-Unis et on s'en sert de VPN.

Ou on peut détecter qu'un serveur quelconque joue le rôle d'un VPN ( ce qui me parait étonnant ) ?

J'avais assisté à une conférence d'un chercheur en sécurité qui affirmait qu'il n'était pas sûr que cela permette de nous identifier car les diverses informations fournies pour créer une signature du visiteur changent, et ceci plutôt souvent. Par exemple, à chaque fois qu'on met à jour son navigateur, on correspond à un nouveau visiteur, idem pour les plugins.

Ainsi, la stratégie qui consisterait à choisir un ensemble de caractéristiques aléatoires pour les informations recueillies par panopticlick est déjà implémentée, en quelque sorte, sur nos machines.

Détrompe-toi :

Si toi tu es prêt à payer plus cher, d'autres ne le sont pas.

Si d'autres sont prêts à payer moins cher quitte à avoir une moins bonne sécurité, d'autres ne le sont pas.

le compromis choisis par la majorité des gens n'est pas le tien

Ha bon ? Celui de privilégier la sécurité ? Tu as des chiffres ?
J'ai comme l'impression que tu n'as pas vraiment compris ma remarque et que tu n'as pas lu ma dernière phrase :

Cependant, Burps indique de façon convaincante que ce n'est pas que pour des raisons de performance qu'on utilise
l'assembleur, mais aussi pour éviter des attaques, donc ça parait bien plus justifié d'utiliser l'assembleur.

A partir du moment où l'assembleur permet d'obtenir une meilleure sécurité, c'est un bon choix. Si en plus, il permet d'avoir de meilleures performances et de réduire les coûts, c'est encore mieux.

Il n'est pas sûr en plus qu'utiliser une implémentation avec des failles de sécurité permettent de réduire les coûts in fine, s'il faut rembourser des utilisateurs floués, mettre à jour les programmes et l'infrastructure, restaurer des sauvegardes, voir l'image de l'organisation complètement détruite devant les utilisateurs.
Avant d'affirmer de façon péremptoire que ça va coûter plus cher ou moins cher (tu as peut-être raison), moi, je préfère étudier la question plus en détails.

Je ne suis pas sûr de comprendre ta remarque… je me contentais de faire une remarque théorique, et aucunement de proposer à tout le monde d'utiliser une implémentation prouvée et générée à partir de Coq d'AES.

Oui, on peut effectivement implémenter AES avec C, Java ou Ocaml, et oui, ce sera effectivement moins rapide qu'en ASM.

Une comparaison plus adéquate aurait été entre descendre de la tour Effel en sautant en parachute (risqué) ou par les escaliers (moins risqué mais plus lent) - et il y a un compromis… les ascenseurs- .
Ainsi, si utiliser un langage de plus haut niveau avec des garantis statiques fortes apportait plus de confiance dans l'implémentation, personnellement, je préfèrerais utiliser utiliser cette implémentation qu'une implémentation très rapide ; peu m'importe que me loguer sur le site de ma banque prenne du temps, mais qu'on puisse faire des virements bancaires à partir de mon compte à mon insu, par contre, ça me gênerait…

Cependant, Burps indique de façon convaincante que ce n'est pas que pour des raisons de performance qu'on utilise l'assembleur, mais aussi pour éviter des attaques, donc ça parait bien plus justifié d'utiliser l'assembleur.

Ils font quand même l'hypothèse assez forte qu'il y a un processus malveillant sur le même ordinateur, qui fonctionne en même temps que le programme de chiffrement.

unprivileged process to attack other processes running in parallel on the same processor,
despite partitioning methods such as memory protection, sandboxing and virtualization.

Dans les contremesures, ils parlent aussi d'autres solutions qu'utiliser l'extension Intel pour activer un no-fill mode, ou l'implémentation bitslice.

Il y a quelques contre mesures qui ne nécessitent pas de coder en assembleur, à première vue : section 5.2, alternative lookup tables, 5.3 (pour le dernier paragraphe), 5.4, these countermeasures […] are algorithmic en rajoutant des transformations aléatoires etc…

Bref, comme les auteurs le rappellent, les méthodes qui n'utilisent pas l'assembleur sont :

significantly slower in software than a bitslice implementation

Encore une question de performance, non ?

Parce que quand tu fais de la crypto tu dois faire de l'assembleur.

Non, c'est juste pour avoir de meilleures performances que c'est fait en assembleur.

On peut très bien implémenter AES en C, en Java, ou en OCaml. Ce que tu montres est le support d'une extension Intel pour accéléer AES, ce qui n'est absolument pas indispensable pour faire de la crypto.

Par ailleurs, on peut mettre de l'assembleur inline dans du code Rust (dans un bloc unsafe) :

Rust release notes

Je serais moi aussi heureux de pouvoir utilisé OCaml !

Difficulté technique pour le mettre en place, ou manque de demandes des utilisateurs ?

Le binding OCaml de LLVM est maintenant plus complet et couvre l'ensemble des bibliothèques LLVM.

J'espère que les erreurs de segmentation intempestives qui avaient lieu lorsqu'on compilait un code invalide ont été supprimées, pour laisser place à quelque chose de plus informatif…

Le jeu 0ad utilise Spidermonkey, par exemple.

Je ne vois pas de mention de Visa (sauf dans un commentaire), mais d'American Express et de MasterCard dans le lien indiqué. Et le partenariat avec Facebook concerne l'entreprise Acxiom…

Donc soit ce que tu dis est une belle exagération, soit tu t'es trompé de source, soit tu devrais rajouter une source qui indique que Visa a des liens avec Acxiom…

Il parait que ces nouveaux connecteurs ne sont pas compatibles avec les anciens.

On va pouvoir nous vendre des adaptateurs entre les connecteurs, ou nous convaincre de racheter des matériels compatibles…

Oui, pour Israël. Cependant, dans le descriptif sur le site des régions, ils n'en parlent pas, donc je pense que c'est une exception.

Pour l'UPC, c'est tout à fait vrai. J'ai malencontreusement confondu les sigles…

Oui, en effet.

Je connais, mais justement, ça a l'air un projet (prometteur) mort.

Alors, je me contente d'un éditeur hexadécimal. Le développeur de wxHexEditor avait l'air partant pour améliorer son système de tags pour qu'il puisse être appliqué sur plusieurs fichiers à la fois.

Ca a l'air surtout fait pour analyser des exécutables ; est-ce que c'est aussi adapté à l'analyse de formats de fichier dont les spécifications sont inconnues ? Par exemple, peut-on afficher des sortes de masque de fichier pour souligner la structure d'un fichier, pour ensuite plus facilement faire des comparaisons ?

Certes, l'Ircam ne publie pas tous ces logiciels sous licence libre, mais je ferais remarquer qu'OpenMusic est opensource, et ceci depuis le début de son existence, depuis 1998.

Et il y aussi, pour regarder en différé, des vidéos sur le site de l'Ircam mais j'ai l'impression qu'il n'y a pas tout dessus.

Toutes les conférences et séminaires de l'Ircam sont filmés et accessibles en direct ici.

Et je parlais de types linéaires, mais en fait, ce qui est particulier à ATS, c'est les types dépendants. Là, je crois que Rust n'en possède pas.

Ha oui, en effet.

Les deux langages ont donc encore plus de points communs que je ne le pensais.

Et donc, pourquoi choisir Rust et pas ATS , ou le contraire, dans ce cas ?

Comment se positionne Rust par rapport à un langage qui est un peu sur le même créneau système, ATS ?

J'ai l'impression que ATS fait comme Rust, mais qu'ATS, lui, a intégré les nouveaux concepts des 15 dernières années (types linéaires, par exemple).

Ouais, ok. Mais la version non béta est sortie il y a quelques mois à peine.

Et j'utilise Ardour réguliérement, et j'ai testé la gestion du midi. C'est pas mal, mais ce n'est pas encore complet, et encore (mais c'est mon avis), pas complètement utilisable en production.

Est-ce que la création, l'enregistrement de la musique du film va utiliser des logiciels libres ?

D'habitude, c'est le point un peu honteux et le dernier îlot de résistance du propriétaire dans ce genre de projets.

Pourtant, Ardour sur Linux est un logiciel très sérieux pour faire de l'enregistrement multipiste, et il commence même à se doter d'un support des pistes MIDI…