Merci, excellent ! Ça se lit comme un roman.
Quelle affaire complètement délirante…
Outre l'intérêt financier ou le complot d'Intel, une autre théorie qui circule ici et là est encore plus abracadabrante.
Elle postule que, les processeurs Intel basés sur Core ayant été conçus en Israel, on pourrait imaginer qu'ils contiennent une backdoor exigée par les services secrets israéliens, lesquels auraient alors tout intérêt à nuire à AMD, pour éviter que ses processeurs non compromis se répandent.
J'avoue que vu le niveau d'hallucination atteint, cela me semble pas plus absurde que le reste.
Je te rejoins, ça semble important. TRÈS important.
Pas tellement pour les failles qui ont quand même l'air assez mineures et réclament de toute façon des conditions assez strictes d'exécution (accès physique, flashage, root local), mais pour l'épée de Damoclès qui va tous nous menacer si les chercheurs en sécurité se transforment en malfrats ou en mercenaires qui ne respectent pas les "responsible disclosure" et font tout pour exploiter à fond financièrement leurs trouvailles, aidés en cela par des médias en mal de sensation et de clics.
Imaginez une seconde ce qui se serait passé si Meltdown avait été monté en épingle comme ça et lâché en zéro-day ? 8-|
ça aurait été un cataclysme économique majeur !
Je ne vois pas comment nos sociétés peuvent se prémunir contre un tel risque :-(
Oui, l'action a initialement chuté de 4% quand la nouvelle est parue, mais les investisseurs semblent avoir décidé que tout ça n'était pas très sérieux, que c'était même carrément trop gros.
Je ne sais pas s'ils ont "raté" leur coup dans la mesure où il suffit que l'action passe par un minimum, même pendant quelques minutes, pour générer un profit substantiel.
Cela pourrait être coordonné par exemple avec une rumeur qui a circulé il y a quelques jours concernant un rachat d'AMD et qui a pendant quelques minutes fait monter le cours de l'action de 8%.
Le différentiel d'avec aujourd'hui devient de l'ordre de 13%, ce qui est déjà pas mal comme rendement.
On ne peut pas tout à fait exclure non plus que tout cela soit une campagne de dénigrement orchestrée par Intel pour contrer le succès d'EPYC et la mauvaise presse liée à Meltdown.
Mais ces derniers temps, Intel semble avoir bien besoin d'AMD pour contrer Nvidia…
Tout sent l'arnaque à plein nez dans cette histoire.
Le directeur de cette boite israélienne inconnue jusqu'ici dirige aussi le hedge fund NineWells qui a de grosses positions "short" sur AMD (autrement dit : ils font un bénéfice si l'action baisse).
Ils larguent un zéro day avec moins de 24h de préavis mais ils ont eu le temps de peaufiner des sites spécialisés avec nom de domaine, vidéos et tout le toutim ?
Le "whitepaper" est écrit comme un spam africain, il n'y a aucun détail, les noms des vulnérabilités sont stupidement dramatiques et reprennent les marques déposées d'AMD (Ryzenfall, sérieusement ?), il contient des remarques visant à discréditer AMD sans aucun rapport avec le sujet.
Il n'y a même pas de CVE associée, c'est du vent.
Tenez, regardez ce qu'il y a d'écrit, perdu dans le fatras légal à la fin du rapport :
"Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports."
"Bien que nous croyions notre analyse de bonne foi et croyons qu'elle est objective et non biaisée, vous êtes avertis que nous pourrions, soit directement, soit indirectement, avoir un intérêt économique dans la performance des actions des compagnies dont les produits sont le sujet de nos rapports."
Mon dieu mon dieu mon dieu, et tout le monde relaye ces idioties ;-/
Oui, je pense que tu as raison, c'est écrit noir sur blanc :
"La micro-architecture AMD n'autorise pas les références mémoires, y compris les références spéculatives, à accéder à des données d'un niveau de privilège supérieur depuis un mode d'exécution moins privilégié, si cet accès devait provoquer une erreur de page."
Franchement, c'est parfaitement clair. Je le traduis juste parce qu'apparemment, ça n'a pas été bien compris par tout le monde.
De ce fait, peu importe que des instructions continuent ou non d'être exécutées spéculativement : il n'y a pas de fuite de données. CQFD.
Ça c'est bien pour l'éducation des jeunes !
A quand la libération de Click'N Play… je pourrais enfin voir à quoi rimaient ces 8 pages qu'on devait se taper dans TILT tous les mois…
PEBKAC ? Un mélange à proportion diverse d'ignorance, de je m'en-foutisme et d'incompétence ? Voire illetrisme rampant qui pousse à éviter de lire les notices ?
Le référençage est le fait de scans automatiques par des robots. Ils détectent simplement un serveur web fonctionnel à cette adresse.
Certaines sont quand même mises à disposition de manière délibérées, d'autres sont protégées par mot de passe.
non, pour ma part je parlais bien de la livebox et il n'y a pas besoin d'accès physique, voir scénario complet plus haut.
Mais peut-être que la sécurité a été changée depuis que ce scénario a été testé (pas par moi, bien sûr) - en 2011.
c'est bien à moi que tu réponds ? en fait je parlais d'une connexion Wifi
Le scénario complet est le suivant:
1) acquérir le code par une attaque classique style aircrack
2) configurer statiquement la carte avec une ip probablement déjà attribuée (192.168.0.x, etc..) et tâcher de se connecter à l'interface du routeur (le filtrage des adresses MAC ne s'applique qu'à l'attribution d'ip par DHCP) - ce n'est pas très fiable mais devrait marcher.
3) utiliser les mots de passe par défaut et ajouter les MAC de son choix à la liste des connexions autorisées pour obtenir une ip en bonne et dû forme.
et si j'emploie des tournures hypothétiques, c'est pour me garantir du texte de loi recopié plus bas..
elles sont non seulement connectées par erreur sur le net, souvent avec toute leur interface de commande à distance, mais aussi référencées dans les moteurs.
Il suffit de chercher par exemple 'inurl:CgiStart?page=Single' chez google pour avoir une vue saisissante du monde du travail tel que vu par les Panasonics.
Tiens là j'ai une fille en train de bosser sur un microscope électronique..
il est vrai que les Livebox ont cette sécurité où, quand bien même on disposerait du code cryptographique, elles n'attribuent pas d'ip tant que la MAC de l'impétrant n'est pas dans leur base de donnée - ce que madame Michu peut faire seule grâce à une sorte de bouton magique de 'pairage', d'après ce qu'on m'a dit.
Toutefois, il serait peut-être possible, muni du dit code crypto, de s'attribuer statiquement une ip qu'on pourrait deviner comme étant déjà attribuée par cette machine, et ainsi se connecter au dit routeur avec les dits codes par défaut, et ajouter innocemment sa MAC à la liste des machines autorisées.
Auquel cas, le mot de passe par défaut du routeur aurait quand même très nettement affaibli la sécurité de l'ensemble.. '
Je t'ai traduit un extrait d'interview dans le commentaire au-dessus, mais je peux juste te resituer un contexte, c'est ça l'histoire, une question de perspectives, personne ne détient la vérité ultime et il faut souvent savoir lire entre les lignes.
Comme c'était précieux, on allait sûrement pas faire exprès de bouffer de la ressource…
non, l'idée était de ne pas te laisser la possibilité de bouffer de la ressource, parce que ce serait tellement peu pratique que le faire serait absurde. J'ai fait une analogie avec la petite cuiller qu'on laisse aux prisonniers : ils peuvent parfaitement s'en servir pour manger, mais s'ils veulent s'évader, ça va les faire chier, c'est fait exprès !
Donc si tu veux juste brider les possibilités, tu vas les faire chier, et peut-être nous faire chier en faisant des pages moins réactives avec les limitations que tu veux mettre.
Elles ne seraient pas moins réactives. L'idée (JavaScript == vitesse du web) est une construction marketing des années 2006 par Google qui voulait ses applications lourdes : il faut savoir que tout n'est pas accélérable dans la pile de standards constituée par les navigateurs. Depuis bien longtemps, aux environs de 2006 d'ailleurs, ce n'est pas JavaScript qui est le facteur limitant, mais l'arborescence DOM, qui n'est pas parallélisable, et qu'il faut bien parcourir, et l'arbre de rendu du document avec son arbre de styles CSS associé. Tout cela est au maximum de vitesse depuis des années, et ne peut évoluer que si de nouveaux standards émergent.
99% de tout ce qui se fait sur le web en dehors des applis lourdes (pour lesquelles l'utisateur pourrait faire des exceptions à la manière de NoScript) peut se faire avec 1% de la vitesse JS, sans différence de vitesse effective puisque tout ce qui est vraiment interactif visuellement est bridé par le DOM. Cela éviterait les spoliations de CPU qui sont le fait de programmeurs incompétents ou de l'accumulation de strates de frameworks.
Cela rétabirait 'équilibre entre les différents standards, et entre client et serveurs : on éviterait de faire en JS ce qu'on peut parfaitement construire côté serveur mais qu'il est simplement devenu plus rentable de faire sur le client, ou ce qu'on peut carrément implémenter statiquement en CSS 3.
En gros, il me semble qu'il est urgent de recentrer le Web sur le statique, et de refaire de l'applicatif une exception.
Mais ça n'est que mon avis (j'avoue, je suis biaisé, j'ai bossé 8 ans sur le moteur de rendu de Konqueror - j'exècre ce que Google a fait du Web)
Non, j'ai parfaitement compris ta phrase, mais tu mets trop de poids dans la mienne : il était important que JS soit lent pour pouvoir exister au départ, pour pouvoir être adopté comme langage embarqué, et il n'y avait absolument aucun projet de l'accélérer un jour.
On parle ici d'une décision historique, c'est-à-dire d'un contexte, de besoins précis, d'une idée qu'on se faisait de la chose naissante qu'était le web - du respect de l'équilibre client/serveur et de leurs ressources respectives.
Bien sûr que Brendan Eich ne s'est pas regardé dans la glace le matin en se demandant comment rendre ses constructions syntaxiques les plus lentes possibles. Il n'en avait pas besoin parce que de toute manière, implémenter un langage lent était ce qu'il y avait de plus rapide à faire - il ne faut pas oublier que tout ça se passe sur un coin de table, à toute allure, chez Netscape. Mais cette lenteur arrangeait tout le monde, parce qu'elle rassurait sur la non-exploitabilité du langage. Cela devait rester un jouet aux yeux des "programmeurs sérieux".
Il aurait été complètement impensable d'interfacer un langage puissant avec le DOM, sans aucun garde-fou, alors que c'était la chose la plus simple à faire - ils auraient parfaitement pu passer un arrangement pour interfacer Java plus directement puisqu'ils étaient cul et chemise avec Sun, mais tout le monde les aurait pris pour des fous.
Tout comme on laisse une petite cuiller à des prisonniers, mais pas un marteau piqueur, parce qu'on se dit qu'il leur faudra quand même un bout de temps pour creuser un tunnel, JS était intentionnellement lent.
Je te traduits un bout d'interview de Eich pour infoworld (comme ça, je réponds aussi indirectement à la demande de citation de source, plus bas) :
"
InfoWorld: Dans quel but avez-vous développé JavaScript ?
Eich: L'idée était de faire quelque chose que les développeurs Web, des gens qui n'avaient pas forcément beaucoup d'expérience de la programmation, pourraient utiliser pour ajouter un tout petit peu d'animation, ou un tout petit peu d'interactivité, à leurs formulaires et à leurs pages Web.
Bon, on est en 1995, le Web en est à ses premiers balbutiements. HTML en était à 3.2, je crois, ou quelque chose d'approchant. Les gens n'avaient pas beaucoup de programmabilité à disposition. Java arrivait au même moment mais ça demandait d'apprendre un langage de programmation sophistiqué, puis de faire tourner un compilateur et de mettre votre code dans un paquet qui devenait une applet qui faisait alors partie de la page, mais qui était dans un petit silo. Il était entouré de murs en quelque sorte.
Et puis c'était dur—c'était pour les programmeurs professionnels. On pensait que c'était pour faire les visites virtuelles d'agences immobilières ou des trucs puissants comme ça. Alors que JavaScript, c'était juste 3 lignes que vous pouviez écrire, que vous pouviez copier sur quelqu'un, et que vous pouviez apprendre sur le tas. Vous n'aviez pas à apprendre tout le langage pour l'utiliser - ça pouvait se faire au coup par coup.
Cette idée était apprement défendue par Marc Andreessen et moi-même. Bill Joy, de chez Sun, était son plus ardent défenseur, ce qui était utile parce que c'est comme ça qu'on a trouvé le nom. Et on le promouvait comme le petit frère de Java, un langage complémentaire, un peu ce que Visual Basic était au C++ dans la gamme des langages de Microsoft à l'époque. Et ça a pris. Et on l'a sorti à temps.
"
Bon j'ai bien mouillé la chemise là :-)
Je pensais que tout ça était encore bien connu, mais je m'aperçois que l'idée moderne du web déforme beaucoup celle qu'on se fait de ses origines.
que JavaScript a été pensé pour être lent, faut pas déconner
c'est pourtant exactement le cas. Pour les besoins computationnels sérieux, il y avait Java sous forme d'applet - bardé de sécurités.
On parle d'une époque ou la moindre ressource CPU était précieuse, je vois pas ce qui te surprend.
Et qui y gagnerait au fait ?
si ton navigateur te laissait allouer un certain pourcentage de CPU maximum dévolu au JS, contrôlé par usleep, avec des exceptions paramétrables,
tu y gagnerais que ton système ne ramerait plus pour 3 pauvres onglets, on y gagnerait tous que les devs Webs cesseraient progressivement de mettre 1 Mo de scripts sur la moindre page, et les fournisseurs de contenu y gagneraient qu'on cesserait peut-être tous d'utiliser NoScript pour survivre.
Les pages Web utilisent les ressources de ta machine comme bon leur semble et tu n'as aucun moyen de savoir à l'avance comment.
Le seul moyen que tu aies d'éviter ça, c'est de désactiver le javascript avec quelque chose comme NoScript, et le web n'est presque plus fonctionnel comme cela tellement les pages reposent abusivement sur cet environnement d'exécution.
eh bien voilà, l'UI de ton navigateur a l'air de répondre normalement, mais en fait tous tes CPU sont maxés, exploités sans que tu aies été consulté, pour faire des calculs arbitraires.
Bien sûr dans ce cas, c'est juste pour une démo, et la page te met gentiment au courant de ce qu'elle fait..
mais oui, mais précisément, voilà ! Il est devenu complètement impossible de se passer de moyens de désactiver sélectivement le javascript dès qu'on a une navigation de quelques dizaines d'onglets : c'est quelque chose qui était complètement impensable il n'y a pas même 5 ans. Et ça c'est pour une raison toute simple : le javascript s'exécute beaucoup plus rapidement et incite donc les dévelopeurs à en abuser. C'est toujours la vieille histoire software becomes slower faster than hardware becomes faster.
Après, dire qu'il faut pas rendre JS plus rapide car JS ça bouffe du CPU, c'est pas très cohérent
Mais si, c'est cohérent : au départ, la lenteur de JS était intentionnelle, c'était un outil limité, destiné à rendre quelques services programmatiques, mais en évitant de rendre les ressources du client intéressantes pour le serveur.
Maintenant, qu'on veuille rendre JS plus efficace, qu'on le JIT, qu'on l'optimise pour qu'il bouffe moins de cycles pour une même tâche, c'est très bien, mais il devrait être limité en vitesse d'exécution par défaut (avec un mécanisme de réglage facile pour les applis exigeantes, voire une api standard pour demander ce genre de permission) et faire des petits usleep(3) des familles pour ne pas rendre ton système rentable à exploiter.
Tout le monde serait gagnant et tu n'aurais pas à faire tout ça manuellement avec ton plugin NoScript qui te casse 98% des sites par défaut - ce qui est quand même un hack incroyable !
La transparence des sources ? je pense que ça te fait une belle jambe quand la plupart du JS est camouflé, compressé, utilise un framework lourd qui change complètement la sémantique, ou n'est plus qu'un bytecode illisible issu d'un des innombrables compilateurs depuis le langage X..
Quant à la différence entre "utilisation malveillante" et "transfert d'une partie des calculs des serveurs aux clients", ce n'est qu'une question de point de vue - c'est à dire que c'est exactement la même chose.
Aujourd'hui même, il est impossible de laisser 50 onglets ouverts sur des sites parfaitement banals sans mettre un octo coeur à genoux, tout cela parce que les acteurs de l'industrie ont transformé à dessein le JS en outil d'annexion des ressources de calcul individuelles. Ça n'a donc rien d'une vue de l'esprit ou d'une projection dans l'avenir.
Améliorer la vitesse d'exécution de JS, ou sa parallélisation, sous quelque angle que ce soit, ne fait qu'empirer une situation déjà désastreuse en rendant la déportation des calculs sur le client toujours plus rentable.
la Crimée est très jolie, mais c'est pas la plus goûteuse des noires…
je recommande plutôt la Charbonneuse de Russie (j'en ai 25 pieds au semoir)
:-|°°
Pour le pire. L'entreprise d'accélération de JS lancée par Apple à partir de 2005 est une abomination.
Naviguer sur une page revient maintenant, grâce à des gens de bonne volonté comme toi, qui prennent prétexte de l'extension de ce fléau pour l'aggraver, à faire de ses processeurs autant de noeuds potentiels d'un supercalculateur dont personne ne peut rien savoir.
N'importe quel amateur peut mettre en place un réseau distribué de Web Workers transparents (cf. http://blog.0x82.com/2010/11/22/map-crowd-reduce/), qui asservit peut-être toutes les ressources de ta machine, pour ce que tu en sais, au programme nucléaire iranien ou pire encore, à l'élaboration du prochain Stephenie Meyer.
Donc, plutôt que de poursuivre tes investigations dans ce sens, je t'encourage à te tourner vers des tâches collectivement utiles et éthiquement recevables, comme la lutte contre cet état de fait - ou à défaut, vers la culture des tomates (la noire de russie est succulente).
# else's
Posté par spart . En réponse au journal Stallman chez Microsoft: Azure is just someone else computer. Évalué à 8.
Le génitif. Apostrophe S, ou S apostrophe au pluriel. C'est important.
[^] # Re: juste une arnaque
Posté par spart . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 4.
Merci, excellent ! Ça se lit comme un roman.
Quelle affaire complètement délirante…
Outre l'intérêt financier ou le complot d'Intel, une autre théorie qui circule ici et là est encore plus abracadabrante.
Elle postule que, les processeurs Intel basés sur Core ayant été conçus en Israel, on pourrait imaginer qu'ils contiennent une backdoor exigée par les services secrets israéliens, lesquels auraient alors tout intérêt à nuire à AMD, pour éviter que ses processeurs non compromis se répandent.
J'avoue que vu le niveau d'hallucination atteint, cela me semble pas plus absurde que le reste.
[^] # Re: juste une arnaque
Posté par spart . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 2.
Je te rejoins, ça semble important. TRÈS important.
Pas tellement pour les failles qui ont quand même l'air assez mineures et réclament de toute façon des conditions assez strictes d'exécution (accès physique, flashage, root local), mais pour l'épée de Damoclès qui va tous nous menacer si les chercheurs en sécurité se transforment en malfrats ou en mercenaires qui ne respectent pas les "responsible disclosure" et font tout pour exploiter à fond financièrement leurs trouvailles, aidés en cela par des médias en mal de sensation et de clics.
Imaginez une seconde ce qui se serait passé si Meltdown avait été monté en épingle comme ça et lâché en zéro-day ? 8-|
ça aurait été un cataclysme économique majeur !
Je ne vois pas comment nos sociétés peuvent se prémunir contre un tel risque :-(
[^] # Re: juste une arnaque
Posté par spart . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 6.
Oui, l'action a initialement chuté de 4% quand la nouvelle est parue, mais les investisseurs semblent avoir décidé que tout ça n'était pas très sérieux, que c'était même carrément trop gros.
Je ne sais pas s'ils ont "raté" leur coup dans la mesure où il suffit que l'action passe par un minimum, même pendant quelques minutes, pour générer un profit substantiel.
Cela pourrait être coordonné par exemple avec une rumeur qui a circulé il y a quelques jours concernant un rachat d'AMD et qui a pendant quelques minutes fait monter le cours de l'action de 8%.
Le différentiel d'avec aujourd'hui devient de l'ordre de 13%, ce qui est déjà pas mal comme rendement.
On ne peut pas tout à fait exclure non plus que tout cela soit une campagne de dénigrement orchestrée par Intel pour contrer le succès d'EPYC et la mauvaise presse liée à Meltdown.
Mais ces derniers temps, Intel semble avoir bien besoin d'AMD pour contrer Nvidia…
# juste une arnaque
Posté par spart . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 10.
Tout sent l'arnaque à plein nez dans cette histoire.
Le directeur de cette boite israélienne inconnue jusqu'ici dirige aussi le hedge fund NineWells qui a de grosses positions "short" sur AMD (autrement dit : ils font un bénéfice si l'action baisse).
Ils larguent un zéro day avec moins de 24h de préavis mais ils ont eu le temps de peaufiner des sites spécialisés avec nom de domaine, vidéos et tout le toutim ?
Le "whitepaper" est écrit comme un spam africain, il n'y a aucun détail, les noms des vulnérabilités sont stupidement dramatiques et reprennent les marques déposées d'AMD (Ryzenfall, sérieusement ?), il contient des remarques visant à discréditer AMD sans aucun rapport avec le sujet.
Il n'y a même pas de CVE associée, c'est du vent.
Tenez, regardez ce qu'il y a d'écrit, perdu dans le fatras légal à la fin du rapport :
"Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports."
"Bien que nous croyions notre analyse de bonne foi et croyons qu'elle est objective et non biaisée, vous êtes avertis que nous pourrions, soit directement, soit indirectement, avoir un intérêt économique dans la performance des actions des compagnies dont les produits sont le sujet de nos rapports."
Mon dieu mon dieu mon dieu, et tout le monde relaye ces idioties ;-/
[^] # Re: Bug (ou fonctionnalité ?)
Posté par spart . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 4.
Oui, je pense que tu as raison, c'est écrit noir sur blanc :
"La micro-architecture AMD n'autorise pas les références mémoires, y compris les références spéculatives, à accéder à des données d'un niveau de privilège supérieur depuis un mode d'exécution moins privilégié, si cet accès devait provoquer une erreur de page."
Franchement, c'est parfaitement clair. Je le traduis juste parce qu'apparemment, ça n'a pas été bien compris par tout le monde.
De ce fait, peu importe que des instructions continuent ou non d'être exécutées spéculativement : il n'y a pas de fuite de données. CQFD.
# Zswap
Posté par spart . En réponse au journal Fini Firefox, vive Midori !. Évalué à 4.
Il peut suffire d'activer zswap.
# Excellent
Posté par spart . En réponse à la dépêche Les coulisses du standard C++. Évalué à 4. Dernière modification le 22 août 2016 à 18:49.
hahahaha merci à toute l'équipe pour cette excellente vanne, you made my day :'-) :'-)
-Spart, programmeur C++ expatrié en Hongrie depuis un an,
toujours au stade csecsemő après 18h de hongrois par semaine
# Bravo !
Posté par spart . En réponse à la dépêche Libération de Livecode via un financement participatif. Évalué à 5.
Ça c'est bien pour l'éducation des jeunes !
A quand la libération de Click'N Play… je pourrais enfin voir à quoi rimaient ces 8 pages qu'on devait se taper dans TILT tous les mois…
allons bon j'ai encore perdu ma canne.
[^] # Re: LiveBOX
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 0.
je crois bien que c'était une WPA-TKIP, dans le test auquel j'ai assisté. Ca avait quand même pris plusieurs heures en tout cas.
[^] # Re: Houston, we have a problem !
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 1.
PEBKAC ? Un mélange à proportion diverse d'ignorance, de je m'en-foutisme et d'incompétence ? Voire illetrisme rampant qui pousse à éviter de lire les notices ?
Le référençage est le fait de scans automatiques par des robots. Ils détectent simplement un serveur web fonctionnel à cette adresse.
Certaines sont quand même mises à disposition de manière délibérées, d'autres sont protégées par mot de passe.
[^] # Re: LiveBOX
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 0.
non, pour ma part je parlais bien de la livebox et il n'y a pas besoin d'accès physique, voir scénario complet plus haut.
Mais peut-être que la sécurité a été changée depuis que ce scénario a été testé (pas par moi, bien sûr) - en 2011.
[^] # Re: LiveBOX
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 2.
c'est bien à moi que tu réponds ? en fait je parlais d'une connexion Wifi
Le scénario complet est le suivant:
1) acquérir le code par une attaque classique style aircrack
2) configurer statiquement la carte avec une ip probablement déjà attribuée (192.168.0.x, etc..) et tâcher de se connecter à l'interface du routeur (le filtrage des adresses MAC ne s'applique qu'à l'attribution d'ip par DHCP) - ce n'est pas très fiable mais devrait marcher.
3) utiliser les mots de passe par défaut et ajouter les MAC de son choix à la liste des connexions autorisées pour obtenir une ip en bonne et dû forme.
et si j'emploie des tournures hypothétiques, c'est pour me garantir du texte de loi recopié plus bas..
[^] # Re: Houston, we have a problem !
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 9.
or a Million Webcams,
elles sont non seulement connectées par erreur sur le net, souvent avec toute leur interface de commande à distance, mais aussi référencées dans les moteurs.
Il suffit de chercher par exemple 'inurl:CgiStart?page=Single' chez google pour avoir une vue saisissante du monde du travail tel que vu par les Panasonics.
Tiens là j'ai une fille en train de bosser sur un microscope électronique..
[^] # Re: LiveBOX
Posté par spart . En réponse au journal un nmap d'un fort beau gabarit.. Évalué à 2.
il est vrai que les Livebox ont cette sécurité où, quand bien même on disposerait du code cryptographique, elles n'attribuent pas d'ip tant que la MAC de l'impétrant n'est pas dans leur base de donnée - ce que madame Michu peut faire seule grâce à une sorte de bouton magique de 'pairage', d'après ce qu'on m'a dit.
Toutefois, il serait peut-être possible, muni du dit code crypto, de s'attribuer statiquement une ip qu'on pourrait deviner comme étant déjà attribuée par cette machine, et ainsi se connecter au dit routeur avec les dits codes par défaut, et ajouter innocemment sa MAC à la liste des machines autorisées.
Auquel cas, le mot de passe par défaut du routeur aurait quand même très nettement affaibli la sécurité de l'ensemble.. '
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 1.
J'ai développé plus haut dans le fil, depuis ton message :-)
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 1.
Je t'ai traduit un extrait d'interview dans le commentaire au-dessus, mais je peux juste te resituer un contexte, c'est ça l'histoire, une question de perspectives, personne ne détient la vérité ultime et il faut souvent savoir lire entre les lignes.
Comme c'était précieux, on allait sûrement pas faire exprès de bouffer de la ressource…
non, l'idée était de ne pas te laisser la possibilité de bouffer de la ressource, parce que ce serait tellement peu pratique que le faire serait absurde. J'ai fait une analogie avec la petite cuiller qu'on laisse aux prisonniers : ils peuvent parfaitement s'en servir pour manger, mais s'ils veulent s'évader, ça va les faire chier, c'est fait exprès !
Donc si tu veux juste brider les possibilités, tu vas les faire chier, et peut-être nous faire chier en faisant des pages moins réactives avec les limitations que tu veux mettre.
Elles ne seraient pas moins réactives. L'idée (JavaScript == vitesse du web) est une construction marketing des années 2006 par Google qui voulait ses applications lourdes : il faut savoir que tout n'est pas accélérable dans la pile de standards constituée par les navigateurs. Depuis bien longtemps, aux environs de 2006 d'ailleurs, ce n'est pas JavaScript qui est le facteur limitant, mais l'arborescence DOM, qui n'est pas parallélisable, et qu'il faut bien parcourir, et l'arbre de rendu du document avec son arbre de styles CSS associé. Tout cela est au maximum de vitesse depuis des années, et ne peut évoluer que si de nouveaux standards émergent.
99% de tout ce qui se fait sur le web en dehors des applis lourdes (pour lesquelles l'utisateur pourrait faire des exceptions à la manière de NoScript) peut se faire avec 1% de la vitesse JS, sans différence de vitesse effective puisque tout ce qui est vraiment interactif visuellement est bridé par le DOM. Cela éviterait les spoliations de CPU qui sont le fait de programmeurs incompétents ou de l'accumulation de strates de frameworks.
Cela rétabirait 'équilibre entre les différents standards, et entre client et serveurs : on éviterait de faire en JS ce qu'on peut parfaitement construire côté serveur mais qu'il est simplement devenu plus rentable de faire sur le client, ou ce qu'on peut carrément implémenter statiquement en CSS 3.
En gros, il me semble qu'il est urgent de recentrer le Web sur le statique, et de refaire de l'applicatif une exception.
Mais ça n'est que mon avis (j'avoue, je suis biaisé, j'ai bossé 8 ans sur le moteur de rendu de Konqueror - j'exècre ce que Google a fait du Web)
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à -4.
Non, j'ai parfaitement compris ta phrase, mais tu mets trop de poids dans la mienne : il était important que JS soit lent pour pouvoir exister au départ, pour pouvoir être adopté comme langage embarqué, et il n'y avait absolument aucun projet de l'accélérer un jour.
On parle ici d'une décision historique, c'est-à-dire d'un contexte, de besoins précis, d'une idée qu'on se faisait de la chose naissante qu'était le web - du respect de l'équilibre client/serveur et de leurs ressources respectives.
Bien sûr que Brendan Eich ne s'est pas regardé dans la glace le matin en se demandant comment rendre ses constructions syntaxiques les plus lentes possibles. Il n'en avait pas besoin parce que de toute manière, implémenter un langage lent était ce qu'il y avait de plus rapide à faire - il ne faut pas oublier que tout ça se passe sur un coin de table, à toute allure, chez Netscape. Mais cette lenteur arrangeait tout le monde, parce qu'elle rassurait sur la non-exploitabilité du langage. Cela devait rester un jouet aux yeux des "programmeurs sérieux".
Il aurait été complètement impensable d'interfacer un langage puissant avec le DOM, sans aucun garde-fou, alors que c'était la chose la plus simple à faire - ils auraient parfaitement pu passer un arrangement pour interfacer Java plus directement puisqu'ils étaient cul et chemise avec Sun, mais tout le monde les aurait pris pour des fous.
Tout comme on laisse une petite cuiller à des prisonniers, mais pas un marteau piqueur, parce qu'on se dit qu'il leur faudra quand même un bout de temps pour creuser un tunnel, JS était intentionnellement lent.
Je te traduits un bout d'interview de Eich pour infoworld (comme ça, je réponds aussi indirectement à la demande de citation de source, plus bas) :
"
InfoWorld: Dans quel but avez-vous développé JavaScript ?
Eich: L'idée était de faire quelque chose que les développeurs Web, des gens qui n'avaient pas forcément beaucoup d'expérience de la programmation, pourraient utiliser pour ajouter un tout petit peu d'animation, ou un tout petit peu d'interactivité, à leurs formulaires et à leurs pages Web.
Bon, on est en 1995, le Web en est à ses premiers balbutiements. HTML en était à 3.2, je crois, ou quelque chose d'approchant. Les gens n'avaient pas beaucoup de programmabilité à disposition. Java arrivait au même moment mais ça demandait d'apprendre un langage de programmation sophistiqué, puis de faire tourner un compilateur et de mettre votre code dans un paquet qui devenait une applet qui faisait alors partie de la page, mais qui était dans un petit silo. Il était entouré de murs en quelque sorte.
Et puis c'était dur—c'était pour les programmeurs professionnels. On pensait que c'était pour faire les visites virtuelles d'agences immobilières ou des trucs puissants comme ça. Alors que JavaScript, c'était juste 3 lignes que vous pouviez écrire, que vous pouviez copier sur quelqu'un, et que vous pouviez apprendre sur le tas. Vous n'aviez pas à apprendre tout le langage pour l'utiliser - ça pouvait se faire au coup par coup.
Cette idée était apprement défendue par Marc Andreessen et moi-même. Bill Joy, de chez Sun, était son plus ardent défenseur, ce qui était utile parce que c'est comme ça qu'on a trouvé le nom. Et on le promouvait comme le petit frère de Java, un langage complémentaire, un peu ce que Visual Basic était au C++ dans la gamme des langages de Microsoft à l'époque. Et ça a pris. Et on l'a sorti à temps.
"
Bon j'ai bien mouillé la chemise là :-)
Je pensais que tout ça était encore bien connu, mais je m'aperçois que l'idée moderne du web déforme beaucoup celle qu'on se fait de ses origines.
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à -6.
que JavaScript a été pensé pour être lent, faut pas déconner
c'est pourtant exactement le cas. Pour les besoins computationnels sérieux, il y avait Java sous forme d'applet - bardé de sécurités.
On parle d'une époque ou la moindre ressource CPU était précieuse, je vois pas ce qui te surprend.
Et qui y gagnerait au fait ?
si ton navigateur te laissait allouer un certain pourcentage de CPU maximum dévolu au JS, contrôlé par usleep, avec des exceptions paramétrables,
tu y gagnerais que ton système ne ramerait plus pour 3 pauvres onglets, on y gagnerait tous que les devs Webs cesseraient progressivement de mettre 1 Mo de scripts sur la moindre page, et les fournisseurs de contenu y gagneraient qu'on cesserait peut-être tous d'utiliser NoScript pour survivre.
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 1.
Qui exploite ta machine et pourquoi ?
Je comprends presque pas ta question.. ;-(
Les pages Web utilisent les ressources de ta machine comme bon leur semble et tu n'as aucun moyen de savoir à l'avance comment.
Le seul moyen que tu aies d'éviter ça, c'est de désactiver le javascript avec quelque chose comme NoScript, et le web n'est presque plus fonctionnel comme cela tellement les pages reposent abusivement sur cet environnement d'exécution.
Tu veux un exemple concret, on va prendre encore les Web Workers parce que c'est frappant :
- ouvre cet URL en 4 ou 5 exemplaires dans des onglets d'un navigateur récent :
http://extremelysatisfactorytotalitarianism.com/projects/experiments/2010/03/boxdemo/
- coche la case marqué "11" dans chaque onglet.
eh bien voilà, l'UI de ton navigateur a l'air de répondre normalement, mais en fait tous tes CPU sont maxés, exploités sans que tu aies été consulté, pour faire des calculs arbitraires.
Bien sûr dans ce cas, c'est juste pour une démo, et la page te met gentiment au courant de ce qu'elle fait..
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à -1.
C'est vrai que quand on utilise NoScript
mais oui, mais précisément, voilà ! Il est devenu complètement impossible de se passer de moyens de désactiver sélectivement le javascript dès qu'on a une navigation de quelques dizaines d'onglets : c'est quelque chose qui était complètement impensable il n'y a pas même 5 ans. Et ça c'est pour une raison toute simple : le javascript s'exécute beaucoup plus rapidement et incite donc les dévelopeurs à en abuser. C'est toujours la vieille histoire software becomes slower faster than hardware becomes faster.
Après, dire qu'il faut pas rendre JS plus rapide car JS ça bouffe du CPU, c'est pas très cohérent
Mais si, c'est cohérent : au départ, la lenteur de JS était intentionnelle, c'était un outil limité, destiné à rendre quelques services programmatiques, mais en évitant de rendre les ressources du client intéressantes pour le serveur.
Maintenant, qu'on veuille rendre JS plus efficace, qu'on le JIT, qu'on l'optimise pour qu'il bouffe moins de cycles pour une même tâche, c'est très bien, mais il devrait être limité en vitesse d'exécution par défaut (avec un mécanisme de réglage facile pour les applis exigeantes, voire une api standard pour demander ce genre de permission) et faire des petits usleep(3) des familles pour ne pas rendre ton système rentable à exploiter.
Tout le monde serait gagnant et tu n'aurais pas à faire tout ça manuellement avec ton plugin NoScript qui te casse 98% des sites par défaut - ce qui est quand même un hack incroyable !
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 2.
La transparence des sources ? je pense que ça te fait une belle jambe quand la plupart du JS est camouflé, compressé, utilise un framework lourd qui change complètement la sémantique, ou n'est plus qu'un bytecode illisible issu d'un des innombrables compilateurs depuis le langage X..
Quant à la différence entre "utilisation malveillante" et "transfert d'une partie des calculs des serveurs aux clients", ce n'est qu'une question de point de vue - c'est à dire que c'est exactement la même chose.
Aujourd'hui même, il est impossible de laisser 50 onglets ouverts sur des sites parfaitement banals sans mettre un octo coeur à genoux, tout cela parce que les acteurs de l'industrie ont transformé à dessein le JS en outil d'annexion des ressources de calcul individuelles. Ça n'a donc rien d'une vue de l'esprit ou d'une projection dans l'avenir.
Améliorer la vitesse d'exécution de JS, ou sa parallélisation, sous quelque angle que ce soit, ne fait qu'empirer une situation déjà désastreuse en rendant la déportation des calculs sur le client toujours plus rentable.
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 1.
la Crimée est très jolie, mais c'est pas la plus goûteuse des noires…
je recommande plutôt la Charbonneuse de Russie (j'en ai 25 pieds au semoir)
:-|°°
# soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 5.
Pour le pire. L'entreprise d'accélération de JS lancée par Apple à partir de 2005 est une abomination.
Naviguer sur une page revient maintenant, grâce à des gens de bonne volonté comme toi, qui prennent prétexte de l'extension de ce fléau pour l'aggraver, à faire de ses processeurs autant de noeuds potentiels d'un supercalculateur dont personne ne peut rien savoir.
N'importe quel amateur peut mettre en place un réseau distribué de Web Workers transparents (cf. http://blog.0x82.com/2010/11/22/map-crowd-reduce/), qui asservit peut-être toutes les ressources de ta machine, pour ce que tu en sais, au programme nucléaire iranien ou pire encore, à l'élaboration du prochain Stephenie Meyer.
Donc, plutôt que de poursuivre tes investigations dans ce sens, je t'encourage à te tourner vers des tâches collectivement utiles et éthiquement recevables, comme la lutte contre cet état de fait - ou à défaut, vers la culture des tomates (la noire de russie est succulente).
[^] # Re: Hm
Posté par spart . En réponse au journal [Tu es prof de physique ????? -> ]Pymecavideo sort en version 6.1. Évalué à 1. Dernière modification le 18 février 2013 à 02:04.
Non, puisqu'il s'agit d'une faute de graphie, et pas d'une faute de syntaxe.
C'est donc une faute d' orthographe d'accord