DO_NOT_TRACK - プライバシー保護のための標準

 (donottrack.sh)
2 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • DO_NOT_TRACK は、CLIツール、SDK、フレームワークごとに異なるテレメトリ無効化の方法を、1つの環境変数に統一しようという提案
  • .NET、AWS SAM CLI、Azure CLI、Gatsby、Go、Google Cloud SDK、Homebrew、Netlify CLI、Syncthing は、それぞれ異なる設定やコマンドで テレメトリ を無効化している
  • DO_NOT_TRACK=1 は、広告トラッキング、利用状況レポート、テレメトリ、クラッシュレポート、機能に必須ではない開発元または第三者向けリクエストを拒否することを意味する
  • ユーザーは export DO_NOT_TRACK=1 を設定し、Bash、Zsh、Fish、PowerShell、Windows CMD のシェル設定に追加して、すべてのターミナルセッションに適用できる
  • ソフトウェア開発元は DO_NOT_TRACK が 1 の場合、すべての追跡を無効化し、既存の無効化方法とあわせてこの変数を尊重すべき

問題と提案

  • 多くのCLIツール、SDK、フレームワークはデフォルトで テレメトリデータ を収集しており、各ツールごとに無効化方法が異なる
  • たとえば .NET は DOTNET_CLI_TELEMETRY_OPTOUT=1、AWS SAM CLI は SAM_CLI_TELEMETRY=0、Azure CLI は AZURE_CORE_COLLECT_TELEMETRY=0、Gatsby は GATSBY_TELEMETRY_DISABLED=1、Go は go telemetry off、Google Cloud SDK は gcloud config set disable_usage_reporting true、Homebrew は HOMEBREW_NO_ANALYTICS=1、Netlify CLI は netlify --telemetry-disable、Syncthing は STNOUPGRADE=1 を使用する
  • DO_NOT_TRACK は、ユーザーが次の項目を拒否することを明確に表す 単一の標準環境変数 として提案されている
    • 広告トラッキング
    • 匿名かどうかに関係ない利用状況レポート
    • テレメトリ
    • クラッシュレポート
    • 機能に必須ではないソフトウェア開発元または第三者向けリクエスト
  • ユーザーは export DO_NOT_TRACK=1 を設定することで、ローカルソフトウェアだけを望む意思を示せる
  • シェル設定ファイルに追加すれば、すべてのターミナルセッションに適用できる
    • Bash: ~/.bashrc に export DO_NOT_TRACK=1
    • Zsh: ~/.zshrc に export DO_NOT_TRACK=1
    • Fish: ~/.config/fish/config.fish に set -x DO_NOT_TRACK 1
    • PowerShell: $PROFILE に $env:DO_NOT_TRACK = "1"
    • Windows CMD: システム環境変数に setx DO_NOT_TRACK 1

