Éthique de la journalisation des frappes

La journalisation des frappes enregistre la façon dont vos annotateurs écrivent. Ce sont des données comportementales sur des personnes identifiables, et elles s'accompagnent d'obligations que la documentation technique ne couvre pas.

Cette page s'adresse au chercheur qui déploie la fonctionnalité. Ce n'est pas un conseil juridique, et cela ne remplace pas l'examen par votre propre institution.

Rien de tout cela ne s'applique tant que vous n'avez pas activé la fonctionnalité. keystroke_logging.enabled vaut false par défaut, et une mise à niveau ne changera pas cela.

Ce que vous collectez réellement

Les flux de Potato sont aveugles au contenu. Ils enregistrent qu'un caractère a été inséré, quand, à quel endroit du champ, et quelle classe de touche l'a produit, mais jamais quel caractère. Vous ne pouvez pas reconstituer le texte à partir d'un flux.

C'est une protection réelle de la vie privée, et ce n'est pas la même chose que des données non identifiantes.

Les profils temporels sont une donnée biométrique

La dynamique de frappe, c'est-à-dire la distribution des intervalles entre touches, des temps d'appui et des latences de digrammes, est une donnée biométrique comportementale bien établie. Elle peut servir à identifier des individus et à relier des comptes entre contextes. Potato ne le fait pas et ne fournit aucun outil pour le faire, mais les données sous-jacentes le permettraient.

Traitez un flux de frappes comme n'importe quelle autre donnée biométrique comportementale : comme identifiante, comme devant faire l'objet d'une limite de conservation, et comme exigeant un consentement.

Ce qui peut être inféré au-delà de la paternité du texte

Les données temporelles ont servi, en recherche, à inférer l'aisance au clavier, la maîtrise d'une langue et le statut de locuteur non natif, la charge cognitive et la fatigue, et dans certaines littératures, des affections motrices et neurologiques. Potato ne calcule rien de tout cela, mais les données que vous conservez rendraient ces analyses possibles, et vos participants ne s'y attendent guère lorsqu'ils acceptent « une tâche d'annotation ».

Dites ce que vous collectez. Ne comptez pas sur une clause générale du type « nous collectons des données d'usage » pour couvrir cela.

Divulgation

disclose_to_annotators vaut true par défaut. Le désactiver inscrit un avertissement au démarrage :

keystroke_logging:
  disclose_to_annotators: false   # logs a warning; make sure your IRB covers this

Il existe des raisons légitimes de collecter sans divulgation, puisque certains protocoles sont invalidés si l'on dit aux participants ce que l'on mesure. C'est une décision de comité d'éthique, pas une commodité de configuration. Si vous désactivez la divulgation, vous devriez pouvoir montrer l'approbation qui l'autorise.

Exemple de formulation du consentement

Adaptez ce texte à votre protocole. C'est un point de départ, pas un modèle à coller sans le lire.

La façon dont vous écrivez est enregistrée, en plus de ce que vous écrivez.

Pendant que vous tapez vos réponses, cette étude enregistre le rythme de votre frappe : quand vous commencez et vous arrêtez, la durée de vos pauses, les moments où vous revenez en arrière pour réviser, et les moments où vous collez du texte venu d'ailleurs. Elle enregistre le rythme et la structure de votre frappe, pas les touches que vous appuyez. L'enregistrement ne permet de retrouver rien de ce que vous avez tapé, en dehors des réponses que vous soumettez.

Ces informations servent à comprendre comment les personnes abordent la tâche et à vérifier la qualité des données recueillies.

[Le cas échéant :] Ces mesures pourront servir à repérer les réponses copiées ou produites ailleurs plutôt qu'écrites par vous.

[Le cas échéant :] Les enregistrements seront diffusés dans le cadre d'un jeu de données de recherche anonymisé.

Vous pouvez nous demander de supprimer vos données à tout moment en écrivant à [ ].

Les clauses entre crochets comptent. Si vous comptez vous servir des signalements pour des décisions de paiement ou d'exclusion, dites-le avant que les gens commencent à travailler, pas après les avoir signalés.

Utiliser les signalements équitablement

La détection du processus de rédaction produit des signalements avec les preuves attachées. L'usage que vous en faites relève de votre responsabilité.

À faire :

• Traiter un signalement comme une invitation à regarder, pas comme une conclusion.
• Lire les preuves session par session, et pas seulement l'étiquette de verdict.
• Laisser à l'annotateur la possibilité de s'expliquer avant d'agir.
• Tenir compte des faux positifs connus : claviers mobiles, utilisateurs d'IME, dictée, technologies d'assistance et dactylos rapides.
• Consigner votre règle de décision à l'avance, dans votre protocole.

