Tests automatisés

Les services hébergés (catégories avec type: service) sont testés automatiquement lorsque leur fichier d'évaluation contient un domain. Les fournisseurs d'e-mail et les services de transfert qui ont un mail_domain font aussi l'objet d'un test e-mail.

Normes de l'e-mail

Les fournisseurs d'e-mail et les services de transfert qui ont un mail_domain font aussi l'objet de ces tests, exécutés par scripts/mail-tests.js :

Les noms de serveur proviennent de imap_host, pop3_host et smtp_host dans le fichier d'évaluation, ou des enregistrements SRV RFC 6186 du fournisseur. Définissez un hôte à false lorsque le fournisseur ne propose pas ce protocole. Les capacités sont ce que chaque serveur annonce avant la connexion, et les listes complètes sont affichées sur chaque page d'évaluation.

Traceurs des sites web

Chaque entrée qui a un site web, applications comprises, fait l'objet d'un test de traceurs exécuté par scripts/trackers.js. Il charge la page d'accueil sans exécuter JavaScript et compare chaque hôte de script, de cadre, d'image et de feuille de style, ainsi que le code en ligne, à une liste de services connus de pistage et de mesure d'audience.

Lorsque le site web est une page d'hébergeur de code ou de boutique d'applications (GitHub, GitLab, Codeberg, SourceForge, F-Droid, Google Play et similaires), le test est ignoré, car cette page n'est pas gérée par le projet.

Le test ne voit que les traceurs écrits dans la page elle-même. Les traceurs ajoutés ensuite par des scripts, et la télémétrie à l'intérieur des applications, nécessitent toujours des preuves dans le fichier d'évaluation, comme une politique de confidentialité ou un rapport Exodus Privacy.

SRS et ARC ne peuvent pas être observés de l'extérieur sans envoyer de courrier ; ce sont donc des critères auxquels on répond avec des preuves plutôt que par des tests.

Les vérifications automatisées qui n'ont pas encore été exécutées s'affichent comme « Pas encore testé » et sont exclues du score, de sorte qu'un fournisseur n'est jamais pénalisé pour un test qui n'a pas eu lieu.

Pour SSL Labs, la note la plus faible parmi toutes les adresses IP d'un domaine est retenue.

Hardenize ne propose plus d'API publique ; chaque page renvoie donc à son rapport public au lieu de le noter.

Calendrier

Le workflow Scan s'exécute chaque jour et teste les 40 entrées dont les résultats sont les plus anciens (Internet.nl suit ses propres limites, voir ci-dessous), de sorte que chaque service est testé régulièrement sans surcharger les API gratuites. Les résultats sont enregistrés dans scans/ au format JSON, commités dans le dépôt et publiés avec le site. Chaque page indique quand ses tests ont été exécutés pour la dernière fois.

Un test en échec conserve le résultat précédent et enregistre l'erreur, pour qu'une panne temporaire ne modifie pas un score.

Limites d'Internet.nl

L'API par lots d'Internet.nl est utilisée dans le respect de ses conditions d'utilisation :

• Au plus 2 requêtes par lots sur toute période de 7 jours. Le test du site web et le test de la messagerie sont des requêtes distinctes, donc une série complète utilise les deux.
• Au plus 5000 domaines par requête. Quand davantage de domaines ont le test, ceux dont les résultats manquent ou sont les plus anciens passent en premier et les autres attendent une requête ultérieure.
• Aucune requête pour un seul domaine, donc --only ignore Internet.nl.

Chaque requête est enregistrée dans scans/internetnl-requests.json, qui est commité avec les résultats même quand une exécution échoue. Une exécution qui constate que la limite hebdomadaire est atteinte ignore Internet.nl et conserve les résultats existants. Les lots prennent des heures, donc l'état de la requête est vérifié toutes les 5 minutes, et une requête encore en cours à la fin de l'exécution est récupérée par une exécution ultérieure au lieu d'être renvoyée. Internet.nl ignore --limit, et seules les exécutions sur la branche par défaut utilisent les identifiants Internet.nl, donc toutes les exécutions partagent un même registre.

Ce site web réutilise des résultats de tests fournis par l'outil de test Internet.nl.

Configuration

Tous les paramètres sont des secrets de dépôt facultatifs (Settings › Secrets and variables › Actions) :

Mozilla HTTP Observatory ne nécessite aucun compte. Les données de licence GitHub utilisent le jeton intégré du workflow.

Lancer les tests en local

npm ci
node scripts/scan.js --only email-providers/forward-email
node scripts/scan.js --limit 5 --tests observatory
node scripts/scan.js --tests mail-dns          # email DNS checks only
npm run test:unit                              # protocol probes against local mock servers
npm run build

Quel domaine est testé

Le champ domain doit correspondre au site web principal ou à l'application web où les utilisateurs se connectent, par exemple mail.example.com plutôt qu'un sous-domaine marketing sur un autre hôte. Les éditeurs peuvent proposer un domaine plus précis dans une pull request.