実際、私が System Settings > あなたの名前 > iCloud > Advanced Data Protection へ行って Turn On ボタンをクリックしてみると、Apple ID パスワードの入力を求められたのだが、私が文字を一つ入力した途端にパスワードダイアログが消え、System Settings の画面が点滅してから、下の図に示したエラーダイアログが出た。その後何度か試してみるともう少し先まで進めたが、私はセットアップ手順を進めるためだけに古いデバイスをアカウントから削除するつもりはなかった。
Apple のセキュリティアップデートページによれば、今回のアップデートでは CVE エントリにある脆弱性に対処していないという。Howard Oakley が、今回変更が施されたのは Security フレームワークとキーチェーン関係のいくつかのファイルのみだと報告している。ならば問題は、その「重要なバグ修正」に何が含まれているかだ。
Apple がここでしくじったことに疑問の余地はない。Advanced Data Protection は比較的新しい機能であって Apple ユーザーのうちごく少数の人たちしか使っていないものかもしれないが、上で説明したようなエラーならば自動化されたテストで見つかるべきもののはずだ。おそらく Apple は既にテストのための人的資源の大部分を来たるべき macOS 15 と iOS 18 に振り向けているのだろうが、だからと言ってろくにテストしていないアップデートで現行のユーザー基盤にトラブルを起こしてよいという言い訳にはならない。
私には皆さんの中の誰かのためのプロジェクトがある！ 昔から何度も自認してきたように、私の開発技量は良く言っても弱い、でも私は多くの Apple 管理者やコンサルタント、ひいては残りの我々に利益をもたらすツールを思いついた。
Apple は、同社のオペレーティングシステム、アプリ、機器の多くの技術的側面を文書化した数千ページに及ぶサポート記事と言う広範な知識ベースを維持している。TidBITS では、定期的にこれらの記事にリンクしており、そして読者のJolin Warren からの提案のおかげで、私のクリーンアップマクロは URL をトリミングするので、それ等はあなたの国のデフォルトの Apple サポートサイトを読み込むはずである。
ちょっと前に、私は Apple サポートの URL が数値パターンに従っていることに気づいた。例えば、Apple の最新のセキュリティ更新プログラムリリースノートのURL は次の様になっている：
ご覧の通り、"HT" の後の６桁の ID 番号はリリースごとに１ずつ増加するが、 IDはリリースに対しては無作為に割り当てられている。これらの URL の多くを手で作成しそして幾つかの数字を推測することで、私は Apple が時間の経過とともに他の６桁の範囲も使ってきたと判断した。最近の多くの URL は 213 と 214 で始まるが、100-119 と 201-212 で始まる URL も見つけた。私はこれ等の範囲の背後にあるパターンを未だ発見しておらず、そして Apple は理由はわからないが幾つかの ID をとばしてもいる。
実現方法を探る
私は Apple がしている事を最初に理解した時、Dejal の Web 監視アプリ Simonを使ってこれらのページのいずれかが変更されたかどうかを私に教えて貰うことを考えた。私はこのやり方では余り先に進めなかった。何故ならば、私にはプログラム的な方法で Simon に何千もの URL を供給する方法がわからなかったし、それに、定期的に調べるためには私の Mac に負荷をかけ過ぎるかもしれないように思えたからである。他の Web 監視ツールも同じ問題を抱えていた - それ等は数千ページではなく、ほんの少数のページを見るように設計されている。
次に、私は６桁の ID のための列、各 ID をその URL ルートに追加した列、そして、数式 =Hyperlink($A2, IMPORTXML($A2,"//title")) を使って結果のページのハイパーリンクされたタイトルを見つけて取り込む Google Sheet を作成した。すべての ID がアクティブなページにマップされるわけではないので、一部のセルは #N/A で埋められた。
更なる追加クレジットのために、ソースページを参照する回答を使って、ナレッジベースとの会話を可能にする AI チャットボットを作成する。
これは相応の Web 開発才能を持つ人にとってはそれほど難しくないと信じたいのだが、私の技術力では到底及ばない。(それを作成するために手を挙げてくれた訳ではないが、Glenn Fleishman は、データを保存、差分を取り、そして表示し、更にコミュニティ注釈のオプションを提供する簡単な方法は Wiki サイトかもしれないと提案してくれた。) 私は、誰かがそれをやりがいのある挑戦だと思い、実際にそれを構築することを期待して、この考えを共有している。私は喜んで協力させて貰うし、必要ならばホスティングのお手伝いもしたい。一緒にする気はありませんか？ そのようなツールで見たい他の機能はありませんか？
私が Apple のベータ版について記事を書くことが滅多にないのは、記事を書いた時点と Apple がベータ版のアップデートを出したり正式版をリリースしたりする時点との間で何かが大きく変わることが十分あり得るからだ。皆さんの時間や私の時間を無駄に費やすことは望まない。
でも、何かが変わる べき だと思う場合には話が違う。現時点での macOS ベータ版の中にある Apple 最大の誤りの可能性と思われるものがまさにそれで、今ならまだ Apple はそこから引き返すことができる。具体的には、画面記録を利用するアプリの再認可を承認するか否かを macOS 15 Sequoia がひっきりなしに尋ねてくるのだ。単にスクリーンショットアプリのみならず、他にも数多くのユーティリティがそれに該当する。この挙動は、使い勝手を悪くし、ユーザーの不満を増し、セキュリティに対する認識を減らす。
Continue to Allow
開発者用ベータ版の macOS 15.1 Sequoia を私の M1 MacBook Air にインストールしてから数日後、何かがひどくおかしいと気付いた。私は TidBITS や TCN の記事を書く際に数多くのスクリーンショットを撮るのだが、そのために CleanShot X を使っている。システムをアップグレードしてから最初にこのアプリを使った際に引き続き CleanShot X がスクリーンをキャプチャすることを承認するかと尋ねられたが、私は驚きもせずに承認を与えた。オペレーティングシステムを完全にアップグレードしたのだから、私たちが既に承認済みでしばらくそのことを忘れていたようなものであっても改めて承認させたいと Apple が考えるのも自然なことだろうと思われた。(人によっては、それをきっかけに何年も使っていなかったユーティリティやその他のアプリを自分がまだ走らせていたと気付くこともあるだろう。)
けれども、それからあまり時間も経たないうちにまたもや同じプロンプトが出て、私はびっくりした。その後一日か二日経ってさらにまた同じことを尋ねられて私はますます苛立った。そしてまた同じことが、何度も何度も起こった。そうこうするうちに、私はどうにもならない気持ちになって、これは記事にしなければならないと心を決め、問題のダイアログのスクリーンショットを撮ろうと試みた。それはなかなか難しい注文だった。なぜなら、Continue To Allow ボタンをクリックした後でなければ CleanShot X にスクリーンショットをキャプチャする許可が与えられないからだ。(ちなみに、Apple Style Guide に規定されている大文字の使い方のルールに従うならば、このボタンの文言は "Continue to Allow" でなければならないはずなのだが。) スクリーンショットを撮ろうとすると最初のダイアログの上に第二のダイアログが重なって表示され、macOS が数分間応答しなくなった。それでも辛抱強く待てば、結局双方のダイアログの Continue To Allow を押すことができ、作業を続けることができた。問題は、スクリーンショットのためにダイアログを選択しようとしている間も CleanShot X がすべてのマウスクリックをキャプチャし続けるので、Continue To Allow ボタンを正しくクリックできなくなるのだった。結局、このスクリーンショットを撮る正しい方法は、まず Escape キーを押して CleanShot X のスクリーンショットキャプチャモードを脱してから、その後で Apple の内蔵スクリーンショットツールを使うことだと分かった。驚くには当たらないが、Apple の内蔵ツールは承認を必要としない。奇妙なことに、Open System Settings と書かれたもう一つのボタンをクリックしても Continue To Allow ボタンと同じことしか起こらず、System Settings を開いてみてもこのリクエストに関するそれ以上の説明は見つからなかった。
セキュリティ通知と認証リクエストで良いバランスを実現することは、この上なく厄介な問題だ。あまりにも頻繁にダイアログを出せば、ユーザーは苛立ち、反射的に OK をクリックするようになるだろう。あまりにも数多いアラートが単なる騒音と化してユーザーが読まなくなってしまえば、それはセキュリティ機能として失敗だ。そうなればいずれは、マルウェアが許可を求め、ユーザーが何も考えずに許可を与えるという事態に結び付くだろう。言わば、「狼が来た！」と叫ぶ少年の寓話の現代版だ。
私たちは既にセキュリティアラート過多の境界を越えている。私の眼前にベータ版 Sequoia が再認可を求めるプロンプトを出した初めの一回か二回は、書いていた記事に使うスクリーンショットを撮るために Continue To Allow をクリックしなければならないと判断する目的以外にそこに示されたテキストを読むことさえしなかったのが実態だった。このダイアログは私が押したキーボードショートカットに対する直接的な応答として開いたのだし、私はもう何年も CleanShot X を信用して使ってきた。その後さらに何回かこのダイアログが開いてから、私はやっとそこに書かれたテキストを注意して読み、自分が何かを見落としていなかったか確かめようとした。でも私は何も見落としてなどいなかった。
どうやら Apple はスクリーン (あるいはオーディオ) を監視するサードパーティのアプリはすべて悪意あるものである可能性を秘めていると見なしているようだ。それは、セキュリティの枠組みを開発するための基盤としては問題ある考え方ではないかもしれないが、現実世界においては明白に事実と異なる。私の推測だが、あらゆる Mac 上にあるアプリの 99% 以上が正当なものだ。そう思う理由は単純で、悪意あるアプリを意図的に自分でインストールしたり普段から走らせたりする人は誰もいないからだ。
iOS で Apple が位置情報へのアクセスの承認アラートを追加して、バックグラウンドで位置情報へのアクセスが何週間も何か月も続いた後に時折そのアラートを出すようにしたことは理解できる。そのアラートはこれまでに追跡された回数を表示し、そのデバイスがこれまでに提供した位置情報を地図上に示し、それに応じて適切な行動を取れるようにしている。そのダイアログでは、位置情報へのアクセスを "only while using" に切り替えることもできる。これはおそらく、旅行中に承認を与えたけれども帰宅後にそのことを忘れていてずっと追跡され続けているような事態を防ぐものなのだろう。あるいは、そもそもインストールしたのを忘れて承認したことさえ全く覚えていなかったということもあるかもしれない。いずれにせよ、その手順は意味をなしているし、そもそも稀にしかポップアップしないものだ。
けれども事実上ほとんど存在しない脅威のための保護を追加して意味あるアクションさえ伴わず警告を提供すれば、それは Mac の使用体験に悪影響を与えるものでしかない。それを批評するためその昔の Windows Vista を引き合いに出した評論家も一人ならずいた。当時 Windows Vista は過剰なセキュリティダイアログでよく知られ、他ならぬ Apple からのあざけりが世を騒がしたのだ。Mac ユーザーのほとんどがそうだと思うが、私は 2007 年に出荷された当時の Windows Vista を使ったことがないので、また聞きのこの比較に実感がなかった。でも、Stack Overflow と Discourse の共同創設者 Jeff Atwood が 2006 年に書いた記事を見つけた。彼は「終わりなき警告ダイアログを通したセキュリティ」では機能しないと警告しているが、彼が挙げた理由もまた、あの実証済みの理由と全く同じものだ：
Microsoft が 15 年以上前に陥った誤りを Apple が繰り返そうとしているのを見るのは何とも気が滅入る。
Apple の実際の意図は？
いったいなぜ Apple はこれらのさらなる承認プロンプトを追加しようとしているのか、私は不思議に思う。アプリというものは一週間もすれば暗黒の側に回ってしまうものであり かつ 私たちがそれと知る唯一の方法は画面記録の承認を既に与えているアプリがプロンプトを出して念押しすることだと Apple のセキュリティチームが考えている、というのが安直な答だろう。でもその答は明らかに馬鹿げている。月曜日にユーザーがあるアプリを信用していて、その次の月曜日までそのアプリに何の変化もなければ、従来の信用レベルを変更すべき理由は何もない。もしも何か変化があったならば、そもそも Apple が自らのアンチマルウェアシステムを使ってそのアプリが走らないようブロックするはずではないのか？
ひょっとするとその変更は、しばらく前に Apple があまりにも静かに Touch ID と Face ID のパスコード要件を格上げした際の成功に促されてのものだったかもしれない。例えば再起動後などに iPhone や iPad でパスコードを (Mac ではパスワードを) 入力しなければならないようにした状況に加えて、Apple は新たに 6.5 日間のカウントダウン時計を追加して、パスコードが入力される度にカウントダウンをスタートさせるようにした。その期間が過ぎれば第二の 4 時間タイマーがスタートする。その間に Touch ID か Face ID を使ってデバイスのロックを外さなければ、次に使おうとした際にパスコードの入力を求められる。少なくとも週に一回はパスコードを入力しなければならないというのはユーザーにとって些細な厄介事だが、全体的に見ればセキュリティ的に良いことだと言える。なぜなら、習慣的に入力させられることで人々は自分のパスコードを忘れなくなるからだ。
