今週は元 Apple エンジニアの David Shayer が再度の寄稿記事で、プライバシーに対する Apple の手法を述べ、それを他のテクノロジー会社と比較し、Apple と Google による COVID-19 曝露通知への取り組みを彼が信用する理由を語る。Apple TV を Mac の画面に表示させたいと思ったことのある人のために、Josh Centers がそれをする方法を説明し、うまくいかない事柄についても触れる。カンファレンス関係のニュースとしては、Apple が WWDC を、仮想的に、6 月 22 日より開催すると発表し、ACES Conference が無料の前編期間を IT コンサルタントに限らず一般の小規模事業主にも開放すると発表した。それからもう一つ、懐かしい昔の記憶が大好きな人たちのために、TidBITS 出版者 Adam Engst が最近いろいろなポッドキャストに次々と出演して TidBITS の 30 周年を祝った。Mac の歴史の初期から届けられた素晴らしい物語の数々をお聞きあれ。今週注目すべき Mac アプリのリリースは HandBrake 1.3.2、Retrospect 17.0.1、Bookends 13.4.1、Piezo 1.6.5、1Password 7.5、それに PopChar X 8.10 だ。
Apple は今年の仮想 Worldwide Developers Conference の開始日を発表した：22 June 2020 である。これは例年より少し遅いが、それは恐らくフォーマットの変更や同社の従業員が遠隔で働くと言う複雑さが加わったせいであろう。でも、Apple が WWDC を開催するということだけでも幸運と思わなければならない - Google はその I/O conference を遠隔で開催すると約束した後、完全にキャンセルしてしまったし、Facebook は F8 開発者カンファレンスを "年間を通しての一連のアップデート" で置き換えてしまった。
幸いなことには、$1599 のチケットは必要でない - 今年の仮想カンファレンスは登録 Apple 開発者全員に対して開かれている。キーノートはストリームされ誰でも見られると想定される。Apple は興味のある開発者は全員、iOS, iPadOS, そして tvOS に対する Apple Developer アプリをインストールするよう勧めている。これは、準備が出来次第更なる情報や分科会ビデオを提供すると見られる。
今年は学生に奨学金を提供する意味がないので、Apple は代わりに Swift Student Challenge を開催している。興味のある学生は３分以内で経験出来る Swift Playground を作成し Apple に 17 May 2020 の 11:59 PM PDT 迄に提出すべきである。勝者は WWDC20 ジャケットとピンのセットを受け取れる。
討論に参加
TidBITS Content Network を代表して、私は IT コンサルタントのための ACES Conference にここ数年参加してきており、今年も May 19th と 20th のカンファレンスに参加するため Atlanta に飛ぶ予定でいた。でも、コロナウィルスパンデミックの影響で、それは 10 月に延期となった。
しかしながら、単に日付をずらすだけでなく、カンファレンス組織者の Justin Esgar は今出来ることをやることに決めた。ACES Conference: The Prequel (前編イベント) である。これは仮想のイベントで、元々のカンファレンスの予定日と同じ日に開かれるが、全産業における中小企業経営者に焦点を拡大して行われる。テーマは時流に乗った直截的なもので：How Your Business Is Going to Survive COVID-19 (あなたの事業は COVID-19 をどの様に生き抜くか) である。討論課題は、マーケティング、販売、財務、ブランド戦略、精神衛生、等々に及ぶ。
最も良い点？ 誰もが ACES Conference: The Prequel に無料で受講登録出来る。これには２日間の講演討論が含まれ、そして何時でもライブで参加することも、その日の既に終了した録画を見ることも出来る。スピーカーには、作家 Peter Shankman, La Terza Coffee CEO David Gaines, そして Advocate to Win CEO Heather Hansen, 経営者コーチ Jason Womack, そしてポッドキャスター Josh Tapp, 更に、起業家、産業界のリーダー、財務コーチ、そして他の中小企業経営者が含まれる。
もし IT コンサルタントであれば、$199 の IT Consultant Pass には、追加のコンテンツや資源、去年のイベントで極めて効果的であると証明された分科会や IT 業界討論会、そして October 20-21 に予定される生参加の ACES Conference のチケットに適用される $199 のクレジットが含まれる。
チケット購入による収益の 10% と、イベントでの寄付は、青年期及び若年成人がこの世界的に不確かな時にがんと戦うのを援助する Stupid Cancer チャリティに当てられる。
(情報の全面開示の観点から言うと、私は過去に ACES で話をし、そしてスポンサーした事があり、そして ACES 顧問団の一員でもあるが、それは完全に無給の職である。更に、私は Stupid Cancer とは何らの関わりもないが、とても親しい友人が現在末期の膵臓癌と闘っており、Stupid Cancer の様なグループがどの様に援助出来るかについては十分認識している。)
討論に参加
大きな節目の TidBITS 記念日の私の好きな部分といえば、それは恐らく、昔懐かしい思い出を辿って TidBITS の初期の頃からの良い話を引っ張り出すのに良い機会だと言うことであろう。我々の最近の 30 周年記念日に合わせて沢山のポッドキャストに招待を受けた。全てがとても楽しかった。もし時間がおありで (正直言って、この状況下では皆さん持て余しておらせませんか)、Mac の世界の初期の時代を再び体験してみたとお思いなら、是非聴いてみてほしい。内容は、びっくりするほど重複していない。
- MacBreak Weekly: 私は、何時も時折の Leo Laporte の MacBreak Weekly への仮想の訪問を楽しんでおり、そして今回の Leo, Rene Ritchie, そして私の旧友で誕生日が同じの Andy Ihnatko との番組は何時もに増して楽しかった。MacBreak Weekly は取り上げる話題が広範囲で、とても TidBITS 記念日に焦点が当たったものとは言えないが、我々の最初の号の内容について話す時間はあった。取り上げたのは、After Dark スクリーンセーバー、Outbound Macintosh ポータブル、そして DeskWriter インクカートリッジをリフィルする話であった。
- The Talk Show: 私が John Gruber のポッドキャストにゲストとして出演するのは今回が初めてであり、そして会話はおよそ２時間にも及び、Mac と TidBITS の初期の時代について John と話をするのはとても楽しかった。もし Mac を 1980 年代の後半から 1990 年代の初期から使っておられた方は、是非時間を作ってこの会話に耳を傾けてほしい。我々は、当時が我々の誰もが認識していたよりも遥かに特別な時であったことに改めて気づくこととなる数多くの素晴らしい事柄に会話が弾んだ。
- Chit Chat Across the Pond Lite: Allison Sheridan と私は長年ほぼ同じ様な場を旅してきたが、実際に会える機会が出来たのは、去年の MacTech Conference で隣同士に座ることになった時であった。このポッドキャストの会話は TidBITS の創設の所から始まり、話題はあちこちに飛び、私の今好きな Apple ハードウェア、Apple の年次のオペレーティングシステムのアップデートスケジュールに伴う問題、そして何故私はもはや噂に注意を払わないのかと言った話題について話し合った。
- MacVoices (Part 1 と Part 2): Chuck Joiner と私はポッドキャストを長年録音してきた。そして、私は Chuck をむきにならせる事を言うのにとてつもない喜びを感じる。と言うのも、彼の放送での人格は何時もとても抑えられたものであったからである。我々は最後の方で、私と Tonya がまだ Cornell の学部学生だった頃に一緒に関わった出版物、これ迄の TidBITS 記事のリンク全てがきちんと働くのをどの様に確実にしているのか、そして電子メールは Internet 技術におけるゴキブリなのは何故なのか、等々について話し合った。
皆さんがこれらの会話を、私が自ら楽しんでしたのと同じ様に、楽しんで聞いていただけたらと願う。ポッドキャストの世界にいる他の人達のために言うと、時の雪崩に埋まってしまっている話や話題を掘り起こす作業ができるようなチャットならとりわけ喜んでお受けしたい。
討論に参加
最近読者の一人が私にメールで Apple TV を Mac にミラーするやり方を質問してきた。これをする主たる理由は二つある：記録のためにスクリーンショットやビデオを撮る、或いは Apple TV に関わる遠隔プレゼンテーションを可能にするためである。
私が初版の Take Control of Apple TV を書いた時、私はスクリーンショットを撮るために、高価で扱いにくい Elgato キャプチャーボックスを使わなければならなかった。Apple はその後この能力を QuickTime Player に組み込んだ。Apple TV HD (または、第四世代 Apple TV として知られている) を使う場合、それを USB-C ケーブルで Mac に接続しなければならないが、Apple TV 4K には USB-C ポートは付いていない。今日では、Apple TV の出力を QuickTime Player で捉えるのに必要となるのは、Apple TV と Mac が同じ Wi-Fi ネットワーク上にあることだけである。
設定
以下の手順を踏む：
- QuickTime Player を開く。
- File > New Movie Recording を選ぶ。macOS 10.14 Mojave かそれ以前では、ウィンドウが開いて、デフォルトではあなたのウェブカメラが表示される。10.15 Catalina では、System Preferences > Security & Privacy > Privacy > Camera で、QuickTime Player にカメラへのアクセスを許可する必要がある。
- マウスポインターをそのウィンドウに置いて、操作盤を出す。
- 録画ボタンの隣にある矢印をクリックする。
- メニューから Apple TV を選ぶ。
- 初めて Apple TV に接続する時には、Mac に入力しなければならないコードが表示される。もし Apple TV が別の部屋にある場合、これを一人でやるのは結構大変である。と言うのも、直ぐに時間切れになるからである。
"カメラ" を選ぶ時には、"マイク" を選ぶ選択肢も与えられ、そして、あなたの Apple TV も、それがどんなものであり、そこに表示される。しかしながら、私は Apple TV から Mac に音声を成功裏に送れたことは一度もない。もし、これをうまくやれた方は、コメントで知らせて欲しい。
使い方
一旦、この手順を踏み終えれば、Apple TV のインターフェースは QuickTime Player ウィンドウにミラーされ、スクリーンショットを撮ったり、或いは、プレゼンテーションをしているのであれば、Mac 上の他のウィンドウと同様に共有するのは簡単になる。
幸いにも、Siri Remote も Bluetooth 経由で働くので、たとえ別の部屋にいても、それを使って QuickTime Player ウィンドウの中の Apple TV を制御することも出来る。また、iPhone 上の Control Center にある Apple TV 制御も使える。
驚きはないであろうが、Apple は、映画や TV 番組からスクリーンショットやビデオを撮ることをさせてくれない。如何なるアプリの - Apple TV, Netflix, Amazon Prime, CBS All Access, 等々 - 保護されたビデオを再生しようとすると、QuickTime Player は黒の画面を表示してその様な振る舞いを拒否する。(購入した映画の場合、HDCP エラーが表示される。) Menu ボタンを押してそのビデオから離れると、Apple TV インターフェースが再び使えるようになる。ゲームやビデオ以外のアプリはこの様には阻止されないし、YouTube もブロックされない。
しかしながら、QuickTime Player は Apple TV インターフェースのスクリーンショットやビデオを捉えるには素晴らしい方法である。標準の macOS スクリーンショットコマンドが使える。制御バーや Mac のウィンドウ飾りの入らないきれいなスクリーンショットを撮るには、以下の手順を踏む：
- QuickTime Player ウィンドウを合うと思える大きさにリサイズする。
- マウスポインターを QuickTime Player ウィンドウの外側に動かす。
- 捉えるウィンドウを指定するために、Command-Shift-4、続いて Space バーを押す。
- カメラポインターを QuickTime Player ウィンドウの上に持ってくる。
- ドロップシャドウ無しにウィンドウを捉えるため Option クリックする。
Apple TV インターフェースの使い方を誰かに遠隔で教えたり、或はそれについてプレゼンテーションをしたりするのであれば、Skype, Zoom, 等々を使って、他の Mac ウィンドウでと同様に QuickTime Player ウィンドウを共有出来る。ビデオは滑らかではないであろうが、デモの用途には十分である。
私は、スクリーンショットの撮り方や他の多くのヒントを Take Control of Apple TV で解説している。この本は、理解しやすさを改善し、そして Apple の現在の TV 戦略にもっと沿うものとするべく最近書き直したばかりである。
討論に参加
私たちは皆、アプリを使う。私たちの情報をアプリが取り込むことは知っている。でも、実際どれだけの情報を取り込んでいるのだろうか？ 私は Apple でも、また他のある中規模のテクノロジー会社でも、ソフトウェアエンジニアとして働いたことがある。善も悪も私は見てきた。そして、Apple で働いた私の実体験に照らして考えれば、今回 COVID-19 曝露通知のため Apple と Google が提案した取り組みを私は大いに安心して受け取ることができると思う。その理由をこれから述べたい。
Apple はユーザーのプライバシーを尊重する
私が Apple Watch の仕事をしていた当時、私の任務の一つは Weather アプリと Stocks アプリがどれだけの回数起動されたかを記録してそれを Apple に報告する機能をアプリに組み込むことであった。個々のアプリが何回起動されたかを記録するのは単純なことだ。でも、そのデータを Apple に報告するのはもっとずっと複雑なことだ。
Apple は自社のプログラマーが顧客のセキュリティとプライバシーを常時念頭に置いていなければならないと強調する。基本的なルールがいくつかあって、中でもこの問題に最も関係が深いのが次の二つだ：
- 情報の収集は正当なビジネス目的のものに限られる
- その目的のために必要なもの以外の情報を収集してはならない
この二つ目のルールは少し説明を必要とする。通常の利用データ (人々はどれくらい頻繁に天気予報をチェックするのか？) を集めるならば、その際にそのユーザーを特定することに結びつく可能性のある何かを、例えばその人が天気を調べた都市名などを、うっかりと一緒に収集してしまうようなことがあってはならない。これらのルールを Apple がどれほど厳しく執行しているかを、私は実際に自分がユーザーデータの記録を担当するまで全然知らなかった。
Weather アプリと Stocks アプリが起動された回数を記録し終えると、私はデータを Apple に報告するため Apple 社内用のフレームワークをセットアップする仕事に取り掛かった。そこで初めて気付いたのは、報告するデータは数字であるべきで文字列 (語句) であってはならないとそのフレームワークが明確に強調していることだった。文字列を報告しないことで、コードがうっかりとユーザーの名前や電子メールアドレスを記録してしまうことがなくなる。さらにファイルのパス名を記録してはならないという具体的な警告もある。パス名にはユーザーの名前が (例えば /Users/David/Documents/MySpreadsheet.numbers のように) 含まれる可能性があるからだ。また、文字を数字にエンコード (例えば A=65, B=66, など) して送信するなどの小細工を用いることも許されない。
その次に私が知ったのは、プライバシー審査委員会による審査を受けて承認を得るまでは私のコードを Apple のソース制御システムにチェックインすることさえできないという事実だった。これは、印象ほどには手ごわい障壁ではなかった。数人の上席エンジニアたちが私に、そのデータを記録する理由と、それがビジネス目的であることの説明を書面で提出するようにと言った。また、彼らは私のコードを審査して、私が意図した以上のものをうっかりと記録していないか確認した。
いったん Apple のデータ報告フレームワークの使用を承認された後は、自分のコードをソース制御システムにチェックインすることを許された。承認なしに勝手に自分のコードをソース制御システムにチェックインしようとしても、ビルド用サーバがビルドを拒否したはずだ。
watchOS の次のビルドが出た時点で、社内の報告ダッシュボード上で Weather アプリと Stocks アプリが日々どれだけの回数起動されているかの数字を OS のバージョンごとに分けて一覧することができるようになった。けれどもそれ以上の情報はなかった。これで任務完了、プライバシーは保たれた。
TechCo はユーザーのプライバシーを大体において無視する
私はある中規模のテクノロジー会社で iPhone アプリを書いたこともあるが、その会社の名前は書かないでおこう。でもここはきっと皆さんも聞いたことのある会社だし、数千人の従業員がいて、数十万ドルの収益を上げている会社だ。この記事では仮に TechCo と呼ぶことにしよう。ユーザーのプライバシーに対するこの会社の姿勢は残念ながらこの業界であまりにも一般的だからだ。この会社は Apple に比べてユーザーのプライバシーへの関心がずっと低い。
私が作っていたアプリはユーザーとのやり取りをすべて記録し、そのデータをコントロールサーバへ報告した。あなたが何かアクションをする度に、このアプリはあなたがどのスクリーンにいてどのボタンをタップしたかを記録した。取り込まれるデータを最小化する試みは一切なされず、匿名化しようともしなかった。報告される一つ一つのデータに、そのユーザーの IP アドレス、ユーザ名、本名、言語と地域、タイムスタンプ、iPhone モデル名、その他にも多くのデータが含まれていた。
このような挙動がいかなる意味でも悪意によるものでなかったことには留意して頂きたい。この会社の目標はユーザーたちを監視することではなかった。そうではなくて、どの機能が人気を得ていてどの機能が最も多く使われたかを会社のマーケティング部門が知りたかっただけのことだ。何よりも重要な点として、マーケティング担当者たちは人々がどこで「じょうご」から抜け落ちたかを知りたがった。
皆さんがオンラインで何か買い物をするとき、その購入プロセスはじょうご (funnel) と呼ばれる。まず、あなたは製品を見る。例えば一足のスニーカーとしよう。あなたはそのスニーカーをショッピングカートに追加して、購入ボタンをクリックする。それからあなたは名前、住所、そしてクレジットカード番号を入力し、最後に Purchase ボタンをクリックする。
これらのプロセスの一つ一つの段階で、人々は抜け落ちる。考えてみれば新しいスニーカーに $100 も出すのはもったいないと思い直すかもしれないし、子供たちが部屋に駆け込んできて何かを見せてきたかもしれないし、食事ができたよと呼ばれたかもしれない。理由は何であれ、人々はスニーカーのことを忘れて、もうその購入を完了することはない。これがじょうごと呼ばれているのは、まるでじょうごのようにだんだんと狭まって行くからで、終わりに向かう各段階ごとに次へ進む人たちの数が減るからだ。
会社は多くの時間を費やして、じょうごの各段階で人々がなぜ抜け落ちるのかを見出そうとする。段階の数を減らせば、人々が抜け落ちる機会を減らすことができる。例えば、前回の注文で名前と住所を記憶しておいてそれを自動入力するようにすれば、それをあらためて入力する手間が省かれ、処理のその時点で抜け落ちる可能性が減るだろう。このような削減の究極の形が、Amazon が特許を受けた 1-Click 注文だ。ボタンを１つ押すだけで、スニーカーがあなたの住所に向けて発送されたからだ。
TechCo のマーケティング部門は、人々がじょうごから抜け落ちるのがなぜかを知るためにもっと多くのデータを得たがった。それを利用してじょうごに調整を加えることで、もっと多くの製品を売ろうというのだ。でも残念ながら、データを収集する際に彼らはユーザーのプライバシーなんか考えもしなかった。
収集されたデータの大部分は私たちが自分で書いたコードによって収集されたものでなく、私たちがアプリに追加したサードパーティのライブラリが収集したものであった。ユーザーのデータを収集するために最も人気を集めているライブラリは Google Firebase だが、それ以外にも何十ものライブラリがある。私たちのアプリにも、そのうち数個のライブラリが使われていた。それらは大体似たような機能を提供していたけれども、それぞれに特有のマーケティングが望む何らかのデータを収集していて、私たちはそれぞれを追加しなければならなかった。
データは大きなデータベースに保存され、エンジニアたち全員が検索することができた。これは、自分たちのコードが意図通りに働いていることを確認するためには便利だった。アプリを起動して、タップしていくつかの画面を通れば、データベースの中の私のアカウントを見るだけで私のアクションが正しく記録されていることを確認できた。けれども、このデータベースはアクセスをコンパートメント化するようには作られていなかった。アクセスを得られる人は全員、データベースの中にあるデータをすべて見ることができた。私も、自分のデータを見るのと同じ手順でどのユーザーのアクションもすべて見ることができた。ユーザーたちの本名と IP アドレス、その人がログオンしログオフした時刻、どのアクションをしたか、どの製品を購入したかまで、すべてが見えた。
私より上席のエンジニアたちの何人かも、私も、これではセキュリティが良くないと知っていたし、私は TechCo の経営者に状況を改善すべきだと訴えた。テスト用のデータはすべてのエンジニアがアクセスできるようにしておくべきだが、製品のユーザーデータをその状態におくべきではない。本名と IP アドレスは別のセキュアなデータベースに保存しておくべきだし、汎用のデータベースではユーザーを識別できない ID を使うべきだ。特定のビジネス目的に必要でないデータはそもそも収集すべきでない、と。
でも、マーケティング担当者たちは利用できるすべてのデータを取り込む何でもかんでも一緒くたのやり方を気に入っていた。機能面だけを考えれば、彼らの考え方も完全に理不尽だとも言えなかった。余分なデータがあることで、私たちがアプリを書いた時点では思い付けなかったユーザーの行動パターンについて疑問が生まれても、データベースに立ち戻るだけで答が得られるだろうからだ。けれども何かがただ実行可能だからと言って、それをすべきだということにはならない。セキュリティに関する私たちの申し立ては無視され、結局は私たちも声を上げるのをやめてしまった。
このアプリは私が働いていた間に米国以外でリリースされたことはなかった。おそらくこのアプリはヨーロッパの General Data Protection Regulation (GDPR として知られる一般データ保護規則、Geoff Duncan の 2018 年 5 月 2 日の記事“欧州の一般データ保護規則、プライバシーをグローバル化”参照) の下では合法的でないだろう。TechCo はヨーロッパでリリースする前に変更を加えることになるのではなかろうか。それにまた、このアプリはカリフォルニア州の California Consumer Privacy Act (CCPA) にも適合しない。カリフォルニア州の住民に、どのデータが収集されているかを知り、その利用法をいくつかの方法で制御できる権利を与えることを狙った法律だ。だから、この会社も近いうちに GDPR と CCPA に適合するため大きな変更を加えようとするかもしれない。
COVID-19 曝露通知取り組みにはプライバシーが織り込まれる
以上の２つの物語を念頭に置いて、Apple と Google が取り組んでいる COVID-19 曝露通知テクノロジーについて考えてみたい。この取り組みは、明示的に濃厚接触を追跡するものではない。あなたも、あなたが接触した誰をも、識別することはしない。
(以下に説明する内容は公開された説明に基づいている。例えば Glenn Fleishman の 2020 年 4 月 10 日の記事“Apple と Google、プライバシーを守った COVID-19 接触追跡＆通知で協業”にもよっている。Apple と Google は連続的にプロジェクトの各要素に調整を加えつつあるので、特に今述べた記事に寄せられたコメントにメジャーな内容の更新も報告されているのでぜひお読み頂きたい。Glenn も引き続き進行中の Apple/Google 共同ブリーフィング情報を得ていて、改作に対する吟味をしている。)
この取り組みの現時点での草稿を読むと、Apple 流のプライバシー尊重の感触が非常に強く感じられる。情報の記録と送信の参加はいずれもオプトインで、あなたが COVID-19 陽性の診断を受けた場合にもそれを報告するか否かはあなたの判断に任される。あなたについての個人情報をスマートフォンが送信することは一切ない。その代わりに、Bluetooth ビーコンを作成してそこに固有の ID を割り振り、その ID があなたをトラックバックできないようにする。この ID はランダムに生成された診断暗号化鍵に由来し、その暗号化鍵は 24 時間ごとに新たに作成されてあなたのスマートフォン上のみに保存される。その ID でさえ追跡は不可能だ。ID は 15 分ごとに変わるので、それ自体からあなたのスマートフォンが特定されることもない。保存されるのは最新の 14 個の鍵、つまり最近 14 日間分のもののみだ。
あなたのスマートフォンは近隣にある他のスマートフォンから届いた識別子をすべて記録するが、それらの識別子がどの場所で届いたかは記録しない。あなたが遭遇した Bluetooth ID のリストはスマートフォン上にのみ保存され、集中型のサーバへ送られることはない。(Apple と Google は最近になって、この接触通知システムを利用しかつ位置情報を記録するアプリはいかなるものでも承認しないと公式に述べた。)
もしもあなたが COVID-19 検査で陽性と判定されれば、公衆衛生機関の公式アプリを使って Apple と Google のフレームワークとやり取りし、あなたが受けた診断を報告することができる。おそらく、あなたはコードなり何なりの情報を入力して、その診断の認証をしなければならないだろう。これは偽の通報を防ぐためのもので、偽の情報は不必要なトラブルを招きシステムへの信頼を損なうだろうからだ。
アプリがあなたへの診断を確認すると、アプリはあなたのスマートフォンに、保存している過去 14 日間の日ごとの暗号化鍵を Apple と Google がコントロールするサーバへアップロードさせる。曝露がいつ起こったかに応じてアップロードされる鍵の個数は減るかもしれない。
もしもあなたがそのサービスを有効に設定していれば、あなたのスマートフォンは連続的に、陽性診断を受けた人たちのデバイスがアップロードしたすべての日々の暗号化鍵をダウンロードする。するとあなたのスマートフォンはさまざまの暗号学的処理を実行して、それらの鍵から生成された ID と、その鍵がカバーする期間中に取り込んだすべての Bluetooth 識別子とを照合できるようになる。もしもマッチが見つかれば陽性の人の近隣にいたと分かるので、あなたは通知を受ける。(近隣というのは複雑な問題で、Bluetooth の到達範囲にもよるし、ずっと離れたところにあるデバイスが近くにあると評価してしまうこともある。) たとえアプリがインストールされていなくても、スマートフォンのオペレーティングシステムから通知が来る。アプリがあれば、より詳細な情報を受け取れる。
いかなる時点でも、サーバが誰かの名前や位置情報を知ることは一切ない。サーバが受け取るのはただ単にランダムに生成された一連の暗号化鍵だけだ。あなたが個別の Bluetooth ビーコンを受信できる訳ですらない。そんなことをすれば公共の場で誰かがあなたを識別できてしまうかもしれないからだ。実際、検査で COVID-19 陽性であったことをあなたがアプリに証明してみせない限り、あなたのスマートフォンはいかなるデータもサーバへ送信しない。たとえどこかのハッカーが、あるいは熱心過ぎる政府機関がサーバを乗っ取ったとしても、ユーザーを識別することはできない。あなたのスマートフォンは 14 日分より古い鍵をすべて捨て去るので、たとえあなたのスマートフォンがクラッキングされたとしても長期的な情報は明かされない。
実際には、複数のサーバが使われるだろうし、処理のプロセスはもっと複雑なものになる。ここに記したのは、TechCo が犯したような種類の誤りを避けるために Apple と Google がそもそもの始めからどのようにしてプライバシーを築こうとしているかを示す、概略を述べたに過ぎない。
Apple はユーザーのプライバシーを尊重すると断言する。そして私の体験が、それが真実であることを示唆している。他の会社や政府が作ったシステムよりも、私は Apple が開発したシステムの方を信用したいと強く思う。それは決して他の会社や政府がユーザーのプライバシーを乱用しようとしていると言っているのではない。それはただ、Apple の外ではあまりにも多くの組織が、そもそもの始まりからプライバシーを織り込むことの意味を理解していないか、あるいはまた競合する利害の結果として正しいことをしようとする努力を台無しにしているかの、いずれかだからだ。
David Shayer は Apple のソフトウェアエンジニアとして 18 年間働いていた。彼は数多くのプロジェクトに携わったが、その中には iPod、Apple Watch、それに Apple のバグ追跡システム Radar の開発も含まれている。
討論に参加
