Thoughtful, detailed coverage of everything Apple for 32 years
前週号 | 日本語版ホーム | 次週号

#1615: Stage Manager が M1 iPad を必要とする理由、IP アドレストラッキング制限での問題点、Citibank が暗号通貨で混乱

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 だ。

Adam Engst  訳: 亀岡孝仁  

とんでもない、Citibank よ、TidBITS は暗号通貨など売っていません

ここ数週間はとても忙しくて他には手も回せないぐらいであったが、殆ど進展は見られないように思えた。私の週のかなりの部分は、何人かの 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 は次の様に進化してきた:

これらの変更全ては 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 年をかけて忠実な支持層を得ることだ。私はそれを良い行いに対する報酬だと思いたい。

討論に参加

Josh Centers  訳: Mark Nagata   

Stage Manager が M1 iPad を要件とする理由を巡って

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 自身でさえ同意している。)

Stage Manager in iPadOS 16

最近のモデルの 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 は:

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 を使えるようにしてくれたらと提案する。私もそのアイデアに強く同感だが、それにはいくつかの理由がある:

もちろん 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 の命令によるものだろう) が、アーカイブされたバージョンは今も読める

shrinkydink

討論に参加

Adam Engst  訳: Mark Nagata   

連動し合う Apple プライバシー設定で起こる接続性の問題を解決する

ウェブサイトをロードする際の問題が、最近になってポツポツと聞こえて来るようになった。細かな点はいろいろと違うけれども、共通して言えるのは問題が macOS 12.4 Monterey で始まったという点だ。問題は Safari だけで起こることもあったけれども、Chrome やその他のブラウザに影響することもある。ページ全体がどうしてもロードしない場合もあるし、ページの一部分だけロードしない場合もある。

私がこれまで見聞きした限りでは、この問題への単純な解決策が一つある。それは、System Preferences > Network を開いて、使用中のネットワークアダプタ一つ一つに対して "IP アドレスのトラッキングを制限" をオフにすることだ。(下の図では Ethernet と Wi-Fi に対するものが示してあるが、両者は驚くほど違っている。)

Limit IP Address Tracking settings for macOS Network preference pane

人によっては iOS 15 や iPadOS 15 でも問題が起こっている。Apple は同じ "IP アドレスのトラッキングを制限" オプションを Settings > Wi-Fi > ネットワーク名 と Settings > Cellular > Cellular Data Options に提供している。

Limit IP Address Tracking in iOS 15

上の iPhone スクリーンショットで細かな文字で書かれたところを読めば、そこに「これをオフにすれば、iCloud プライベートリレーがこのネットワークでもオフに切り替わります」と書いてあるのが分かる。私の iPhone にこのメッセージが表示されるのはこの iPhone で iCloud プライベートリレーを有効にしているからであり、一方それをオフにしてある私の Mac では表示されない。

ここで何が起こっているのかをもっとよく理解できたらいいのにとは思うが、悪意ある当事者によるトラッキングを防ぐための機能をテストするのはこの上なく困難だ。私には悪意はないし、当事者でもないからだ。さらにもっと状況を不透明にしているのが、IP アドレスのトラッキングを制限したり IP アドレスを隠したりと称する機能が完全に別々の 3 つの場所に分かれて存在しているという事実だ:

きっとこうなっているのだろうと私が推測することと、私にはよく分からないところを、以下で説明してみたい。この情報を利用して、プライバシーの向上と接続性の問題点の増加との間の微妙な境界線を皆さんが見極めて下さることを願っている。

iCloud プライベートリレー

ネットワークの不具合が時々起こるようになった場合にまず最初にチェックすべきは、iCloud プライベートリレーだ。この機能は追加のストレージ料金を Apple に払っている iCloud+ 購読者のみが利用できるものだが、すべてのトラフィックを 2 つの個別のインターネットリレーに分けて送る。片方は Apple が運用しているもので、もう片方は AkamaiCloudflareFastly. などメジャーなコンテンツ配信ネットワークが運用している。詳細を説明したホワイトペーパーを 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 から下の図のような応答を得た。

iCloud Private Relay overriding DNS servers

けれども、ユーザーとしては、もしも問題に遭遇したならば、試してみる必要のあることはたった 2 つしかない。さきほど述べた通り:

"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 はできる限りオンにしておくべきだ。)

