Le House Homeland Security Committee demande au patron de l’entreprise fautive de s’engager à venir au Congrès des États-Unis pour y être entendu. Il devra s’expliquer sur les causes de la panne, les mesures d’atténuation mises en place et les actions prises pour éviter un nouvel épisode, comme le rapporte le Washington Post.
The Verge publie la lettre du comité :
« Bien que nous appréciions la réponse de CrowdStrike et sa coordination avec les parties prenantes, nous ne pouvons pas ignorer l'ampleur de cet incident, qui, selon certains, est la plus grande panne informatique de l’histoire. Reconnaissant que les Américains ressentiront sans aucun doute des conséquences durables et réelles de cet incident, ils méritent de savoir en détail comment il s'est produit et les mesures d'atténuation prises par CrowdStrike ».
Le comité laisse jusqu’à mercredi pour planifier une audience.
Entre les vols annulés, ceux retardés, les opérations médicales reportées, les appels au 911 perturbés et les « nombreux autres impacts », le Comité demande des comptes. The Verge rappelle que lundi, trois jours après la mise à jour défaillante, Delta était toujours victime d’écrans bleus et de perturbations sur son trafic aérien.
CrowdStrike a donné des détails techniques, mais il manque encore des précisions sur comment cette mise à jour a pu causer de tels dégâts.
Commentaires (29)
#1
Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.
En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.
Bref, une idée d'article ^^
[edit]
Pour aller plus loin dans l'idée d'article, aborder aussi la notion de compétence. Un client français peut-il attaquer un éditeur américain par exemple ? Si oui, dans quelle condition ? Car par exemple, si l'éditeur américain ne cible que les Etats-Unis, mais que le petit client français achète quand même la solution, c'est radicalement différent de l'éditeur qui va se prendre un .fr, monter un site en français, avoir une filiale en France et faire payer en euro. Et si on inverse les rôles ? Si c'est un éditeur français qui veut être poursuivi par un client américain ? Quel est la juridiction compétente ?
Historique des modifications :
Posté le 23/07/2024 à 08h40
L'heure de rendre des comptes arrive. J'espère que partout dans le monde cela fait être un peu la même histoire, car le problème n'est pas resté cloisonné aux Etats-Unis.
Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.
En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.
Bref, une idée d'article ^^
#1.1
Pour les législations c'est généralement par pays ou par zone comme pour l'europe, tout dépends le domaine que ça recouvre.
#1.2
#1.3
[edit] Rajout de la partie en italique.
Historique des modifications :
Posté le 23/07/2024 à 10h23
Par exemple. Même si les conséquences n'étaient pas du tout les mêmes. D'un côté, c'était plutôt l'exfiltration de données. De l'autre, l'arrêt complet, que l'on pourrait presque assimilé à un DOS !
#2
En gros, ce serait en partie de la faute de l'Europe que ce fisco ait pu prendre une telle ampleur, du point de vue de Microsoft. Un accord européen de 2009 obligerait Microsoft à accorder les mêmes droits aux solutions tierces de sécurité pour des raisons de concurrence. Microsoft n'aurait donc pas pu verrouiller autant qu'il le souhaitait le noyau de Windows, en tout cas, pas sans violer cette accord visant à favoriser la libre concurrence...
Point de vue intéressant qui ouvre d'autres perspectives.
#2.1
#2.2
On oblige une solution à ouvrir ses APIs pour la concurrence qui a ouin-ouin qu'il leur fallait une interface très bas niveau avec le système et qu'il faut leur accorder LE MÊME NIVEAU que l'éditeur (mais sans les compétences), concurrence qui déploye sans tester alors que des programmes existent pour ce genre de situation, mais c'est la faute de Microsoft.
N'oublions pas que CWD a déjà fait planté d'autres systèmes, seulement c'était moins visible.
Tu me diras, ce message est au niveau des campagnes marketings de CWD extrêmement aggressives / insultantes, notamment sur LinkedIn.
#2.3
Après, est-ce qu'il ne manque pas de culot ? Je ne dirai pas ça. Vu la couverture médiatique et le manque de professionnel d'un grand nombre de journaliste sur le sujet, qui ont titré, à tord, que la faute incombait à une mise à jour de Windows, j'ai presque envie de dire que c'est normal que Microsoft se défende.
Ils se prennent des critiques de toute part, notamment sur le soi-disant manque de sécurité de Windows (il n'y a qu'à regarder les commentaires sur les articles parlant de Crowdstrike sur Next ces derniers jours pour s'en convaincre).
Si fermer le coeur du noyau implique de se prendre un procès pour abus de position dominante, la société est sensée faire quoi ? On peut ne pas être d'accord, mais je trouve que rappeler que la solution n'est pas qu'un problème technique fait tout à fait sens, surtout dans le contexte actuel.
Anecdote : un client me demandait une fois de mettre en place une fonctionnalité. En tant que consultant externe, je suis "aux ordres" de mon client. Mais je l'ai prévenu : s'il voulait cette fonctionnalité à tout prix, je lui ferai signer une décharge comme quoi je l'avais prévenu que la sécurité de la solution serait amoindri, que je l'avais prévenu, qu'il avait décidé de passer outre mon avertissement et d'en assumer ainsi l'entière responsabilité. Bizarrement, j'ai jamais eu ce papier signé et jamais eu à mettre en place cette fonctionnalité ^^
#2.4
Concernant la news MS-EU, on peut comprendre la communication de Microsoft quand on voit, comme tu l'as dit, le nombre d'articles sur cet accident: je n'ai quasiment pas vu un seul titre sans les mots "panne de Microsoft".
J'ai vu aussi des comparaisons avec les problèmes en automobile de pièces défectueuses, comme encore récemment (et à plusieurs reprises) des défauts sur les airbags: on pointe la responsabilité de l'assembleur et moins celle de l'équipementier, alors que c'est l'assembleur qui doit se taper la campagne de rappel (et ses frais) ainsi que la communication.
Ici, désolé, mais Microsoft n'est pas (pour ce que j'en sais) distributeur/intégrateur du produit de Crowdstrike et ne le fournit pas aux clients concernés.
Et comme d'autres l'ont également indiqué ici, si on avait eu ce problème (et ça serait déjà le cas) avec d'autres OS, je suis convaincu qu'on aurait pas vu des titres similaires.
Historique des modifications :
Posté le 23/07/2024 à 09h59
Je partage ton avis, confronté à la même situation à plusieurs reprises.
Aussi, on peut comprendre la communication de Microsoft quand on voit, comme tu l'as dit, le nombre d'articles sur cet accident: je n'ai quasiment pas vu un seul titre sans les mots "panne de Microsoft".
J'ai vu aussi des comparaisons avec les problèmes en automobile de pièces défectueuses, comme encore récemment (et à plusieurs reprises) des défauts sur les airbags: on pointe la responsabilité de l'assembleur et moins celle de l'équipementier, alors que c'est l'assembleur qui doit se taper la campagne de rappel (et ses frais) ainsi que la communication.
Ici, désolé, mais Microsoft n'est pas (pour ce que j'en sais) distributeur/intégrateur du produit de Crowdstrike et ne le fournit pas aux clients concernés.
Et comme d'autres l'ont également indiqué ici, si on avait eu ce problème (et ça serait déjà le cas) avec d'autres OS, je suis convaincu qu'on aurait pas vu des titres similaires.
#2.5
Microsoft était donc partie prenante de l'accord et avait accepté les termes.
Ils auraient pu soit refuser simplement l'accord et subir l'enquête en se défendant lors de celle-ci en expliquant que donner l'accès au noyau pouvait entraîner des plantages. Si la Commission leur avait quand-même imposé l'accès au noyau sans contrôle, là, leur discours sur le sujet aurait été entendable.
Ils auraient aussi pu proposer à la Commission une autre solution permettant la concurrence tout en gardant le contrôle de ce qui se passe dans le noyau : soit en offrant des API en userspace permettant de surveiller tout ce qui est nécessaire pour ce genre d'outil et évidement utiliser les mêmes interfaces pour ses propres outils ; ils pouvaient aussi probablement limiter ce qui tournait dans le noyau en reportant la plus grosse partie du code de ces outils là aussi en userspace en imposant un audit (éventuellement indépendant) du code des concurrents.
Ils ont largement amélioré la situation des écrans bleus en imposant des règles et certifications pour les drivers (WHQL), ils pouvaient à mon avis faire la même chose sur ce sujet.
#2.6
màj : J’en profite puisque @fdorin et @fred42 sont là tous les deux pour un message perso. Si vous voulez toujours qu’on se fasse une petite rencontre sur LR (ou les environs) on peut se programmer ça en aout (je vous laisse me contacter par email ? Sebastien at nom du site, ou nom de l’ancien site comme vous voulez
Historique des modifications :
Posté le 23/07/2024 à 10h21
Une actu arrive sur Next :) (avec une confirmation de Microsoft)
#2.7
Au sujet du message perso : toujours partant. C'est juste compliqué depuis quelques mois niveau timing et j'avoue que je n'ai pas mis les pieds à La Rochelle depuis des lustres donc yes, ça me tente bien à la rentrée, quand les touristes seront partis. Et autre détail : je suis "sans voiture" actuellement. J'ai une C3 victime des airbags Takata...
#2.8
#2.9
J'ai bien lu grâce à @fdorin, faites moi signe, je suis en théorie le plus disponible.
#2.22
la notif est envoyée seulement au premier mentionné dans le message, et même en édition ça renotifie pas si on ajoute un @
ça avait été remonté dans le poingdev (12 je crois) lors de la mise en place
#2.23
@fred42 : test en édition du commentaire.
Édit2 : pas reçu la notification ajoutée lors de l'édit précédent.
Historique des modifications :
Posté le 25/07/2024 à 14h08
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Posté le 25/07/2024 à 14h09
Merci. J'avais un doute en écrivant mon commentaire, donc j'ai préféré signaler.
@fred42 : test en édition du commentaire.
Édit2 : pas reçu la notification ajoutée lors de l'édit précédent.
#2.24
#2.10
Une autre solution pour Ms, plutôt que de permettre (forcer) n'importe quelle solution de sécurité (hum - y compris les gestionnaires de DRM) à devenir des rootkits, ça aurait été de mettre SA solution de sécu au niveau des autres au lieu de la mettre dans le noyau... Ou de la partager, si c'est le noyau...
Ou de rendre les solutions plugables dans Hyper-V si on veut un genre de rootkit...
N'importe quel spécialiste pourrait démonter cet argument je pense.
Historique des modifications :
Posté le 24/07/2024 à 06h51
Et qui a forcer Linux et BSD à abaisser leur sécu pour que les solutions de sécurité soient au même niveau ?
Une autre solution pour Ms, plutôt que de permettre (forcer) n'importe quelle solution de sécurité (hum - y compris les gestionnaires de DRM) à devenir des rootkits, ça aurait été de mettre SA solution de sécu au niveau des autres au lieu de la mettre dans le noyau... Ou de la partager, si c'est le noyau...
Ou de rendre les solutions plugables dans Hyper-V si on veut un genre de rootkit...
N'importe quel spécialiste pourrait démonter cet argument je pense.
#2.11
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).
Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).
Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.
Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.
Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)
Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.
L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.
[edit]
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.
Je suppose que c'est parce que le système avait le temps de booter entièrement.
Historique des modifications :
Posté le 24/07/2024 à 08h44
A mon avis, c'est loin d'être aussi simple. Pour créer une API spécifique :
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).
Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).
Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.
Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.
Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)
Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.
L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.
#2.13
Mauvaise idée dans ce contexte très précis; des machines business-critical qui tout d'un coup n'ont plus aucune protection et se retrouvent en réseau ? ça aurait été encore plus catastrophique, et Microsoft aurait quand même été vu comme coupable par les semi-habiles qui ne lisent que les titres de journaux.
#2.14
- démarrer normalement
- démarrer en mode sans échec
- démarrer en mode sans échec avec prise en charge réseau
- ouvrir une console
etc.
Mais sinon oui, tu as tout à fait raison : un démarrage en mode sans échec sans intervention de l'utilisateur, c'est une mauvaise idée.
#2.15
2 points :
- je ne suis pas sûr de comprendre ce que tu veux dire : tu parles en même temps d'espace noyau et espace utilisateur.
- je ne suis pas sûr que la lecture du fichier de configuration se fasse en espace noyau. On n'a pas l'info, mais je pense que ce n'est pas une pratique habituelle qu'un driver (Windows ou autre) qui tourne en espace noyau lise un fichier (de configuration ici). L'architecture habituelle est qu'un logiciel dans l'espace utilisateur (un service de pilote , si j'ai bien compris le vocabulaire Microsoft) lise le fichier de conf, le décode et fasse un appel au driver pour passer la (nouvelle) configuration. J'ai tendance à penser que c'est plutôt cela qui s'est passé, mais que la nouvelle configuration était mauvaise et que le module l'a utilisée sans de contrôle.
Ça ne changer rien au résultat final quel que soit l'endroit où s'est fait le décodage du fichier.
#2.16
L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)
L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.
Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.
L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.
Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).
J'espère avoir été plus clair ;)
Historique des modifications :
Posté le 24/07/2024 à 10h33
Alors je vais essayer d'éclaircir.
L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)
L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.
Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.
L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.
Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).
#2.17
Quand on oppose espace noyau (kernel tout court en anglais) et espace utilisateur (user space), il ne s'agit que du mode dans lequel tournent les programmes, pas du système de fichiers.
Même si les articles Wikipédia sont assez sommaires, surtout en français, mais ils sont assez clairs sur ce point.
#2.20
Je pensais que le contexte général suffirait à comprendre. Il semblerait que non. Mea culpa.
#2.18
Par ailleurs, le noyau Windows a largement évolué: la compatibilité des anciennes applis reste du haut niveau - assez peu dépendant du noyau en fait même si s'appuyant sur certains mécanismes.
Hyper-V est actif sur de nombreux ordis et un Windows qui héberge WSL n'est pas tout à fait un hôte (cf le fait que la gestion d'énergie et d'autres subtilités sautent sur beaucoup de config si hyper-v est actif) - oui, Hyper-V est bien SOUS l'instance Windows qui tourne et a le privilège d'accéder au clavier physique et à la partie graphique. D'ailleurs, plusieurs solutions de sécu de MS sont basées sur l'activation de cette virtualisation.
Sans parler de toutes les sondes intégrées - Windows est un OS plutôt ouvert sur le suivi, avec une structure commune.
Il y a certainement des TONNES de solutions autres. Ms a certainement choisi celle qui l'arrangeait le plus pour fustiger ce qu'on lui a imposé. On a vu assez de rootkits avant même la demande de l'europe pour savoir qu'il y a des solutions pour s'intercaler sous l'OS dans le noyau et surveiller les applis. Cf les anticheats et DRM.
Pour le redémarrage en mode sans échec, il existe, et aurait dû se déclencher. Je pense que le pilote falcon déclare avoir démarré AVANT d'avoir lu la config et planté - dans le cas d'un pilote qui n'arrive pas à démarrer, Windows peut le virer automatiquement. Ou alors Crowdstrike a fait en sorte que justement on ne puisse pas désactiver le pilote en bidouillant les fichiers - auquel cas je reviens au produit Falcon qui devrait se mettre en mode sécu tout seul et isoler proprement le poste avec une manip pour se reconnecter.
#2.12
Historique des modifications :
Posté le 24/07/2024 à 08h51
Personne n'a forcé Linux ou BSD puisque leur éditeur ne propose pas sa propre solution de sécurité, en plus de ne pas être en position dominante.
Posté le 24/07/2024 à 08h51
Personne n'a forcé Linux ou BSD puisque leur "éditeur" ne propose pas sa propre solution de sécurité, en plus de ne pas être en position dominante.
#2.19
#2.21