L'horloge derrière les commits : mesurer une journée de travail en UTC
Le défi
feedparse-lite se trouve sous trois mille paquets et l'auteur d'origine, qui n'y avait pas touché depuis deux ans, a confié les clés à un inconnu après une série de bons correctifs. La version 2.1.0 est sortie avec un script postinstall absent du tag git. Avant de débattre des intentions, le fil de discussion veut établir quelque chose de plus simple : le compte annonce Vancouver, et les horaires de travail d'une personne sont très difficiles à falsifier parce que ce n'est pas un champ que l'on remplit. Six documents publics sont sur le tableau. Donnez le décalage UTC dans lequel ce mainteneur vit réellement.
Ce que tu vas apprendre
- Comparer deux horodatages d'un même instant enregistrés par des horloges différentes
- Lire le DateTimeOriginal EXIF comme une heure locale sans décalage inhérent
- Déduire une journée de travail et une pause déjeuner à partir d'un histogramme d'activité
- Écarter les champs de profil et les enregistrements WHOIS d'un service d'anonymisation comme preuves de localisation
- Expliquer pourquoi les horaires d'activité sont plus difficiles à falsifier que n'importe quel attribut déclaré
Compétences testées
Prérequis
- Ce que sont l'UTC et un décalage horaire
- Lire un journal de commits
Comment ça marche
Presque tout sur un profil est saisi par la personne qu'il décrit. Localisation, nom, employeur, photographie : ce sont des déclarations, et elles ne coûtent rien. Ce qu'on ne peut pas facilement contrôler, c'est le moment où l'on est éveillé, parce que sa journée de travail s'infiltre dans chaque horodatage qu'une plateforme enregistre, et les plateformes enregistrent en UTC.
La mesure nécessite deux horloges montrant le même instant. Une publication porte un horodatage UTC côté serveur. La photo qui y est jointe porte un DateTimeOriginal, qui est l'horloge murale locale de l'appareil et, sur un appareil qui n'écrit aucun champ OffsetTime, n'a aucun fuseau horaire associé. L'écart entre les deux est le décalage, et sa précision correspond au nombre de minutes écoulées entre le déclenchement et la mise en ligne.
Vérifiez ensuite. Un décalage correct transforme un nuage d'horodatages UTC en quelque chose que l'on reconnaît comme humain : un début, une fin, un creux pour le déjeuner et rien le week-end. Un décalage erroné en fait quelqu'un qui dit bonjour à onze heures du soir. Dans ce cas, c'est un écart d'une journée entière qui trahit l'erreur, ce qui explique pourquoi le fil de discussion demandait un chiffre plutôt qu'un pays. Le chiffre est ce que les preuves permettent d'établir. Le pays n'est qu'une supposition ajoutée par-dessus.
Erreurs fréquentes
- Répondre UTC-7. C'est Vancouver en août, et c'est l'affirmation à vérifier, pas un résultat.
- Faire confiance à l'adresse WHOIS. Le titulaire est un service d'anonymisation. Son adresse postale est celle du service, et elle apparaît sur des milliers de domaines sans rapport.
- Lire l'horodatage de la photo comme de l'UTC.
DateTimeOriginalest l'horloge murale de l'appareil. La fiche précise qu'aucun champ de décalage n'est présent. - N'utiliser que le journal des commits. Il réduit la réponse à quelques décalages plausibles. Associer la publication à la photo la détermine exactement.
- Répondre avec un pays. Plusieurs pays partagent UTC+3, et les preuves ne permettent pas de trancher entre eux.
Comment s'en protéger
Pour un projet qui transmet des droits de commit ou de publication, l'identité est un problème de processus.
- N'accordez pas de droits de publication sur la seule foi de bons correctifs. Un échange vocal ou vidéo, une référence de quelqu'un de connu, ou une période de commits relus sans accès aux publications coûtent peu et brisent ce schéma.
- Exigez que deux mainteneurs approuvent une publication, et publiez avec une provenance vérifiable afin que l'archive puisse être comparée au tag dont elle prétend provenir. Un script postinstall absent du tag git n'aurait jamais dû atteindre un registre.
- Surveillez la forme plutôt que la personne : un paquet populaire dormant, un auteur inactif, un nouveau compte, un statut de confiance obtenu rapidement, puis une publication qui diffère de la source.
- Pour les utilisateurs, fixez les versions, installez avec les scripts de cycle de vie désactivés, et laissez un délai entre une publication et son adoption. La plupart de ces prises de contrôle sont repérées en quelques jours par quelqu'un d'autre.