Hide IP Address setting in macOS Safari and Mail

iOS と iPadOS では、Settings > Safari > IP アドレスを隠す と Settings > Mail > Privacy Protection に同等なオプションがある。ここでも、Mail では Protect Mail Activity をオンにしないと "IP アドレスを隠す" をコントロールできるようにならない。

Hide IP Address setting in iOS Safari and Mail

では、これらの "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つの互いに連動し合う設定項目についてどう考えるべきかについて、私は次のようにすべきだと思っている。

私のこの考え方を支持する事実として、Safari で "IP アドレスを隠す" をオフにして、ネットワークで "IP アドレスのトラッキングを制限" をオフにし、それから iCloud プライベートリレーをオンにすると、まず Safari で "IP アドレスを隠す" をオンにするよう促され (左下図)、それからネットワークでオフになっているという警告 (右下図) が出る。

iCloud Private Relay warning messages

ここでもやはり "IP アドレスのトラッキングを制限" と "IP アドレスを隠す" が "既知のトラッカー" にのみ作用すると Apple が言っているのがどういう意味なのか、私には分からない。Safari の "IP アドレスを隠す" 画面が明確にその違いを示す。iCloud プライベートリレーがオンになっている限り、トラッカーとウェブサイトとの双方を対象とするのか、それともトラッカーのみを対象とするのかを選べるようになっている。iCloud プライベートリレーがオンになっていなければ、トラッカーから IP アドレスを隠す選択肢しか選べない。

Apple がどうやって既知のトラッカーを識別して、IP アドレスを彼らから守るために Safari や Mail のトラフィックを処理しているのか、そこのところを説明する Apple の資料を私はまだ見付けられていない。既知のトラッカーでない遠隔サイトに接続した場合に何が起こるのか? その場合、Apple は IP アドレスを生のままで送信するのか? ネットワークトラフィックを分析する方法を知っている人ならばひょっとするとそこが分かるのかもしれないが、私にはそのようなスキルはない。

けれども現実的には、重要なのは次のことだけだ。もしも問題が起これば、まず初めに iCloud プライベートリレー をオフにしてみること、そして、もしそれで解決しなければ "IP アドレスのトラッキングを制限" をオフにしてみる。それでもまだ解決しなければ、Safari あるいは Mail で "IP アドレスを隠す" をオフにしてみよう。

問題が起こっていないのならば、単純に全部をオンにしておいて、どれだけのことが提供されているのかは知らないが提供される追加のプライバシーを享受しよう。

討論に参加

TidBITS 監視リスト: Mac アプリのアップデート

訳: Mark Nagata   

BusyCal 2022.2.3

BusyCal 2022.2.3

BusyMac が BusyCal 2022.2.3 をリリースして、macOS 13 Ventura のベータ版リリースへの対応を追加した。このカレンダーアプリはまた、スマートフィルタを調整してタイトル、タグ、出席者その他で "does not contain" 条件に対応し、タグフィールドにカラーコードを 16 進数で入力すれば自動的にカラーフラッグに変換されるようにし、List 表示のイベントを 25、50、100 年間リストする出来合いのフィルタへの対応を追加し、複数個のチェックボックスを続けざまにクリックすると同じタスクが 2 回完了したとマークされることがあったバグを修正し、Apple の Contacts から出席者を入力する際に Company とマークされた連絡先が取り込まれなかった問題を解消した。(BusyMac からも Mac App Store からも新規購入 $49.99、無料アップデート、Setapp からも利用可、56 MB、リリースノート、macOS 10.12+)

BusyCal 2022.2.3 の使用体験を話し合おう

Camo Studio 1.7

Camo Studio 1.7

Reincubate が仮想カメラシステム Camo Studio のバージョン 1.7 をリリースした。(これは Camo iOS アプリと統合されている。) この macOS 用アプリは新しいオーバーレイエディタを導入して、カスタマイズしたテキスト、図形、画像、色付きオーバーレイなどをさまざまのテンプレートから、あるいは自分でデザインして作成できるようにする。今回のリリースではまた、前回の起動からウィンドウの位置やサイズを記憶しているようになり、Camo Studio のプレビュー設定を明確化のため "Scale to fit" に変更し、Mac をスリープから目覚めさせた後にビデオが早送りで表示されてしまったバグを修正した。(購読年額 $39.99、無料アップデート、29.1 MB、リリースノート、macOS 10.13+)

