Skip to content

キーストロークロギングの倫理

Potatoのキーストロークロギングにおける同意、IRB審査、データ保持、参加者の権利。このデータから何が分かってしまうのか、執筆プロセスのフラグを公正に使うにはどうすればよいか。

キーストロークロギングは、アノテーターがどのように書いたかを記録します。これは特定可能な個人についての行動データであり、技術ドキュメントが扱っていない責任が伴います。

このページは、この機能を導入する研究者に向けて書かれています。法的助言ではなく、所属機関の審査に代わるものでもありません。

ここに書かれていることは、機能を有効にするまでは当てはまりません。keystroke_logging.enabledのデフォルトはfalseで、アップグレードによってそれが変わることはありません。

実際に収集しているもの

Potatoのストリームは内容に触れません。文字が挿入されたこと、その時刻、フィールド内のどこか、どのクラスのキーによるものかは記録しますが、どの文字だったかは記録しません。ストリームからテキストを復元することはできません。

これは意味のあるプライバシー保護ですが、データが個人を特定しないということとは別です。

タイミングのパターンはバイオメトリクス

キーストロークダイナミクス、つまりキー間間隔、押下時間、ダイグラフ遅延の分布は、確立された行動的バイオメトリクスです。個人を特定したり、文脈をまたいでアカウントを結び付けたりするのに使えます。Potatoはそれを行いませんし、そのためのツールも提供しませんが、元になるデータはそれを可能にします。

キーストロークのストリームは、他の行動的バイオメトリクスと同じように扱ってください。特定可能なものとして、保持期限が必要なものとして、そして同意を要するものとして。

著者性を超えて推定されうること

タイミングデータは研究の中で、タイピング技能、言語運用能力や第二言語話者かどうか、認知的負荷と疲労の推定に使われてきましたし、文献によっては運動系や神経系の状態の推定にも使われています。Potatoはこれらを一切計算しませんが、あなたが保持するデータはそうした分析を可能にします。そして参加者は、「アノテーションのタスク」に同意した時点でそこまで想定していないでしょう。

何を収集するのかを明示してください。「利用状況データを収集します」といった一般的な文言でこれを覆えると考えないでください。

開示

disclose_to_annotatorsのデフォルトはtrueです。オフにすると起動時に警告がログに出ます。

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

開示せずに収集する正当な理由もあります。何を測っているかを参加者に伝えると成立しなくなる研究デザインもあるためです。ただしそれは、設定上の都合ではなく倫理委員会が判断することです。開示を無効にするのであれば、それを認めた承認を示せるようにしておくべきです。

同意文の例

自分のプロトコルに合わせて調整してください。読まずに貼り付けるための定型文ではなく、出発点です。

書いた内容だけでなく、どのように書いたかも記録されます。

回答を入力している間、この研究はあなたの入力のタイミングを記録します。いつ入力を始めていつ止めたか、どれくらいの長さポーズを置いたか、いつ戻って書き直したか、いつ他の場所からテキストを貼り付けたか、といった情報です。記録されるのは入力のタイミングと構造であり、押した個々のキーではありません。この記録から、あなたが送信した回答以外のものを復元することはできません。

これは、人がこのタスクにどのように取り組むかを理解し、収集したデータの品質を確認するために使われます。

[該当する場合:]この測定結果は、あなたが書いたものではなく他の場所からコピーまたは生成された回答を特定するために使われることがあります。

[該当する場合:]この記録は、匿名化された研究用データセットの一部として公開されることがあります。

[ ]までご連絡いただければ、いつでもデータの削除を求めることができます。

角括弧の中の文言は重要です。フラグを報酬や除外の判断に使うつもりなら、フラグが立ってからではなく、作業を始める前にそう伝えてください。

フラグを公正に使う

執筆プロセス検出は、根拠を添えたフラグを生成します。それをどう使うかはあなたの責任です。