À ne pas faire :

• Brancher les signalements sur un rejet automatique, une retenue de paiement ou une exclusion.
• Prendre la queue calibrée pour une faute. Un seuil par percentile signale une part fixe de n'importe quelle population, y compris une population entièrement honnête.
• Publier des scores de risque par annotateur d'une manière qui identifie des individus.
• Vous servir des signalements pour affirmer quoi que ce soit sur une personne au-delà de la paternité d'une réponse. Les données ne permettent pas d'inférences sur sa compétence, son sérieux ou son caractère.

Le problème du taux de base

Si 5 % de vos réponses sont collées depuis un agent conversationnel et que votre règle signale 5 % des sessions, l'essentiel de ce que vous signalez peut encore être du travail honnête, selon la qualité de la séparation opérée par la règle. Sur une plateforme où la fraude est réellement rare, une règle au taux de faux positifs même faible produit plus d'accusations infondées que de prises réelles. Estimez votre taux de base avant de bâtir une politique sur les signalements.

Droits des participants

Suppression

Supprimer les flux et les synthèses d'un participant :

from potato import typing_store
typing_store.delete_for_user(task_dir, project, user_id)

Cela vide typing_sessions. Les synthèses recopiées dans <output_annotation_dir>/<user>/user_state.json sous typing_summaries doivent être supprimées séparément si vous honorez une demande de suppression complète.

Minimisation

Ne collectez que le strict nécessaire à votre question :

keystroke_logging:
  fidelity: summary               # features only, no raw streams retained
  include_schemas: [rationale]    # instrument one field, not every box
  classify_paste_source: false    # skip clipboard comparison entirely

Conservation

Potato ne fait pas expirer les données. Si votre protocole s'engage sur une durée de conservation, supprimez les flux vous-même quand elle est écoulée. Passer à fidelity: summary après la période d'analyse est un compromis raisonnable : vous gardez les caractéristiques agrégées et abandonnez le détail biométrique.

Diffusion et publication

Si vous publiez des données de frappe dans un jeu de données :

• Remplacez les identifiants d'utilisateur par des pseudonymes propres à l'étude, qui ne renvoient pas aux identifiants de plateforme. Les identifiants de travailleur Prolific et MTurk sont des identifiants, pas des pseudonymes.
• Demandez-vous si le rythme au niveau de la session est nécessaire, ou si les caractéristiques de synthèse suffisent. Les synthèses sont bien moins ré-identifiantes que les flux.
• Vérifiez que votre consentement couvrait la rediffusion, et pas seulement la collecte.
• Les empreintes de collage sont salées par session et ne peuvent pas être inversées, mais elles révèlent tout de même qu'un même texte a été collé deux fois. Jugez si ce lien est acceptable dans une publication ouverte.

Les exports de Potato sont optionnels exactement pour cette raison. export_include_typing_dynamics et l'exportateur keystrokes sont désactivés par défaut, si bien que les données comportementales ne se retrouvent jamais par accident dans une publication de jeu de données.

Notes selon les juridictions

Ceci n'est pas un conseil juridique. Cette section signale ce qui a tendance à être pertinent.

RGPD et UK GDPR. Des profils temporels capables d'identifier une personne sont des données à caractère personnel. Si vous vous en servez pour isoler des individus, demandez-vous si l'article 22 (décision automatisée) s'applique, en particulier lorsqu'un signalement a un effet sur le paiement. Le consentement doit être spécifique et éclairé, et une acceptation générale de conditions d'utilisation ne suffira probablement pas.

Examen institutionnel aux États-Unis. Il s'agit en général de recherche sur des sujets humains. Certains IRB considèrent la dynamique de frappe comme un identifiant biométrique, ce qui peut changer la catégorie d'examen.

Plateformes de crowdsourcing. Prolific, MTurk et les plateformes similaires ont leurs propres règles sur la surveillance des participants et sur le rejet du travail. Vérifiez la politique de la plateforme avant de rejeter qui que ce soit sur la base d'un signalement. Plusieurs exigent que vous puissiez justifier un rejet auprès du travailleur.

Pour aller plus loin

• Journalisation des frappes - ce qui est capté et comment
• Détection du processus de rédaction - les règles et leurs faux positifs
• Mener une étude sur Prolific et MTurk - travailler avec des annotateurs rémunérés
• Contrôle de la qualité - contrôles d'attention et étalons

Pour les détails d'implémentation, consultez la documentation source.