Stage Manager は iPadOS 16 の目玉機能で、iPad に Mac 風のウィンドウイングを追加するものだが、Apple が M1 搭載の iPad をその要件としたことが論議を呼んでいる。Josh Centers が、Apple が述べた論拠を調べるとともに、事態を収拾するために Apple ができることを提案する。Adam Engst が、Citibank が TidBITS は暗号通貨の販売をしていると誤解して会費支払いの処理を拒否した顛末を語る。それから Adam が、互いに連動し合う3つの Apple プライバシー機能、"iCloud プライベートリレー" と "IP アドレスのトラッキングを制限" と "IP アドレスを隠す" が奇妙な接続性の問題を引き起こすことがある理由を解説する。今週注目すべき Mac アプリのリリースは BusyCal 2022.2.3、Camo Studio 1.7、それに Evernote 10.39 だ。
ここ数週間はとても忙しくて他には手も回せないぐらいであったが、殆ど進展は見られないように思えた。私の週のかなりの部分は、何人かの TidBITS 読者に影響を及ぼしていた奇妙な問題を解決するのに費やされた。問題の最初の数日間はとてもイライラの募るものであったが、その解決は喜ばしいだけでなく、如何に TidBITS 読者が素晴らしく助けの手を差し伸べてくれるかに対する証しでもあった。
我々は問題を抱えているという最初の兆しは、我々のサポート達人である Lauri Reinhardt から来た。彼女は一人の TidBITS 読者を手助けしていた。この人のメンバーシップ更新は銀行によって拒まれていたのである。彼が Citibank に連絡を取ったら、その顧客サービス係員は、その取引は暗号通貨として流されたので通らなかったのだと言った。(これは明らかに馬鹿げている。とりわけこの分野全体に対する我々の公にしている不信感を考えれば - "暗号通貨を理解しよう、でも投資してはいけない" 20 April 2022 参照。) 彼の抗議は聞き入れて貰えなかったので、彼は Lauri に連絡してきた。彼女は Stripe の取引ログに目を通したが、暗号通貨に関係するものは何も見つけられなかった。しかし、彼女は更新失敗の事例が増えていることに気付いた。
彼女がこれを報告した時、我々の開発者 Eli もまた目を通し、そして失敗した取引の殆どは transaction_not_allowed
(取引不許可) という拒否コードを持っており、それらの全ては Citibank から来ている事を発見した。同時に、私も TidBITS Content Network 加入者の一人から更新出来なかった話を聞いた。そして、彼もまた Citibank クレジットカードを使っていたことが判明した。
Stripe サポートと連絡を取るべき時が来た。この問題は、これ迄の所今月だけで 10 人の人にしか影響していないが、悪化の兆しは明らかであり、それに別の銀行からの他のクレジットカードに切り替えられる人ばかりではない。当時、私はそれはもっと一般的な Stripe 絡みの問題なのかも知れないなどと考えたりしていたが、結果的にはそうではないことが分かった。
より手短に言えば、Stripe のメールサポートは、たまたま Tristan と言う名前の人だが、同情的ではあったが、Stripe は何も間違ったことはしていないと筋を曲げなかった。この時期、もっと多くの TidBITS 読者が Citibank と話をしており、それ等全てが Citibank は我々が暗号通貨を売っていると主張する話に帰着していた。何年もの間 Citibank や他のクレジットカード会社は暗号通貨を許可していない。(思うに、これは暗号通貨の色々な形での不安定さに関係しているのかもしれない。) Citibank に非を認めさせ取引を許可させることの出来た人は一人もなく、読者の Brian Stone は、これ迄隣の家の犬を相手に話をしていたのかもしれないと迄言っていた。
私は Citibank の顧客ではないし、自分で Citibank に電話をする手段を見つけられないでいたので、Tristan に上に上げるよう要請し続けた。最後には、電話を掛けてくれるよう要請する Stripe のサポート選択肢を使った。そして、驚くことに、数分後に Tristan からの電話を受けた。彼はその日は電話サポートの当番で、私と話すとは全く予期していなかった。彼は強い Irish なまりがあったがとても親切で、一方では Stripe が間違ったことをしていたしるしは見つけられないことを繰り返したが (私もそれには同意した)、彼はこの問題を解決出来る立場にいるのは Stripe しかないという私の論点は理解してくれた。彼は他に誰か助けてくれる人がいるか調べてみることを約束した。次に、Tony が電話をして来て、それから Charles からも電話があり、そして Stripe の誰かが Citibank に電話をすべきだとの私の執拗な要求に直面しても頑として公式見解を示した。しかし、私が TidBITS にこの体験談を書くかも知れないと発言すると、Charles は Matt を連れてきた。
Matt が私を助けてくれる結果となった背景に裏での会話があったのかどうかは私には分からないが、彼は長年の TidBITS 読者で、TidBITS は暗号通貨とは何の関係もないことを良く理解していた。彼は Stripe の中で Citibank に電話の出来る人を捜すと約束したが、その前に、彼はこの論議には新しいものを紹介した:Merchant Category Code (MCC, 加盟店業種コード) である。彼は、この MCC に対する変更が時としてこの様な問題を引き起こす可能性について触れたが、我々のものは最近変わっていないので、彼はそれが原因だとは思わなかった。
"ちょっと待って!" と私は思った。我々が MCC を持っている事すら私は知らなかったが、もし我々のものが正確でなかったら、ひょっとすると Citibank 側で何かを変えてその結果我々の取引を誤認し始めたのではないか。Matt によると、我々の MCC は次の様に進化してきた:
- Computer Software Stores (February 2018 から July 2018)
- Computer Programming (July 2018 から August 2018)
- Computers, Peripherals, and Software (August 2018 から October 2020)
- Computer Programming (October 2020 から現在まで)
これらの変更全ては Stripe のアルゴリズムによってなされており、どれも我々がやっていることを的確に表現してはいなかった。正確な MCC を得るためには人間による介入が必要となることもあると言いつつ、Matt は私にそのリストを提供してくれた。TidBITS メンバーシップに対して、私は "Miscellaneous Publishing and Printing (各種出版及び印刷)" を選び、そして (翌日に、と言うのも最初は思い付かなかったので) "Digital Goods Media: Books, Movies, Music (デジタル物品メディア:書籍、映画、音楽)" を TidBITS Content Network に対して選んだ。Matt はそれ等のコードを私に代わって変更してくれた。それ以降、支払い依頼の再試行は即座に働いた。ついに!
終わり良ければ全てよしで、私は自分の好み以上に強引でなければならなかったが、ねばりは報われた。背後で起こっていることを積極的に共有しようとしてくれた Stripe 内の TidBITS 読者に到達することで、私はついにこの問題を解く鍵を見つけた。
実際、それは今月 TidBITS 読者が我々を助けてくれた二例目であった。私が "LittleBITS: 速度とセキュリティのためのウェブサイト変更" (6 June 2022) で Cloudflare の Automatic Platform Optimization サービスに関連した記事を書いた時、TidBITS 読者の Jonas と言う名前の Cloudflare の技術サイドで働いている人が、メールをくれて歓迎出来る助言をしてくれた。Matt と Jonas に感謝したい! Eli が後になって皮肉っぽく口にしたことだが、大いなるサポートを得る一つの方法は、32 年をかけて忠実な支持層を得ることだ。私はそれを良い行いに対する報酬だと思いたい。
討論に参加
iPadOS 16 は、長らく待ち望まれた機能と (2022 年 6 月 6 日の記事“WWDC 2022 で“やっとのことで”登場した機能 10 個”参照) 私たちが困惑して頭を掻きたくなってしまった機能 (2022 年 6 月 13 日の記事“WWDC 2022 で登場したが困惑してしまう機能 7 個”参照) の両方を提供する。多くの意味でその目玉機能と言えるのが Stage Manager で、これは iPad 上にお馴染みの、しかしいくらか制約のある、ウィンドウイングシステムを追加するものだ。
ただ、一つだけ問題がある。この機能は M1 チップを搭載したハイエンドの iPad を要求するのだ。(2022 年 6 月 9 日の記事“Apple の 2022 年版オペレーティングシステムにおける本当のシステム要件”参照。) 現行のモデルはたった 3 つしかない。つまり第5世代 Pad Air と、第5世代 12.9 インチ iPad Pro と、第3世代 11 インチ iPad Pro のみだ。(Stage Manager は macOS 13 Ventura の走るすべての Mac でも動作するが、圧倒的大多数の Mac ユーザーは Stage Manager の新しい枠組みよりも長年慣れ親しんだやり方を使い続けたいと思うだろうという点に Apple 自身でさえ同意している。)
最近のモデルの M1 を搭載しない iPad を持つ人たちを筆頭に、多くのユーザーたちがこの点に不満を感じている。実際、Apple は被害を最小限に抑えようと、その論拠を説明する旅へと踏み出している。
Apple の説明: Stage Manager は M1 のパフォーマンスを必要とする
論議に対して Apple が示した最初の反応は、YouTuber でありベテランの Apple コメンテーターでもある Rene Ritchie に対して示された声明であった:
Stage Manager は全く新しいウィンドウイング体験を提供するフル統合体験であって、信じられないほど高速で反応性も良く、iPad に加えて最大 6K の解像度を持つ外付けディスプレイとでユーザーが 8 つのアプリを同時に走らせられるものです。iPad のタッチ第一の体験でユーザーが期待する即時性を伴ってこの体験を提供できるためには、大きな内蔵メモリと、信じられないほど高速なストレージと、柔軟性を持った外付けディスプレイの I/O とが必要で、そのすべてが M1 チップを搭載した iPad によって実現されるのです。
要するに、Apple は Stage Manager が M1 以外の Apple チップでは動作しない、少なくともうまくは動作しないと言っているのであって、Apple の Craig Federighi は Forbes とのインタビューで次のように説明している:
私たちはこれらのシステムを含んだ試作品を作り始め、その初期の時点でこれではデザインの目標となっている体験を提供できないことが明らかとなりました。もちろん、新しい体験をできる限りすべてのデバイスで実現したいと心から思っていますけれども、それと同時に新しい体験の定義で妥協したいとも思いませんし、その体験で未来のための最良の基礎を築くのを諦めたいとも思いません。本当に、それを構築できるのは M1 の上でしかできなかったのです。
Federighi は TechCrunch とのインタビューで、反応性について再び強調した:
M1 での構築も極めて重要でした。そもそもの初めから、iPad は常に反応性と双方向性のための高い基準を維持してきました。すべてのアプリがすべてのタッチに即座に反応するというやり取りの直接性、まるでスクリーンの下にある本物に触っているような感覚です。それを達成するために生じる技術的制約を受け入れることが時として困難であることはわかっているつもりです。
要するに、Mac ならば時として反応が遅くても許されるけれども、iPad では仮想の表現でなく本物のオブジェクトとやり取りしているという錯覚を維持させるためにタッチインターフェイスの即座の反応性が要求されるから、ということだ。私たちも Mac でならば時折カーソルがビーチボールになって回り続けても、ポインタの動きが時々ギクシャクしてもそんなことには慣れっこだが、Apple はその種の問題を iPad 体験から取り除くために懸命に取り組んできた。Federighi はスクリーン上の複数個のアプリでそれだけのレベルの反応性を維持するために Apple は大変な苦労をしたと語った:
そしてそこに複数個のアプリと、スクリーン上の大量の面積とが加わると、そのアプリの一つ一つのタッチに対する即座の反応が、デスクトップのアプリでは期待していなかったレベルで実現されることを確実にしなければなりません。間接的な操作ではそこに緩みが生じてしまいますから、これは全く違った種類の制約となります。
より技術的なレベルで、彼は次のように述べた:
非常に高い能力を持つ高能力 DRAM と高パフォーマンスの NAND を持つ M1 iPad のみが、私たちの仮想メモリスワップを超高速でこなすことができます。パネル上に 4 個、加えてさらに 4 個、全部で最大 8 個のアプリがすべて即座に反応でき、十分なメモリを持てるようにするのですから、他のシステムでは到底そんな能力を持たないのです。
Stage Manager は iPad 上で同時に 4 つのアプリを開いておくことができるが、それに加えて外付けディスプレイの上にさらにあと 4 つのアプリを置いてデスクトップを拡張することを許す。理論的に言えば Apple としてはパワーの劣る iPad でその外付けディスプレイ対応を Stage Manager から外すこともできたかもしれないが、Apple はその点を Stage Manager の本質的核心だと見なしている。Federighi はこう続けた:
私たちは Stage Manager を、外付けディスプレイ接続性も含めた総合体験とも見なしています。M1 上の IO は従来の iPad では実現できなかった接続性に対応していますので、4K, 5K, 6K のディスプレイを駆動でき、スケールした解像度でそれらを駆動できます。他の iPad ではそれができません。
最後にもう一つ、この要件の一つの要因として、あの大昔の電子メールクライアント Eudora が "trendy 3D junk" と呼んだ、余分な飾り立てがあるのではないかと思う人もいるだろうが、Federighi はそのことについても言葉を変えて言い添えた:
私たちは Stage Manager を本当の意味で M1 の利点をフルに活用するように設計しました。アプリが傾いたり影を持ったりする様子を、開いたり閉じたりする際のアニメーションを、ご覧下さい。それを極めて高いフレームレートで、非常に大きなディスプレイや複数のディスプレイで実現するためには、他の誰にも供給できない極限のグラフィックス・パフォーマンスが必要なのです。
Apple は Stage Manager を非力な iPad でも動作するように設計できたか?
Apple ファンたちの間では、Stage Manager が本当に M1 非搭載の iPad では動かないのか、それとも Apple がハイエンドの iPad をもっと販売したいという動機もあってわざとそのようにしたのか、という議論が交わされていた。Federighi が述べたことを注意深く読めば、その両方とも正しいことが分かると私は思う。TechCrunch とのインタビューで、Federighi は Apple がいかなる意味でも機能を限定することを望まず、過去でなく未来を目指している、と明確に述べた:
これらすべてを考え合わせれば、私たちにはいかなる非力なシステムにおいても Stage Manager のフル体験を提供することができません。いやもちろん、できる限りいたる所で提供できればどんなに素晴らしいかと思います。でも、要求されるのはこれなのです。これこそが、私たちが未来へ持ち込む体験なのです。何か非力なもののために私たちのデザインに制約を課すことは望みませんし、私たちは未来のための基準を据えようとしているのです。
単刀直入な言葉で言い換えれば、Apple は Stage Manager が M1 非搭載の iPad でも動作するように設計することは可能だっただろうけれども、そのために全体的な体験を低下させることはしたくなかったのだ。それは必ずしも Apple による悪辣な陰謀ではなくて、むしろ Apple がビジネス上の決断をする際の標準的なやり方と言うべきだろう。Apple の観点からは、それはあらゆる面での勝利だ。Stage Manager は:
- 豊かなマルチタスキング体験を提供することで、人々は iPad を欲しがる
- M1 非搭載の iPad を持っているユーザーにはアップグレードの動機を与える
- 既に M1 搭載 iPad を持っている人には購入を正当化するものとなる
Apple は多くの分野でこの考え方を使っている。例えば、ユーザーが自分の挙動をアプリに追跡させないようにできる App Tracking Transparency 機能は、プライバシーに関する大きな勝利であるとともに、Apple エコシステムの強力なセールスポイントでもある。それにまた、Facebook のような競争相手を弱体化させるとともに、Apple 自身の広告ビジネスを強化する役にも立つ。
Apple は開発者 (と窮地に立ったテクノロジー系筆者) に向けて何ができるか
大多数の iPad ユーザーたちはこの論争のことを知らないだろうし、Stage Manager がなくても何とも思わないかもしれない。テクノロジー志向の強くないユーザーには、iPad はシンプルで有能なコンピューティングデバイスだ。他方、パワーユーザーたちは既にハイエンドの iPad を持っているか、あるいは仕事の大部分をフル機能の Mac でこなしていることだろう。Stage Manager はそのような iPad パワーユーザー向けの上級機能であり、M1 非搭載の iPad を持つ人には次回のアップグレードに投資するための理由ともなるだろう。
しかしながら、ユーザーたちよりも開発者たちの方が、この M1 要件を腹立たしく思うより強い動機を持つかもしれない。開発者 Steve Troughton-Smith は、大多数の開発者が M1 iPad を持っておらず、iOS Simulator も公式には Stage Manager に対応していないので、そういう開発者は自分のアプリを Stage Manager 用に最適化することが困難になるだろうと指摘する。M1 iPad を持つユーザーたちは、お気に入りのサードパーティ製アプリで Stage Manager がすぐには期待通りに動作しないと知ってがっかりするかもしれない。
Troughton-Smith は、Apple がベータテスターには M1 非搭載 iPad でも Stage Manager を使えるようにしてくれたらと提案する。私もそのアイデアに強く同感だが、それにはいくつかの理由がある:
- より多くの開発者たちが自分のアプリが Stage Manager でうまく働くように最適化することができ、それは M1 iPad を持っている人たちにとって嬉しいことだ。
- Apple が Stage Manager のパフォーマンス要件について真実を言っていると仮定しての話だが、そうすることで Stage Manager が本当に M1 チップを必要とすることが実証される。
- 対応外の iPad を使っているベータテスターたちは、ベータ版だから動作が不十分なのだと理解してくれる。
- 窮地に立った私のような哀れなテクノロジー系筆者も、機能について執筆することができるようになる。
もちろん Apple はこの最後の点については一切気にしないだろうし、独立のライターたちをお呼びでない競争相手と見ている節もなくはない。でも現状では、私は Take Control of iOS 15 and iPadOS 15 を新版に書き換えることに関して難しい立場にいる。なぜなら、私は去年購入したベースモデルの iPad しか持っておらず、私はこれを A12 Bionic チップを必要とする機能をテストするために購入したのだった。私はテスト以外の目的にこの iPad をほとんど使っていないので、アップグレードするかどうかについて板挟みの状態だ。ビデオを見ながら動作の仕方を推測するだけで済ませるか、それとも M1 iPad を購入して 14 日間の期日のうちに返品するか、それとも遠くにある Apple Store で午後を費やして長居するか、迷うところだ。
Stage Manager の起源
面白いことに、Stage Manager は元々 2006 年に "shrinkydink" という名前のプロトタイプとして考え出されたものであった。当時 Apple で開発の仕事をしていた人物がそのことをブログに書き、プロトタイプのスクリーンショットを載せたが、それを見れば当初のデザインからほとんど変わっていないことが見て取れる。元のブログ記事は既に削除されている (おそらく Apple Legal の命令によるものだろう) が、アーカイブされたバージョンは今も読める。
討論に参加
ウェブサイトをロードする際の問題が、最近になってポツポツと聞こえて来るようになった。細かな点はいろいろと違うけれども、共通して言えるのは問題が macOS 12.4 Monterey で始まったという点だ。問題は Safari だけで起こることもあったけれども、Chrome やその他のブラウザに影響することもある。ページ全体がどうしてもロードしない場合もあるし、ページの一部分だけロードしない場合もある。
私がこれまで見聞きした限りでは、この問題への単純な解決策が一つある。それは、System Preferences > Network を開いて、使用中のネットワークアダプタ一つ一つに対して "IP アドレスのトラッキングを制限" をオフにすることだ。(下の図では Ethernet と Wi-Fi に対するものが示してあるが、両者は驚くほど違っている。)
人によっては iOS 15 や iPadOS 15 でも問題が起こっている。Apple は同じ "IP アドレスのトラッキングを制限" オプションを Settings > Wi-Fi > ネットワーク名 と Settings > Cellular > Cellular Data Options に提供している。
上の iPhone スクリーンショットで細かな文字で書かれたところを読めば、そこに「これをオフにすれば、iCloud プライベートリレーがこのネットワークでもオフに切り替わります」と書いてあるのが分かる。私の iPhone にこのメッセージが表示されるのはこの iPhone で iCloud プライベートリレーを有効にしているからであり、一方それをオフにしてある私の Mac では表示されない。
ここで何が起こっているのかをもっとよく理解できたらいいのにとは思うが、悪意ある当事者によるトラッキングを防ぐための機能をテストするのはこの上なく困難だ。私には悪意はないし、当事者でもないからだ。さらにもっと状況を不透明にしているのが、IP アドレスのトラッキングを制限したり IP アドレスを隠したりと称する機能が完全に別々の 3 つの場所に分かれて存在しているという事実だ:
- iCloud プライベートリレー: この包括的なプライバシー機能はすべてのトラフィックを 2 つの個別のインターネットリレーに分けて送ることにより、接続しようとしているサイトからあなたの IP アドレスを隠す。Mac 上では System Preferences > Apple ID で、iOS や iPadOS では Settings > あなたの名前 で、それぞれオン/オフできる。
- IP アドレスのトラッキングを制限: このオプションはあなたが使っている個々のネットワークに付随しており、Wi-Fi、Ethernet、セルラーそれぞれに存在している。さきほど述べた通り、iCloud プライベートリレーがオンになっているかオフになっているかに応じて表示される説明が変わる。
- IP アドレスを隠す: Safari と Mail はそれぞれに環境設定でこのオプションを提供しているが、それが iCloud プライベートリレーとどう関係するかについてはほとんど何も述べていない。
きっとこうなっているのだろうと私が推測することと、私にはよく分からないところを、以下で説明してみたい。この情報を利用して、プライバシーの向上と接続性の問題点の増加との間の微妙な境界線を皆さんが見極めて下さることを願っている。
iCloud プライベートリレー
ネットワークの不具合が時々起こるようになった場合にまず最初にチェックすべきは、iCloud プライベートリレーだ。この機能は追加のストレージ料金を Apple に払っている iCloud+ 購読者のみが利用できるものだが、すべてのトラフィックを 2 つの個別のインターネットリレーに分けて送る。片方は Apple が運用しているもので、もう片方は Akamai、Cloudflare、Fastly. などメジャーなコンテンツ配信ネットワークが運用している。詳細を説明したホワイトペーパーを Apple が出しているが、基本的なことだけを述べれば次のようになる。
プライバシーを確保できるのは、あなたの ISP と Apple のみがあなたの IP アドレスを知っているからだ。ISP と、その最初のリレー ("ingress proxy" と呼ばれる) が接続をあなたと関連付け、返事をあなたに送り返す。けれどもロードしようとしているウェブサイトのアドレスは暗号化されるので、ISP も Apple もあなたがどこへ行こうとしているのかを知ることができない。
2 つ目のリレー ("egress proxy" と呼ばれる) はリクエストに対して新たな、一時的な IP アドレスを割り当て、行く先のウェブサイトのアドレスを復号化し、その遠隔サイトへの接続を完了する。つまり、この egress proxy はあなたの IP アドレスを知らず、世界の中のどの領域か程度のおおよその情報しか得ないのでジオロケーションが問題になることはない。
Apple は iCloud プライベートリレーが問題を起こす可能性があることを認めている。一つには、それが新しい移送プロトコルを使っているからだ。また、iCloud プライベートリレーが DNS サーバに取って代わることが問題の原因となることもあり得る。あるユーザーは、広告ブロッカー Pi-hole を使っていて、System Preferences > Network > ネットワーク名 > Advanced > DNS で DNS サーバを設定しようとして macOS から下の図のような応答を得た。
けれども、ユーザーとしては、もしも問題に遭遇したならば、試してみる必要のあることはたった 2 つしかない。さきほど述べた通り:
- iCloud プライベートリレーを完全にオフにする。 オン/オフの切り替えは簡単にできるので、必要に応じてスイッチを切り替えても害はない。
- 特定のネットワークで "IP アドレスのトラッキングを制限" をオフにする。 例えば、自宅の Wi-Fi ネットワークに対して iPhone 上でオフにして、セルラーデータ接続についてはオンのままにしておくこともできる。
"IP アドレスのトラッキングを制限" を設定することで特定のネットワークでの iCloud プライベートリレーが無効化されるとは必ずしも思い至らないだろう。Apple は iCloud プライベートリレーのサポート記事で一度だけこのことに触れている:
「IP アドレスのトラッキングを制限」環境設定を使って、特定のネットワークに対してプライベートリレーのオン/オフを個別に切り替えることができます。*
最後の星印には、こんな脚注が付随している:
* 以前のバージョンの iOS、iPadOS、macOS では、この環境設定は「iCloud プライベートリレー」と呼ばれていました。
では、いったいなぜ Apple はそのオプションの名前を変更したのか? ここから何もかもがはっきりしなくなる。私の推測では、それは "IP アドレスのトラッキングを制限" が単に "iCloud プライベートリレー" を無効化するより以上のことをしているからではないかと思う。
IP アドレスのトラッキングを制限
Apple は "IP アドレスのトラッキングを制限" をオフにすればその特定のネットワークについて iCloud プライベートリレーがオフになると述べた。私が思うに、"iCloud プライベートリレー" と "IP アドレスのトラッキングを制限" の両方をオフにすれば、トラフィックはあなたの ISP と行く先のサイトの間で通常通りに流れるようになると考えて間違いないのだろう。
でも残る可能性、つまり "iCloud プライベートリレー" がオフになっていて "IP アドレスのトラッキングを制限" がオンになっていたらどうなるのか? ここで注目すべきはさきほどの細かな文字で書かれた文章だ。iCloud プライベートリレーがオンになっている場合、次の文章が細かな文字で表示される:
Mail と Safari であなたの IP アドレスを既知のトラッカーから隠すことにより IP アドレスのトラッキングを制限します。これをオフにすれば、iCloud プライベートリレーがこのネットワークでもオフに切り替わります。
iCloud プライベートリレーがオフになっている場合、この細かな文字の文章は次のように短くなる:
Mail と Safari であなたの IP アドレスを既知のトラッカーから隠すことにより IP アドレスのトラッキングを制限します。
これが何を意味するかについて、私はまだ Apple の資料の中から説明を見付けられていないが、私の推測では Apple は基本的にトラフィックを 2 つの個別のインターネットリレーに分けて送るという iCloud プライベートリレーのやり方を Mail と Safari の中に埋め込み、これらのアプリから出されたリクエストのみに適用されるようにしたのだろうと思う。私が理解できないのは、その「あなたの IP アドレスを既知のトラッカーから隠す」というのが何を意味するのか、それが一般的な意味で IP アドレスを隠すのとどう違うのかという点だ。そこのところを調べてみよう。
IP アドレスを隠す
Mac 上では、Safari > Preferences > Privacy へ行けば、ここにもまた "IP アドレスを隠す" という設定項目がある。Mail では Mail > Preferences > Privacy に行けばよいが、Protect Mail Activity をオフにしないと "IP アドレスを隠す" オプションを使えるようにならない。(一般的に言って、Protect Mail Activity はできる限りオンにしておくべきだ。)
iOS と iPadOS では、Settings > Safari > IP アドレスを隠す と Settings > Mail > Privacy Protection に同等なオプションがある。ここでも、Mail では Protect Mail Activity をオンにしないと "IP アドレスを隠す" をコントロールできるようにならない。
では、これらの "IP アドレスを隠す" 機能は何をするのか? Safari では、判断が難しい。Mac でも iPhone でも、Learn More リンクをクリックまたはタップすると、単に iCloud プライベートリレーを説明したページが開くのみで、Safari へのリンクに関して何ら手掛かりは与えられない。
けれども Mail ではもう少し手掛かりがある。Learn More リンクをクリックまたはタップすると、Protect Mail Activity が使う2足飛びシステムについてかなりの情報が示されるが、その内容は iCloud プライベートリレーとほとんど同じに聞こえる。さらにもう一歩明確化のための説明として、Protect Mail Activity をオフにした状態で "IP アドレスを隠す" をオンにすれば、引き続き「同じく 2 つの個別のインターネットリレーに分ける手法を使って IP アドレスを隠します」と書いている。
それに加えて、Protect Mail Activity は Mail がダウンロードするすべての遠隔コンテンツを別々のところが運用する 2 つの個別のリレーに分けて送ります。その片方はあなたの IP アドレスを知っているけれども、受け取るべき遠隔 Mail コンテンツを知りません。もう片方は受け取るべき遠隔 Mail コンテンツを知っているけれども、あなたの IP アドレスは知らず、その代わりに生成した識別情報を行く先の相手に提供します。こうすることで、あなたについての情報と、あなたが受け取るべき遠隔 Mail コンテンツの情報との両方を知っている者は誰もいません。送信者があなたの IP アドレスを一意的な識別子として使ってウェブサイト間であなたの活動を結び付けたり、あるいはあなたについてのプロファイルをアプリが構築したりすることはできません。... あなたが Protect Mail Activity をオフにした場合でも、引き続きこの IP アドレスを隠す機能が、同じく 2 つの個別のインターネットリレーに分ける手法を使って IP アドレスを隠します。
私の見るところ、これは隅から隅まで iCloud プライベートリレーに他ならない。
全部をまとめると
これら3つの互いに連動し合う設定項目についてどう考えるべきかについて、私は次のようにすべきだと思っている。
- iCloud プライベートリレー: 最上位レベルに iCloud プライベートリレーの設定がある。これをオンにしておけば、すべてのトラフィックが ingress と egress の 2 つのプロキシに分けられ、最高レベルのプライバシーが得られる。しかしながら、iCloud プライベートリレーが問題を起こすことは十分あり得るので、Apple はユーザーがより低いレベルのプライバシーまで落とすことができるようにした。
- IP アドレスのトラッキングを制限: そこで "IP アドレスのトラッキングを制限" のオプションが登場する。これを使って iCloud プライベートリレーを選択的にオフにすることも、(iCloud プライベートリレーがオフになっている状態で) 選択的にオンにして Safari や Mail で iCloud プライベートリレー風のトラフィック切り分けを実行させることもできる。ただ、この 2 つのアプリはかなり違うので (Safari の方が Mail に比べて遥かに多種多様なサーバに接続できる必要があるので)、Apple は両者を別々に扱っている。
- IP アドレスを隠す: それだからこそ、それぞれのアプリが別々に独自の "IP アドレスを隠す" 設定を持っている。iCloud プライベートリレーをオフにして、"IP アドレスのトラッキングを制限" もオフにし、Safari の "IP アドレスを隠す" 設定もやはりオフにしておくけれども、Mail の "IP アドレスを隠す" オプションだけはオンにしておきたいということもあるかもしれない。反対に Mail の追跡保護をオフにして Safari の方をオンにするということも考えられなくはないが、あまりありそうな状況とも思えない。
私のこの考え方を支持する事実として、Safari で "IP アドレスを隠す" をオフにして、ネットワークで "IP アドレスのトラッキングを制限" をオフにし、それから iCloud プライベートリレーをオンにすると、まず Safari で "IP アドレスを隠す" をオンにするよう促され (左下図)、それからネットワークでオフになっているという警告 (右下図) が出る。
ここでもやはり "IP アドレスのトラッキングを制限" と "IP アドレスを隠す" が "既知のトラッカー" にのみ作用すると Apple が言っているのがどういう意味なのか、私には分からない。Safari の "IP アドレスを隠す" 画面が明確にその違いを示す。iCloud プライベートリレーがオンになっている限り、トラッカーとウェブサイトとの双方を対象とするのか、それともトラッカーのみを対象とするのかを選べるようになっている。iCloud プライベートリレーがオンになっていなければ、トラッカーから IP アドレスを隠す選択肢しか選べない。
Apple がどうやって既知のトラッカーを識別して、IP アドレスを彼らから守るために Safari や Mail のトラフィックを処理しているのか、そこのところを説明する Apple の資料を私はまだ見付けられていない。既知のトラッカーでない遠隔サイトに接続した場合に何が起こるのか? その場合、Apple は IP アドレスを生のままで送信するのか? ネットワークトラフィックを分析する方法を知っている人ならばひょっとするとそこが分かるのかもしれないが、私にはそのようなスキルはない。
けれども現実的には、重要なのは次のことだけだ。もしも問題が起これば、まず初めに iCloud プライベートリレー をオフにしてみること、そして、もしそれで解決しなければ "IP アドレスのトラッキングを制限" をオフにしてみる。それでもまだ解決しなければ、Safari あるいは Mail で "IP アドレスを隠す" をオフにしてみよう。
問題が起こっていないのならば、単純に全部をオンにしておいて、どれだけのことが提供されているのかは知らないが提供される追加のプライバシーを享受しよう。
討論に参加