どのアカウントが Unverified として印が付けられているかが見えるというのは、スパムボットアカウントを削除する作業を少しは易しくしてくれており、その作業をやる中で、私はそのスパムボットアカウントに関連する IP アドレスの間にあるある種の共通性に気付いた。(Stop Spammers は WordPress ユーザーリストにあるソースの IP アドレスを表示する。) 見ている内に、私は多くのものがロシアの ISP である Biterika Group によって制御されていることを発見した。もっとも Scamalytics は Biterika Group を現時点で低不正リスクと見做しているが、当時は、間違いなく私のサーバーを攻撃するスパムボットの責任を負っていた。特定のドメインとロシアという国を Stop Spammers を使って阻止しようという私の試みは殆ど役に立たず、私はイライラがつのりそして頭にきて、私は核兵器を手にしそして全 IP アドレス領域をブロックすることとした。それは一般論としては悪い手である。何故ならば、それはまともなユーザーにも影響し、そしてそのリストは管理するのが難しいからである。しかし、ロシアだよ、くそ食らえだ。
(余談だが、Biterika によって制御された 46,000 にものぼる IP アドレスの多くを阻止するこつは CIDR 表記である。CIDR は Classless Inter-Domain Routing の略で、IP アドレス方式の一つである。それは一つの IP アドレスに CIDR を使って沢山の固有の IP アドレスを指定させてくれる。CIDR IP アドレスは通常の IP アドレスの様に見えるが、最後にスラッシュが付き、そして IP network prefix と呼ばれる数字が続く。例を挙げると、Biterika IP アドレスの幾つかは 109.248.204.0 にまつわっていて、私の Stop Spammers 阻止リストに 109.248.204.0/23 を加えることでその IP 範囲からのスパムポッドが私のサイトで何かをするのを阻止出来た。私はこの CIDR を IPV4 計算に使って、使うべき適切な IP ネットワークプレフィックスを決定する。)
全ての Biterika IP アドレスを阻止するのがとてもうまく行ったので、私は全てのスパムボットアカウント上の IP アドレスを調べ、そしてそれ等が英語、オランダ語、或いは日本語を話す国からのもので無ければ、阻止リストに加え始めた。それが何を意味するかを私は十分認識しており、もしどの TidBITS 読者でも阻止されている人は私にメールで連絡して欲しい。問題となる IP アドレスの範囲は取り除く。
ユーザーに確認メッセージのリンクをクリックする事を求め、そしてスパムボット IP アドレスを阻止するのはとても効果的な組み合わせとなっている。時折スパムボットアカウントがすり抜けることもあるが、毎日数百というのに比べれば週に幾つかと言うのは手に負える範囲内である。
ユーザーの観点からすると、我々はここに至るまで幾つかの支障を経験している。私は、ユーザーを助けそして予期しない出来事を解きほぐす Lauri Reinhardt の支援、そして全てのインストールと設定をする Eli Van Zoeren のテックワークにとても感謝している。我々が、メール確認選択肢を正しく構成し、CAPTCHA 認証を提供する複数のプラグインが原因の衝突を解決し、サイトの奥深くにある壊れた Register ボタンを取り除き、TidBITS と TidBITS Talk サイト間のやり取りを解明し (ログインシステムを共有している)、そして色々なエッジケースを解決するのに相応の時間を要した。今となっても、我々は User Verification にバグがあるのではないかと心配している。それはアカウントによっては手動での会員更新の後でも Unverified と印が付く原因だと思われるが、我々は未だそれを追跡し切れていない。
私はこれを直ちにインストールしようと思う。驚くことではないが、私の新しい Apple Watch Series 9 は手にして以来文句なしの電池寿命を示していたが、昨日、私の自転車乗りの後殆ど電池切れになりかけた。ひょっとすると、その前の晩に私はそれを充電器に正しく置かなかったのかも知れないが、Apple があるアップデートは不必要な電池消耗を防ぐはずだと言う度に、私は Install ボタンをためらいなく押す。
HomePod Software 17.1.1
パンデミックの最中、私は沢山の HomeKit スイッチを設置したので、初代 HomePod 上で Siri を使って家中の照明を制御するのに慣れてしまった ("HomeKit のある一年を振り返る" 17 December 2021 参照)。照明を調節する度に Siri と話す時、それがどれ程うまく働いているかの感触を得るものである。(はい、白状します。私は自分の記事の中に書くのは可能な限り避けようとしてきたが、我々は日常生活の中で Siri を完全に擬人化してしまっていて、例えば、昨晩など Tonya は腹立たしく叫んだものだ、"彼女は、今日、どうしようも無く鈍いね" と。)
数週前に、どの程度頻繁に Finder タグを使っているかと皆さんにお尋ねした。十年ほど前に OS X 10.9 Mavericks で導入されて以来、私は Finder タグをあまり好きになれなかったので、今回のアンケートで 56% の人たちが全然使わないと答えたのを見てもそれほど驚かなかった。26% の人たちが時々使うと答え、18% の人たちがいつも使っていると答えた。でもひょっとすると、使わないと答えた私たちは何か大切なことを見落としているのかもしれない。
Finder タグの基本
そもそも Finder タグの目的は、伝統的なフォルダ階層とは別のやり方でファイルやフォルダを整理しようというものだ。一つのファイルは一つのフォルダの中にしか存在できない (ただしエイリアスを作ることはできる) が、一つのファイルに好きなだけ多くのタグを付けることが可能だし、ドライブのあちこちに散らばったファイルをタグでまとめたり、さらには一つの膨大なファイルのコレクションの中からその一部だけを選び出したりすることも可能だ。
私の Mac には何千もの技術論文と何百もの規格文書があります。規格文書にタグ付けしておくことで、手軽に Spotlight 検索を規格文書のみに制限して、論文が出てこないようにできます。また、こちらは頻度が少ないですが特定の系統の規格文書のみに検索を絞るために使ったり、特定のベンダーが出した文書や、時には特定のプロジェクトに関する文書のみに検索を絞ったりもします。
色の選択肢が少な過ぎる： デフォルトで、Finder は色による名前の付いた 7 つのタグを用意している。Red、Orange、Yellow、Green、Blue、Purple、Gray だ。(残念ながら頭文字を並べると Roy G. Bpg となり、虹の七色の Roy G. Biv ほど語呂が良くない。) これらデフォルトのタグの名前を変えることもできるが (もっともそうする理由はあまりないだろうが)、別の色を割り当てることはできない。Finder のウィンドウでタグ付きのファイルを見分ける主な方法は色の付いた丸が表示されることなので、7 色というのはあまりにも少ない。
個人的な感想を言えば、私は Finder タグを使う価値のあるやり方に気付いて、あらためてありがたいと思った。でも、私がタグのヘビーユーザーになることはないだろう。なぜなら、私は Google Drive に依存して仕事をしていて、Google Drive は Mac 間でタグを維持してくれないからだ。でも、私が最近気付いたやり方は、一時的に集めておきたいファイルにタグ付けすると役に立つというものだった。今回のアンケートのお陰でタグが私の意識の第一線を占めるようになったので、これからはタグを賢く使うことで自分のワークフローがより良くなるのではないかという気持ちを持って他の面についても考えてみたいと思っている。皆さんが今後、タグが役に立つかもしれない状況に遭遇した際にタグも選択肢の一つだと思い出して頂ければ嬉しい。
現状では、すべての iMessage 会話がエンド・ツー・エンドのセキュア化をしている。つまり、どちらかのデバイスが最初に 公開鍵と秘密鍵のペア を作成する。それはセキュアに保持され、秘密鍵は双方のデバイスの間で共有され、公開鍵は Apple と共有される。Apple はその公開鍵を key directory service の中で維持し、それを通じて iMessage の参加者たちを接続できるようにする。
Contact Key Verification 機能を有効にした場合には、双方のデバイスがもう一つ 別の 暗号化鍵を生成し、それは双方のデバイス間でセキュアに共有されるが、Apple とはいかなる方法でも共有されない。この新しい鍵は signing と呼ばれるプロセスを通じて、以前に提供された公開鍵を検証するために使われる。あなたのデバイスはその署名を入れたメッセージを Apple に送るが、その際に元の鍵に関する情報は一切明かされない。すると Apple は保存してあった公開鍵と送られた検証用の署名とを使って、その公開鍵が Apple の key directory service の中で変更されたか否かを検証する。
Contact Key Verification 機能を使うために、Apple はあなたと相手の人との双方に短い数字のコードを送り、iMessage 会話の中でお互いに相手の身元を確認できるようにする。(他のメッセージングアプリ、例えば Signal や WhatsApp などもこれに似た検証オプションを提供している。)
仮に、その情報機関が Apple の key directory service に侵入して、Apple に気付かれることなく前者の人たちの公開鍵を自分の手の及ぶ鍵とすり替えることに成功したとしよう。あるいは、何らかの攻撃を通じて Messages アプリが別の公開鍵を受け入れるようにさせたとしよう。(そのようなことが起こる可能性は極めて低いけれども、中央の情報源から公開鍵を配送する部分を攻撃するのが不可能でないことは Apple も認めている。)
これらの out-of-band 手法の目的は、相手の人物がその人の Apple ID とデバイスを確保し続けていると確認することだ。この確認手順により、その人がアカウントのパスワードと第二の要素とを兼ね備えているのを検証することが狙いだ。
もしも上記の手順で数字がマッチせず、それでも相手がその人であることに確信が持てるのならば、何か良くないことが起こったのだと判断できる。例えば二人の間のどこかで何らかの中間者攻撃があったとか、あるいは Apple の鍵サーバか transparency log が改ざんを受けたなどのことが考えられる。その場合は、何が起こったかを見つけ出せる権限を持つ誰かに連絡する必要があるだろう。それはあなたの雇い主かもしれないし、例えば Citizen Lab のような非政府団体の信頼できる人物や、 Apple や、あるいは FBI かもしれない。あなたと相手の人がどんな人物か、二人の間でどのようなプライベートな情報を交換したいかに応じて選ぶことになる。
しかしながらほとんどあらゆる場合において、Contact Key Verification による検証はスムーズに進むはずだ。Messages アプリや Apple の key directory service のセキュリティが破られる可能性は極めて低いからだ。Contact Key Verification 機能の存在そのものによって攻撃しても気付かれることから、より高度な攻撃を思いとどまらせる効果があるかもしれない。
また、このシステムは従来の知り合い関係と既存の iMessage 会話を基盤としているので、第三者があなたが読む認証コードを知っているふりをすることはできない。例えばあなたのコードが "1234 5678" で相手のコードがそれと違う "8765 4321" だったとして、相手が「はい、私のコードとマッチします」と嘘を言ったとしても、あなたが Mark as Verified をタップしても何も起こらない。同じ会話の中にいれば、コードは同一のはずで、それはどの手段でコードにアクセスしたかによらない。相手が同じ会話の中にいなければ、コードはマッチしないはずで、相手はあなたが読んだコードを持っているふりをしても役に立たない。実際、この認証コードは何かが 既に おかしくなっている場合にそれを識別できて、将来の変化に備えて監視の始点とすることができる。
別の見方をすれば、“公人”が認証コードをオンラインに公開してもリスクはないと Apple が述べているのもこれが理由だ。誰かが公人と iMessage 会話を始めたいと思えば、その公開要素に依存してその公人が本人だと証明できる。さらに、Apple はその人たちの公開鍵をその人の Apple ID アカウントに付随した電子メールアドレスと電話番号に対応させることができるので、たとえ誰かがその公人の Apple ID アカウントを乗っ取ったとしても、その人に連絡しようとしてコードを確認した人は詐欺師と顔を合わせることになるだけだ。
Contact Key Verification は長年指摘されてきた問題を解決することにもなる。その昔の 2016 年に、セキュリティ研究者 Matthew Green が iMessage の設計上の根本的欠陥をいくつか指摘して説明した。その中でも最悪な欠陥の一つが「iMessage は脆弱な集中型の鍵サーバに依存している」というものであった。(もう一つの欠陥として Apple が iMessage のプロトコルを公開していないという問題があり、これは今もまだ懸念のままだ。 これらの欠陥について 2016 年に私は Macworld にコラム記事を書いた。)
Apple はブログ記事の中で iMessage システムがその種の攻撃に脆弱性を持つことを率直に認めている：
Apple の Identity Directory Service (IDS) のような key directory service は鍵の漏洩に対処しているとはいうものの、これはセキュリティモデルの中の単一障害点と言えます。強力な敵対者が key directory service を破ることができれば、そのサービスは不正な鍵、つまり敵対者が掌握する秘密鍵に対応する公開鍵を返すようになるでしょう。そうなれば暗号化されたメッセージを敵対者が傍受したり消極的に監視したりすることも可能になります。
ここで key directory service つまり Apple の Identity Directory Service について少し掘り下げてみよう。iMessage の会話では、あなたのデバイスが独自に秘密暗号化鍵を生成するが、Apple がそれにアクセスすることはない。(この鍵が Apple に送信されることはない。) iMessage がセキュアなエンド・ツー・エンドの暗号化で起動されると、あなたの Apple ID アカウントを使って最初に iCloud にログインしたデバイスが、ローカルに保持される公開鍵と秘密鍵のペアを作成している。それからあなたの iCloud アカウントに新たなデバイスを追加するごとに、個々のデバイスがその iCloud セットの中の他のデバイスと鍵を交換するので、どのデバイスもメッセージを暗号化し復号化することができるようになる。
Apple がこのことについてほとんど説明していないので、鍵の交換の話で困惑された方もおられるかもしれない。あなたのデバイスの一つが iCloud で接続された 別の デバイスのパスコード/パスワードの入力が必要だと求めてきた場合、そのパスコード/パスワードは Apple に送信されないので、実は上で述べた鍵の交換が起こっている。あなたの iCloud セットにデバイスを追加すれば、その既存の iCloud セットにある他のデバイスについてあなたのみが知る秘密 (つまりそのパスコード/パスワード) を入力しなければならない。その別のデバイスはそれ独自のパスコードまたはパスワード (およびその他の情報) を使ってさまざまの重要な情報を暗号化している。
実例として、あなたの iPhone と Mac が iCloud にログインしている状態で、あなたが新たに iPad を購入したとしよう。その iPad で iCloud にログインすると、ホーム画面が表示されてから、iPhone のパスコードまたは Mac のその Apple ID に付随したアカウントのログインパスワードを入力するようにと求められるはずだ。あなたが入力すると、その新しい iPad があなたの iCloud アカウントに付随した情報を復号化できるようになって、iCloud のデータ、iCloud Keychain 情報、その他の暗号化されていた情報で Messages にアクセスできるようになる。それからその iPad は自らの独自の鍵を暗号化して、iCloud 経由でそれをあなたの他のデバイスと共有する。このようなデバイス上のみの鍵の交換プロセスを通じて、Apple の知らないところであなたのデバイスすべてが独自の鍵情報を共有できるようになる。
iMessage の会話についてはまた別のプロセスがある。Apple の Identity Directory Service が公開鍵と秘密鍵のペアのうち公開鍵の部分を保存しており、このペアが Apple のエンド・ツー・エンドの暗号化システム全体にわたって使われている 公開鍵暗号方式 と呼ばれるやり方の一部となる。この公開鍵暗号方式はインターネットやコンピュータシステムで広く使われていて、過去に関係のなかった人同士がセキュアに暗号化されたデータをやり取りできるようにしている。その理由は、秘密鍵部分を明かすことなく公開鍵部分を自由に共有することができるからだ。秘密鍵は復号化のためと、送り主の身元とデータが改ざんを受けていないことを証明するために使われる。デバイスが秘密鍵を保持して保護し、秘密鍵がそのデバイスのハードウェアの外へ出ることはない。T2 搭載の Intel Mac と、すべての iPhone、iPad、および Apple silicon 搭載の Mac では、一方通行の Secure Enclave の中にロックされている。その一方で公開鍵の方は、秘密鍵で署名されたあらゆるものの身元を確認できる。
この公開鍵暗号方式の弱点は、一つの公開鍵を誰が持っているかを第三者が検証できる手段が鍵を生成するプロトコルのいかなる部分にも存在していないことだ。そのためにこそ基盤構造が築かれる。その昔の Pretty Good Privacy (PGP) の時代には、鍵サーバがいたる所にあった。その後 Keybase がより現代的な手法を提供したが、それでも依然として信用に依存する部分が多かった。現在 Keybase は Zoom が所有しているが、大規模に採用されたことはなかった。Apple の Identity Directory Service はあらゆる暗号化ソフトウェアとデバイスハードウェアとサーバテクノロジーに Apple が制御の手を及ぼしていることを活用しているが、それでもやはり Apple はセキュリティ研究者たちの指摘が正しいことを認めている。つまり、最高レベルの保護を与えるには十分でない。Apple がそれを認めたのは、スパイウェアを通じた Messages 経由の政府機関による攻撃を Apple が数多く経験したことによる。Apple はこの件で NSO Group を相手に訴訟まで起こしている。(2021 年 11 月 24 日の記事“Apple の訴訟、スパイウェア企業 NSO Group を追う”参照。) この訴訟は数多くの裁判所を経て現在ゆっくりと進展しているところだ。
BusyMac が BusyCal 2023.4.4 をリリースして、Quick Entry をスペイン語、イタリア語、オランダ語の自然言語入力対応で拡張した。このカレンダーアプリはまた、タスクを変更日や作成日の順で並べられるようになり、カレンダーのソースリストにカレンダーをアルファベットに並べるコンテクストメニューオプションを追加し、自分が主催者である Google ミーティングの My Status を変更できるようになり、一部の機能対応を誤って宣伝しているカスタム CalDAV サーバとの同期を改善し、まだ開始していないイベントで移動時間の報告が止まったりリマインダーを出さなくなったりしたバグを修正した。(BusyMac からも Mac App Store からも新規購入 $49.99、無料アップデート、Setapp からも利用可、57.7 MB、リリースノート、macOS 10.15+)
上の質問で「かつ」という言葉を使った理由は Apple One バンドルがあるからだ。例えば私は Apple One Premier に料金を払っているけれども、2 TB の iCloud+ ストレージと Apple Music と Apple TV+ しか使っていない。バンドルに含まれるそれ以外のサービスに興味はない。だから、Apple One を購読している場合は、Apple One 項目を選んだ上で、それに加えてあなたが実際に使っている個々のサービスの項目も必ず選んで頂きたい。それに続く質問で、Apple Music、iCloud+、Apple One についてどのプランを使っているかも示して頂きたい。
