Bien malin celui qui parvient à deviner quelles sont les failles affectant les systèmes Apple en ne s'appuyant que sur les dernières alertes de l'éditeur-constructeur. Sûr qu'avec un tel déluge d'information (sans « s », c'est un déluge à goutte unique), il est aisé de prétendre que jamais système ne fut aussi solide. Les esprits chagrins peuvent à la rigueur aller glaner quelques données sur le At Stake ou quelque part du côté de eEye. Les références CAN mentionnées, quant à elles, ne sont pas très explicites. Apple possède un noyau d'une fiabilité certaine, tout le monde en convient. Est-ce une raison pour refuser à ses propres usagers une information pleine et entière lorsqu'une paille vient se glisser dans l'oeil du Mac ? Ajoutons que le succès de la pomme auprès des auteurs de virus et troyens semble très moyen... on ne prête qu'aux riches. La crainte d'une « exploitation » ou d'un « reverse engeenering » utilisant des informations par trop détaillées n'est donc ni une excuse, ni une explication. Ni un argument d'ailleurs. Car ce n'est pas dans un communiqué MS ou une alerte ISS que les chimistes du code trouvent la source de leurs inspirations... mais bel et bien dans le code lui-même. Dis, Monsieur Steeve, la prochaine fois, tu pourrais les faire plus diserts, tes communiqués d'alerte ? Car, en minimisant ce genre d'information à la limite du perceptible, se profile l'ombre d'un autre danger : l'anonymat et la banalisation du défaut de sécurité. Dans un monde où le battage médiatique est hélas bien souvent le seul indicateur « subjectif » de dangerosité, cet obscur silence qui descend du HQ risque d'être interprété par beaucoup comme un signe de « risque bénin ». Et se croire protégé est, en matière de hacking, bien plus dangereux que de se sentir vulnérable.

. Web-profils.com, la place de marché du conseil et de l'ingénierie