iCloud Photos にアップロードされた児童の性的虐待素材を iOS 15 が検出するという Apple の発表を巡る論争はまだ続く。先週、Apple はまた新たな説明資料を公開するとともに、ソフトウェア責任者の Craig Federighi を Wall Street Journal の記者会見に送り出して説明させた。Adam Engst がその詳細に踏み込む。皆さんは現実世界の巡回セールスマン問題を解決する必要に迫られたことがあるだろうか？ Adam はその状況に直面して、MapQuest を使った解決策を思い付いた。インターネットアクセスが低速だったり不安定だったりして困っている人たちのためには、Speedify を紹介する。複数の接続を組み合わせてパフォーマンスと信頼性を向上させる VPN だ。それからもう一つ、Apple が macOS 11.5.2 をリリースしたが、何が変わったのかの発表が一切なかった。アップデートすべきなのか？ 私たちには分からない！ 今週注目すべき Mac アプリのリリースは 1Password 7.8.7、Firefox 91、それに Timing 2021.5.1 だ。
Apple が macOS Big Sur 11.5.2 をリリースした。リリースノートには「バグ修正」としか書かれていない。セキュリティノートはない。では、何が修正されたのだろうか？ 私たちには分からない！ 早めにインストールすべきなのだろうか？ 全く分からない！ インストールされた方は、もし何か違いに気付かれたならどうぞコメントで知らせて頂きたい。
謎めいていない点が２つある。この macOS 11.5.1 Big Sur アップデートのサイズは 2020 年型 27 インチ iMac で 2.54 GB であり、System Preferences > Software Update からインストールできる。
使用可能な幾つかの Internet 接続はあるが - Wi-Fi, DSL, 衛星, セルラー - どれもとりわけ高速でもないし信頼性もないと言った経験はありませんか？ 私は今日ではその様な問題に遭遇していないので、Speedify を試験してみたことはないが、その有用性は確かにありそうなので、簡潔に紹介する。
簡単に言うと、Speedify はソフトウェアベースの VPN で、複数の Internet 接続を纏めて、より高速の、より安全な、そしてより信頼性のある一つの接続とすることを約束している。チャネルボンディングは性能を上げ、自動フェイルオーバーは信頼性を向上させ、そしてオーディオとビデオストリーミングの自動優先順位付けはストリーミングに適したものとする。
私が思うに、Speedify は、不安定な DSL、むらのある衛星、そして中途半端なセルラーしかない田舎に住む人には有用であろう。たとえ常時安定して働く接続は無いとしても、一緒にすれば良くなる場合もありうる。また、列車で定常的に通勤する人達もおり、列車の Wi-Fi とセルラー接続を結合する事で移動中にもビデオ通話に参加することで恩恵を受けられるであろう。或いは、旅行者は、過密のホテルやカンファレンス Internet 接続をセルラー接続で補うことで恩恵を受けられるかもしれない。個別のセルラーモデムを使えば - 追加のハードウェアが必要になる場合もあり得る - 二つの異なったキャリアからのセルラー接続を結合することすら可能となる。結論は、複数のアカウントに対して支払いする意図があるのであれば、Speedify はより高速で、より信頼性のある Internet アクセスを手にする最善の方法かも知れない。
Speedify アプリは、Mac, iOS, Windows, Android, そして Linux に対して用意されている。30 日間の無料試行があるが、その後の無制限のデータプランは、３年縛りの月額 $4.99 から始まる。月毎のプランは月額 $14.99 だが、１年縛りにすれば月額 $7.49 に下げられる。最大５台の機器まで使え、最大５つのアカウントを提供する家族プランもある。
皆さんの中に Speedify を試してみた方がおられれば、どの様に使っておりそしてどの様に働いたかをコメント経由で知らせて欲しい！
関わりを持つ色々な役割の一つとして、私は Finger Lakes Runners Club の会長兼催事担当役員をしている。昨年、COVID によるレースの中止が増えることを予測して、私は FLRC Challenge を企画した。それは地区の周りで 10 の仮想レースをするもので、走者は幾つかのコースを複数回走り、結果を Webscorer アプリを使って記録し、そして動的なリーダーボードで順位を確かめるというものである。ルールを作り、企画を練り、そして必要となる全ての技術を纏めるのはとても楽しいものであった。それは、地域でも大好評で、146 人の走者がこれ迄の所 12,000 マイルを超える距離を走った。
地域で FLRC Challenge を宣伝するため、私は庭先に差し込む背の低い立て看板をデザインしプリントした - 選挙の度にキノコの様に突如現れるやつである。それを庭先に掲示しても良いと思う会員は、名前と住所を尋ねる簡単な Google Form 経由で登録した。看板が Signs.com から届いた所で、私はどうやって配るかの問題に直面したが、我々の地区はそんなに大きい訳ではないので、Tonya と私は独立記念日の午後に車で回って、看板を設置して回ることにした。(それは輝かしい夏空の日で、我々は全電気自動車である Nissan Leaf を運転して回った。看板に申し込んでくれた人の多くは友人であったので、この記念日を過ごすにはとても良いやり方であった。)
そこで、問題である。43 の異なった住所を回るには、最適の道順は何か？ 一つの住所を Apple の Maps か Google Maps に入力する、そして立ち寄る場所を一つか二つ付け加えるだけなら、簡単至極であるが、43 の立ち寄り場所を持つ最適の道順となると話は別である。Google の My Maps に住所のリストをインポートするのは可能であるが、カスタム地図を Google Maps iPhone アプリにロードし、それに一つの地点からもう一つの地点へと道案内させるやり方は、私には思い浮かばなかった。
少し時間を使って調べてみたら、MapQuest が - 道順を印刷していた時代の MapQuest を覚えていませんか？ - 私の必要としているものそのものを提供している事が分かった。MapQuest の RoutePlanner は、最大 26 の住所を再配置して最短の道順を与えてくれる。(最初、私は何故上限は 26 の住所なのか理解出来なかったが、道順のプレビューを見て、住所には個別のピンがあてがわれ一つの英文字が付与されていることに気付いた。) 43 の住所がある時に、上限が 26 に制限されることは特に問題では無い事が分かった。と言うのも、離れた場所へは、別のドライブを計画する方が賢明であると思われたからである - 何も一回に全部をやる必要はない。
住所を一つずつ入力することも可能だが、ツールを使って住所のリストを一行に一つずつペースト入力する、或いは、住所、市、州、ZIP コードがコラム毎に分かれた形になっていれば、Excel や CSV ファイルからインポートすることも出来る。私は、Google Forms によって作成された Google Sheet にある住所を Command-クリックして、全体を RoutePlanner にコピー＆ペーストするやり方を選んだ。
Get Directions ボタンをクリックすることで、RoutePlanner の Line by Line タブに誘われ、私はそこで一番下までスクロールし (その過程で一つの形式不正の住所を修正し、ハイライトした)、"立ち寄り点の順番の入れ替えを許す" を選択し、そして、地図上で私の道順を見るために View Route Directions をクリックした。それから、地元の知識に基づいて二つ程の立ち寄り点の順序を微調整した。
ここ迄は良しだが、次の質問は、その道順を iPhone が我々に道案内をするために使える形のものにどうやって翻訳するかである。その答えは、上辺にある Share ボタンをクリックすることであった。そうすることで URL の付いたダイアログが現れ、テキストする、メールする、或いは iPhone にコピーするかをさせてくれる。
その URL を iPhone 上の Safari に読み込ませると、それを MapQuest アプリで開く選択肢が提供された。私は小さな iPhone アイコンをタップしてそれを選択し、そして Start ボタンをタップした。
(正直に言うと、上記の二つの段落は、たった今書き終えたのだが、それ迄には一週間以上を要した。MapQuest に自信が待てたとはとても言いがたい。最初、道順を共有するために MapQuest が生成した短い URL は、殆どの場合エラーページとなった。私は、その問題を MapQuest に報告し、彼らはその問題を解決すべく働いていると言われたが、未だ修正の確認は貰っていない。しかしながら、今は働いている様に見える。加えて、SMS 共有もメール共有も最近の試行では働かなかったが、他の方法で URL を iPhone に移すことは出来ている。この共有問題の原因探求をしている間に、私は MapQuest にログインし、道順を My Maps に保存することを試みたが、サイトはそれをするだけの長い時間ログイン状態を保持出来なかった。他には、iPhone 上の Safari で、アプリの中で開く選択肢を持つ黒色のバーは、Safari を強制終了し再度開くまで現れなくなった。先月は、これらの問題のどれも見ていなかったし、今回もどうにか解決出来たが、何れにしろ、イライラのつのる話であった。)
実際に車の中で道案内を受ける段になると、MapQuest アプリは Apple の Maps や Google Maps と程度の差こそあれ同じ様に働く。立ち寄り点で完全に止まらないと多少混乱することもあるし、リストビューに立ち戻ったり、地元の知識を使って道案内しようとしたり、問題の立ち寄り点を完全に見失ったりもした。私のお勧めは、その道案内に注意深く従い、可能な限り、違う道を通るのを避けることである。何故ならば、それらはアプリを混乱させるからである。
"パンデミック下でのグループ "寄せ書き" 作成方法" (6 August 2021) と同様、これは多くの人々は持つことのない特別な問題に対する解であるが、同じ様な状況にいる人には、お役に立てると思われる。
Apple が自らのしくじりを認めることはあまり多くないし、それが公式に発表したことに関してならばなおさらだが、今回 Wall Street Journal の Joanna Stern がインタビューした Apple ソフトウェア責任者 Craig Federighi の口からは謝罪の言葉が何度も発せられた。この記者会見は一週間前に Apple が初めて公開した説明を受けてのものであり、その書類の中には既知の児童性的虐待素材 (CSAM) の流布を抑制するための対策と、それとは別に Messages で未成年者が性的な画像に触れる可能性を減らすための対策との、両方の説明が含まれていた。(2021 年 8 月 7 日の記事“Apple による児童保護拡大機能に関してよくある質問”参照。)
Apple が迷い込んだ誤りの道は上記の２つの互いに無関係な児童保護策を一緒に説明したページをウェブサイトに掲載して混乱を招いたことから始まった。その後 Apple は内容を補足する FAQ 書類を公開したがそれはよくある質問の多くに答えておらず、メディア向けの説明会を何度か開いたが新情報を出したのかそうでないのかよく分からず、低位の重役たちにインタビューさせたりもしていたが、結局最後には Federighi を繰り出して Wall Street Journal のインタビューで語らせることになった。Federighi は CEO の Tim Cook の下で Apple の２番目によく知られた重役であることは明らかであって、話をちゃんとさせるためにこの会社がどれほど真剣に立ち向かわざるを得なかったかを如実に示している。インタビューが公開されたのに続いて、Apple はまたもう一つ 新たな 説明書類 "Security Threat Model Review of Apple’s Child Safety Features" を公開した。さらに、Bloomberg の記事によれば Apple はスタッフたちに対して質問を受ける心構えをしておくようにと伝えたという。まさにこれは PR 活動の大惨事だ。
(以前の記事を目にされずこの記事をお読みになっている方たちにはこの記事の以下の部分が文脈を無視していることをお許し願いたい。要約をしたくてもあまりにも多くの内容があるので、どうか Apple が以前に出していた書類と、上でリンクした私たちの先週の記事とを先にお読み頂きたい。)
Wall Street Journal のインタビューで、Stern は Apple が何をスキャンして何をスキャンしないか、CSAM がどのように識別されどのように報告されるかについて、かなり多くの詳細情報を聞き出した。また、Apple が同時に発表した互いに無関係な２つのテクノロジー、つまり CSAM Detection と、それから Messages における Communications Safety についても、彼女はより踏み込んだ明確化を引き出した。
Federighi が今回明かした中で最も重要な点は、Apple が CSAM 検知に“複数レベルの可監査性”を組み込んだことだ。彼は Stern に次のように語った：
私たちは中国でも、アメリカに出荷するものと同じソフトウェアを、同じデータベースを付けて出荷します。ヨーロッパに出荷するものとも同じです。もしも誰かが (他のタイプのコンテンツを照合せよという要求を携えて) Apple にやって来ても、Apple はノーと答えます。でもここであなたにそれが確信できなかったとしましょう。Apple がノーと言うだけでは信頼を置けなかったとしましょう。Apple がこっそりイエスと言って切り抜けられる事態が起こらない確信が欲しいとあなたが願ったとしましょう。実はそれこそが、このような種類のソフトウェアをリリースするに際して私たちが自らに課したハードルでした。そこには複数レベルの可監査性があって、どの画像がこの処理過程に入り込んでいるかに関しては、どこか一つのものだけを、さらにはどこか一つの国だけを、信頼せざるを得ないという事態が起こらないようにしているのです。
CSAM 検知システム内部の可監査性について Apple が言及したのは今回が初めてだし、ましてや複数レベルのものがあるとは聞いたことがなかった。さらに、Federighi は iCloud Photos へのアップロードの最中に 30 個の画像がマッチしなければ、対応する“安全バウチャー”を通じて Apple がマッチした画像の暗号を解けるようにならないとも明かした。おそらくは、Apple がすべてのオペレーティングシステムで世界中のすべての市場を通じて同じバージョンを出荷しているとはほとんどの人が知らなかっただろう。ただ、今回のインタビューで可監査性について語られた内容はこれですべてであった。
Apple はこのインタビューの後にもう一つ新たな書類、"Security Threat Model Review of Apple’s Child Safety Features" をリリースしたが、Federighi がインタビューの中で複数レベルの可監査性について述べた際には間違いなくこの書類のことを念頭に置いていたのだろう。この書類には、アーキテクチャと可監査性の両面にわたってたくさんの新しい情報が提供されている。
この最新の書類は CSAM 検知システム全般についてより良い説明を与えているけれども、私たちの感じでは Apple が論争の嵐への応答としてこのシステムに関するいくらかの新情報を書き加えたのではないかという気がする。論争が起こらなければ、はたして Apple はユーザーに (あるいはセキュリティ研究者に) 向けて必要な情報を提供し、デバイス上の CSAM ハッシュのデータベースが変更を受けないことを明言するに至っていただろうか？ システムに対するサードパーティの監査について、はたして Apple 社内で何か議論が交わされただろうか？ そのような疑問はさておき、私たちがこの書類の中で最も重要と思った新情報をここに挙げておこう：
改めて全体を見直してみると、Apple がこの発表でどれほど徹底的にヘマをしたか、呆れてしまうほどだ。最初に公開した資料はテクノロジーに詳しいユーザーにもそうでないユーザーにも十分な答を提供しないままあまりにも多くの問題を引き起こしていたし、その後続いた複数のインタビューや書類でもその状態は解消しないままであった。これではまるで、Apple が何を言っても私たちは大いに喜び、こんなに透明性を提供してくれてありがとうと口々に褒めそやすだろうと Apple が思い込んでいたかのようではないか。煎じ詰めれば、他のクラウドベースの写真ストレージプロバイダ各社は既に、アップロードされた写真をすべてユーザーに告げることなくスキャンして CSAM と照合しているのだから。例えば Facebook は 2020 年だけでも 2 千万件以上の CSAM 報告を NCMEC に提出している。
けれども Apple は、"Trust us (Apple を信頼して)" という態度が "What happens on your iPhone, stays on your iPhone" (iPhone 上で起こることはすべて、iPhone 上に留まります) という自らのスローガンに合致しないことを、あまりにも過小評価してしまった。どうやら今になって Apple はその態度を "Trust, but verify (信頼して、でも検証はして)" へと改めたようだ。(この "Trust, but verify" という言い回しには興味深い歴史がある。もともとロシアの諺に由来するものでレーニンとスターリンが言い換えて使い、その後英語の言い回しとして Ronald Reagan 大統領が使ったことで有名になった。) 今回明らかになったことについてセキュリティやプライバシーの研究者たちがどう反応するかはもう少し待たないと分からないが、少なくとも今の Apple は関連する詳細情報をすべて共有しようと努力しているように見える。