Camo Studio 1.7 の使用体験を話し合おう

Evernote 10.39

Evernote 10.39

Evernote が社名と同じ名前の Mac 用情報管理アプリのバージョン 10.39 をリリースして、いくつか改良を加えた。今回のアップデートではノートリストから1個または複数個のノートを別のノートの上へドラッグすればそのドラッグしたノートへのリンクが作成されるようにした。また、エディタ間や、エディタの書式設定バーでのキーボードナビゲーションが楽にできるようにするとともに、アプリの起動時間をさらに短縮した。(Evernote からも Mac App Store からも無料、312 MB、リリースノート、macOS 10.14+)

Evernote 10.39 の使用体験を話し合おう

ExtraBITS

訳: Mark Nagata   

M2 ベース MacBook Pro、注文受付開始

Apple は新しい M2 チップを搭載してアップデートした 13 インチ MacBook Pro を WWDC キーノートで発表したが、入手可能となる日程は明かさなかった。(2022 年 6 月 6 日の記事“Apple、M2 駆動の MacBook Air と更新された 13 インチ MacBook Pro を発表”参照。) 2022 年 6 月 17 日現在で、13 インチ MacBook Pro は Apple のウェブサイトApple Store アプリ、および Apple Authorized Retailer のいずれでも注文できるようになっている。完全に再設計された M2 ベース MacBook Air については Apple は何も新たな情報を述べなかったが、こちらは間違いなく製造上の難問を伴っているのだろうと思われ、依然として 7 月のどこかの時点で発売されることになっている。

M3 MacBook Pro 13-inch

元記事を読む | 討論に参加

Apple、メジャーリーグサッカーと 10 年間の独占ストリーミング契約を結ぶ

Apple が Major League Soccer を Apple TV アプリを通じてストリーミングする 10 年間の独占契約 を結んだ。2023 年から 2032 年までの契約だ。Apple は新しい MLS ストリーミングサービス (価格は未発表) の購読者に全試合をライブ配信し、地域による放送停止はない。一部の試合は Apple TV+ 購読者にも無料で提供される。地域による放送停止がない点は注目すべきで、大多数のスポーツ放送はたとえストリーミングのプラットフォームにおいても、その土地のチームや特定のスポーツネットワークの放送権との衝突を避けるために視聴可能なゲームを制限することがあるからだ。

Apple MLS partnership

元記事を読む | 討論に参加

Clarus the Dogcow が macOS 13 Ventura で復活 - Moof!

Clarus the Dogcow はクラシック Mac OS における重要な存在であって、Page Setup ダイアログに登場するとともに、その後 Apple の Developer Technical Support チームのメンバーによって配られた限定配布のバッジにも登場した。Adam Engst は何十年も前に Apple の Mark Johnson からもらったバッジを今も大切にしている。[訳者注: 2002 年 7 月 1 日の記事“MacHack の 2002 年度ベスト・ハック・コンテスト”参照。]悲しいことに、Mac OS X の登場に伴って Clarus も消え、それ以来 macOS に姿を見せることはなかった。でも、ペンネーム Shadowfacts という人が macOS 13 Ventura ベータ版の Page Setup ダイアログに Clarus がいることに気付いた。これはたいていのアプリで File > Page Setup から開くダイアログだ。それから Shadowfacts はシステムの中をあちこち掘り返して探し、新しい、滑らかな見栄えの Clarus を抽出することができた。いったいなぜ Clarus が Ventura で復活したのかについてはその昔の Tech Note #31 を引用するしかないが、そこにはこう書かれている:

現時点で言っておくべきは、牛犬 (dogcow) たちは人々を洗脳することで悪名高いということであり、牛犬のせいで人はあたかも自分の自由意思でその絵をダイアログに追加したと "考える" ようになってしまう。実際にはこの牛犬がすべてを完全に支配しているというのに。牛犬とそのマインドコントロールの最良の実例がかの "霊能牛犬" Moofo だ。同じ広告のコピーごとに牛犬ボタンが出現したり消え去ったりするのは、このマインドコントロールで説明できる。対象のマインドが弱ければ弱いほど、牛犬がその対象に強い力を発揮するようになる。

さらなる背景情報が欲しければ、Clarus Museum を見て回るとよい。抵抗しても無駄だから。

New Clarus

元記事を読む | 討論に参加