ソフトウェア開発元と関連標準

  • テレメトリ、分析、機能に必須ではないネットワークリクエストを行うツールは DO_NOT_TRACK 変数を確認すべき
  • DO_NOT_TRACK が 1 に設定されている場合は、すべての追跡を無効化しなければならない
  • 既存の無効化方法とあわせて、この変数を尊重すべき
  • テレメトリをデフォルトで有効にしてから拒否する方式よりも、オプトイン 方式にすることも検討対象
  • no-color.org — NO_COLOR、色付き出力を無効化するための標準
  • force-color.org — FORCE_COLOR、色付き出力を強制するための標準

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsの意見

  • ここまで来ると、デフォルトで追跡に同意した状態になっていても誰も驚かないというのが興味深い。
    DO_NOT_TRACKのようなフラグは良さそうに見えるが、同時にデフォルトがCONSENT_TO_TRACK=1だと言っているようにも感じられてぞっとする。

    • そもそも、いつ「追跡するな」と言っているのか？ このフラグは、自分のブラウザが他人のサーバーに接続するときに送るものだ。
      インターネットが巨大化したのは、広告とサーバーがユーザーから派生情報を引き出すビジネスモデルが主流だったからだ。
      楽しくも、私的でも、安全でもないが、ほとんどの法域や業界では違法でもない。
      このフラグはおとぎ話のような理想郷ではなく、事実上・法的に固定化された現実への対応だ。
    • こういうフラグ自体に問題があると思う。
      どんな情報も送りたくないし、もちろん追跡も望んでいないのに、それを環境変数ひとつで示すという発想からしておかしい。
      追跡されたくないと言いながらそんな情報を渡したがる人たちは理解しがたいし、その情報を渡した時点ですでに目印を付けたことになる。

  • 変数名は常に肯定形にする派なので、この場合ならALLOW_TRACKING=0になる。
    一貫性が出るし、二重否定を避けられるので推論しやすい。
    ただ、「DO NOT TRACK」という名前はある程度定着した用語なのかもしれない。

    • ALLOW_TRACKINGをカンマ区切りの一覧として実装して、許可するアプリケーションだけ指定することもできる。
      たとえばgoとbrewにはテレメトリーを共有したいが、awsやそれ以外は嫌なら、ALLOW_TRACKING=go,brewのようにできる。

  • ブラウザのDNTと同じ運命をたどる可能性が高い。
    ただ、あらゆる「追跡拒否」環境変数をひとつのdo_not_track.envファイルにまとめるのは悪くなさそうだ。

    • https://toptout.meがすでにあり、新しく作るつもりがないなら、こうした問題をかなり処理してくれる。
      このページの仕様に従いつつ、単純な環境変数ひとつで扱いたいなら、https://github.com/alloydwhitlock/do-not-track-cliもある。
    • 広告業界は、MicrosoftがDNTをデフォルトで有効にしたことでユーザーの選択権を奪ったと主張して無視した。
      実際には、どうせ守る気がなかった可能性が高い。
    • この方向性は気に入っている。
      普遍的なひとつを使えと求めるより、実際の解決策はこういう形になる可能性が高い。
      出発点として何か作ってみようと思う。

  • ちなみにGoテレメトリーはデフォルトではローカルに保存されるだけで、アップロードはされない: https://go.dev/doc/telemetry

  • PythonのtransformersライブラリがHugging Faceに接続しないようにするのが、思った以上に難しくて驚いた。
    HF_HUB_DISABLE_TELEMETRY=1を設定し、Wav2Vec2CTCTokenizer.from_pretrainedを呼ぶときにlocal_files_only=Trueも明示したのに、それでも有効なHF_TOKENがないという警告が出た。
    偶然HF_HUB_OFFLINE=1を見つけてからやっと、ディスクからwav2vec2モデルを読み込むたびにHFへ接続しに行かないのだと、ある程度確信できるようになった。
    あのいら立たしいHF_TOKEN警告がなければ、こんなことが起きていると気づきもしなかっただろう。

    • HFはオフライン作業を難しくすることで悪名高い。
      必要なものがすべてローカルにあっても、接続を試みて時間を無駄にしないようにする方法ですら、しょっちゅう変わる。
      以前はTRANSFORMERS_OFFLINEやHF_DATASETS_OFFLINEのようなものもあった。
    • Little Snitchのようなツールは、こういうものを捕まえて隠れた通信の相手を見つけるのに役立つだろうか？

  • 便利なハニーポットのようにも見える。
    この仕様への対応を公に知らせるツールなら、そもそも明示的な同意なしにテレメトリーを収集しているということなので、避けるべきツールと見なせる。

    • DO_NOT_TRACK対応が、すなわち追跡が明示的同意方式ではないことを意味するわけではない。
      たとえばソフトウェアがクラッシュして、クラッシュハンドラがダンプを送るかどうか尋ねる場合がある。
      DO_NOT_TRACKがあれば、クラッシュハンドラ自体が無効化され、質問もダンプ送信もない。
      ある程度採用されれば、おそらくそういう形で動く可能性が高い。
      広告のように追跡から金銭的利益を得る側は、こうしたオプションをサポートしないだろう。
    • ほとんどのサービスはすでにテレメトリーを収集しており、対応を公表したからといってその事実が変わるわけではない。
    • あまり深く覗き込まないほうがいい。
      そうすると現代的なツールの多くが使えなくなってしまうだろう。

  • 企業がこの提案をものすごくゆっくり実装するのを待つ間、一般的なツールのオプトアウト方法を一か所に集めたものはあるだろうか？
    それらを設定し、一覧を定期的に更新するシェルモジュールのようなものも作れそうだ。

  • 自前のDNSを運用して、問題のあるドメインをブロックリストに入れるほうが、おそらく簡単だ。
    テレメトリードメインが何百万件も入った良いブロックリストもある。例: https://github.com/hagezi/dns-blocklists

    • さらに言えば、そんなスパイウェアじみたゴミをそもそも自分のコンピューターに入れないほうがいい。
    • これが正しい対処法だ。
      「標準」を叫ぶ人たちは、非公式な代替策の長い一覧にひとつ追加しているだけだ。

  • ブラウザのグローバルな追跡拒否は、アクセス先のすべてのWebサイトと広告目的の追跡が対象なので、おおむね機能する。
    しかしテレメトリーはまったく別の問題であり、デフォルトブロックは一つの選択肢にはなっても、すべてのツールに対して意思を表明する標準変数ひとつを使うのは現実的に難しい。

  • 数年前にも同じ提案があったが、どこにも行き着かなかった。
    https://web.archive.org/web/20200613155957/https://consoledo...