すべきこと:

  • フラグは結論ではなく、確認のきっかけとして扱う。
  • 判定のラベルだけでなく、セッションごとの根拠を読む。
  • 何か行動を起こす前に、アノテーターに説明の機会を与える。
  • 既知の偽陽性を考慮する。モバイルのキーボード、IMEの利用者、音声入力、支援技術、速いタイピスト。
  • 判断の基準を、事前にプロトコルへ書いておく。

してはいけないこと:

  • フラグを自動的な却下、報酬の差し止め、アカウント停止に結び付ける。
  • キャリブレーションによる裾を不正と見なす。パーセンタイル閾値は、まったく正直な集団を含めてどんな集団でも一定の割合にフラグを立てます。
  • アノテーター別のリスクスコアを、個人が特定できる形で公開する。
  • 回答の著者性を超えて、その人について何かを主張するためにフラグを使う。このデータは、能力、努力、人柄についての推論を支持しません。

基準率の問題

回答の5%がチャットボットから貼り付けられていて、ルールがセッションの5%にフラグを立てるなら、そのルールが両者をどれだけよく分離できるかによっては、フラグが付いたものの大半が正直な仕事であることは十分にありえます。実際の不正がまれなプラットフォームでは、偽陽性率が小さいルールでも、正しく捉えた件数より誤った告発のほうが多くなります。フラグの上に運用方針を組む前に、自分の基準率を見積もってください。

参加者の権利

削除

特定の参加者のストリームと要約を削除します。

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

これはtyping_sessionsを消去します。<output_annotation_dir>/<user>/user_state.jsontyping_summariesにミラーされた要約は、完全な削除要求に応じるのであれば別途削除する必要があります。

最小化

自分の問いに答えるのに必要な最小限だけを集めてください。

yaml
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

保持

Potatoはデータを自動的に期限切れにしません。プロトコルで保持期間を約束しているなら、その期間が過ぎた時点で自分でストリームを削除してください。分析期間の後にfidelity: summaryへ切り替えるのは、集計された特徴量を残しつつバイオメトリクスの詳細を落とせる、妥当な折衷案です。

共有と公開

キーストロークデータをデータセットの一部として公開する場合は、次の点を確認してください。

  • ユーザーIDを、プラットフォームのIDに戻せない研究固有の仮名に置き換える。ProlificやMTurkのワーカーIDは識別子であって、仮名ではありません。
  • セッション単位のタイミングが本当に必要か、要約特徴量で足りるかを検討する。要約はストリームよりも再識別されにくいものです。
  • 同意が収集だけでなく再配布も対象にしているか確認する。
  • 貼り付けのハッシュはセッションごとにソルトが加えられており復元はできませんが、同じテキストが2回貼り付けられたことは分かってしまいます。その紐付けが公開において許容できるかを判断してください。

Potatoのエクスポートがオプトインになっているのは、まさにこのためです。export_include_typing_dynamicskeystrokesエクスポーターはどちらもデフォルトでオフなので、行動データが手違いでデータセットの公開物に含まれることはありません。

法域ごとの注意

法的助言ではありません。関係しやすい点を挙げておきます。

GDPRおよびUK GDPR。 個人を特定しうるタイミングのパターンは個人データです。それを使って個人を選び出すのであれば、特にフラグが報酬に影響する場合、第22条(自動化された意思決定)が適用されるかを検討してください。同意は具体的かつ十分な説明に基づく必要があり、一般的な利用規約への同意で足りる可能性は低いでしょう。

米国の機関審査。 通常、人を対象とする研究に当たります。IRBによってはキーストロークダイナミクスをバイオメトリック識別子として扱うため、審査の区分が変わることがあります。

クラウドソーシングのプラットフォーム。 Prolific、MTurkなどのプラットフォームには、参加者のモニタリングと作業の却下について独自の規定があります。フラグを根拠に誰かを却下する前に、そのプラットフォームのポリシーを確認してください。却下の理由をワーカーに説明できることを求めるところもあります。

参考情報

実装の詳細については、ソースドキュメントを参照してください。