iOS 隱私保護｜Apple 隱私原則と進化の歴史を徹底解説

閲覧数: 4,258+

正體中文 简体中文 English 日本語

本記事は AI による翻訳をもとに作成されています。表現が不自然な箇所がありましたら、ぜひコメントでお知らせください。

記事一覧

---

iOSのプライバシーと利便性の歴史

Appleのプライバシー原則とiOSの歴年にわたるプライバシー保護機能の調整

Theme by slidego

[2023–08–01] iOS 17アップデート

以前の講演での最新iOS 17のプライバシー関連の調整についての補足。

リンクトラッキング保護

SafariはURLのトラッキングパラメータ（例：fbclid、gclidなど）を自動的に削除します。

• 例：https://zhgchg.li/post/1?gclid=124 をクリックすると https://zhgchg.li/post/1 に変わります。

• 現在iOS 17 Developer Beta 4をテスト中で、fbxxx、gcxxxなどは削除されますが、utm_は保持されます。正式版のiOS 17や将来のiOS 18でさらに強化されるかは不明です。

• 最も厳しい状況での効果を知りたい場合は、iOS DuckDuckGo ブラウザをインストールしてテストしてください。

• 詳細なテスト内容については、「 iOS17 Safari の新機能でURL内の fbclid と gclid を削除する 」という大変参考になる記事をご覧ください。

Privacy Manifest .xprivacy & Report

開発者は使用するユーザープライバシーを宣言する必要があり、使用するSDKにはそのSDKのPrivacy Manifestの提供も求められます。

また、サードパーティSDKの署名も追加

XCode 15 は Manifest を通じて Privacy Report を生成し、開発者が App Store でアプリのプライバシー設定を行えるようにします。

Required reason API

Fingerprintingのリスクがある一部のFoundation APIの乱用を防ぐため、Appleは特定のFoundation APIに対して管理を開始しました；使用理由をManifestで宣言する必要があります 。

現在影響が大きいのは、宣言が必要なAPIであるUserDefaultです。

2023年秋から、App Store Connectにアップロードする新しいアプリやアプリアップデートで、理由の申告が必要なAPI（サードパーティSDKを含む）を使用している場合、アプリのプライバシーリストに承認された理由を提供していなければ通知が届きます。2024年春からは、新しいアプリやアプリアップデートをApp Store Connectにアップロードする際に、対応するAPIの使用方法を正確に反映した承認理由をプライバシーリストに記載する必要があります。

現在の承認理由の範囲に含まれていない理由の申告が必要なAPIのユースケースで、そのユースケースがアプリのユーザーに直接利益をもたらすと確信している場合は、お知らせください。

トラッキングドメイン

Tracking 情報を送信する API ドメインは privacy manifest の .xprivacy に宣言し、ユーザーが追跡に同意した後でなければネットワークリクエストを発行できません。そうでない場合、そのドメインへのすべてのネットワークリクエストはシステムによってブロックされます。

XCodeのNetworkツールでTracking Domainがブロックされているか確認できます：

現在の実測では、FacebookやGoogleのトラッキングドメインはすべて検出され、規定に従ってトラッキングドメインに含め、許可を求める必要があります。

• graph.facebook.com : Facebook 関連のデータ統計

• app-measurement.com : Google 関連のデータ分析：GA/Firebase…

したがって、iOS 17以降では、FBやGoogleのデータ統計が大幅に減少する可能性があることに注意してください。許可を求めず、追跡を許可しない場合、データは全く取得できません。過去の追跡許可の実績によると、約7割のユーザーが「許可しない」を選択しています。

• 開発者自身がAPIを使って送信するトラッキング方法も、Appleは同様に管理対象のトラッキングドメインに含める必要があると述べています。

• もしTracking DomainとAPI Domainが同じ場合は、別の独立したTracking Domainを用意する必要があります（例：api.zhgchg.li → tracking.zhgchg.li）。

• 現時点では、Appleが開発者自身のトラッキングをどのように管理しているかは不明で、Xcode 15で自社トラッキングをテストしても検出されていません。

• 公式ツールで行動を検出するのか、審査担当者が手動で確認するのかは不明です。

fingerprinting は引き続き禁止されています。

はじめに

今回はMOPCON 講演に参加できて光栄でしたが、コロナ禍のためオンライン配信となり、多くの新しい友人と出会えなかったのは残念です。今回の講演テーマは「iOSのプライバシーと利便性の過去と現在」で、Appleのプライバシー原則と、それに基づいてこれまでiOSが行ってきた機能の調整について皆さんと共有したいと思います。

iOSのプライバシーと利便性の歴史 \| Pinkoi、採用中！

ここ数年、開発者やiPhoneユーザーにとって以下の機能変更は馴染み深いものとなっているはずです：

• iOS ≥ 13： サードパーティログインをサポートするすべてのアプリは、Sign in with Appleを実装しなければならず、そうでないとAppのリリースができません。

• iOS ≥ 14： クリップボードアクセスの警告表示

• iOS ≥ 14.5： IDFAはユーザーの許可がなければアクセスできず、ほぼIDFAの使用を禁止する形となる

• iOS ≥ 15： Private Relayにより、プロキシを使ってユーザーの元のIPアドレスを隠す

• iOS ≥ 16： クリップボードへのアクセスにはユーザーの許可が必要

• ….まだまだたくさんありますので、記事の最後に皆さんと共有します。

なぜ？

Appleのプライバシー原則を理解していないと、なぜここ数年Appleが開発者や広告主と対立しているのか疑問に思うかもしれません。多くのユーザーが慣れ親しんだ機能が次々と制限されているからです。

「 WWDC 2021 — Apple’s privacy pillars in focus 」と「 Apple privacy white paper — A Day in the Life of Your Data 」の二つの資料を見終わって、まるで目が覚めたようでした。私たちは知らず知らずのうちに多くの個人情報を漏らし、広告主やソーシャルメディアがそれで大いに利益を得ていることに気づきました。私たちの日常生活は、すでに隅々までその影響が及んでいるのです。

参考 Apple privacy white paper をもとに、以下は架空の人物ハリーを例に、プライバシーがどのように漏洩し、どのような危害をもたらす可能性があるかを説明します。

まずはハリーのiPhoneでの使用履歴です。

左側はウェブ閲覧履歴です： 車、iPhone 13、ブランド品に関連するサイトをそれぞれ訪問したことがわかります。

右側はインストール済みのアプリ： 投資、旅行、ソーシャル、ショッピング、そしてベビーカメラ…これらのアプリ

ハリーのオフライン人生

オフラインイベントで記録が残る場所例：レシート、クレジットカードの利用履歴、ドライブレコーダーなど

組み合わせ

あなたはこう思うかもしれません。異なるウェブサイトを閲覧し、異なるアプリを使い（ログインすらしていないのに）、さらにオフラインのイベントに参加して、どうやって一つのサービスがすべてのデータをつなげられるのか？

答えは：技術的手段は存在し、「可能性がある」または「すでに」部分的に発生しています。

上の図のように：

• 未ログイン時、ウェブサイト間ではサードパーティクッキーやIPアドレス＋デバイス情報から算出されるフィンガープリントを使って、異なるサイトで同じ閲覧者を識別できます。

• ログイン時、ウェブサイト間で登録情報（名前、生年月日、電話番号、メールアドレス、身分証番号など）を通じてあなたのデータが連携されることがあります。

• アプリ間では、デバイスUUIDを取得して異なるアプリで同じユーザーを識別したり、URLスキームを使って端末にインストールされている他のアプリを検出したり、ペーストボードを利用してアプリ間でデータをやり取りしたりできます。また、ユーザーがログインした後に登録情報を使ってデータを紐付けることも可能です。

• アプリとウェブサイト間でも、サードパーティクッキー、フィンガープリント、ペーストボードを使ってデータをやり取りできます。

• オンラインとオフラインの活動の連携は、銀行がクレジットカードの利用履歴を収集したり、家計簿アプリ、レシート収集アプリ、ドライブレコーダーアプリなどで行われ、オフラインの活動とオンラインのデータが結びつく可能性があります。

技術的には可能であることが証明されています；では、すべてのウェブサイトやアプリの背後にいる第三者とは一体誰なのでしょうか？

FacebookやGoogleのような大企業は個人広告で多くの収益を得ています。多くのウェブサイトやアプリもFacebookやGoogleのSDKを組み込んでいます。そのため、すべてを把握するのは難しく、見えている部分だけではありません。多くの場合、どの第三者の広告やデータ収集サービスが使われているか分からず、私たちの行動がこっそり記録されています。

私たちはハリーのすべての行動が、同じ第三者によって密かにデータ収集されていると仮定すると、その第三者の目にはハリーの可能なプロフィールは以下のように映るでしょう：

左側は個人情報で、ウェブサイトの登録情報や配達情報などから取得される可能性があります。右側はハリーの行動履歴に基づいて付けられた行動や興味のタグです。

彼にとってのハリーは、ハリー自身よりも自分のことをよく理解しているかもしれません。これらのデータがソーシャルメディアで使われると、ユーザーはさらに没頭してしまいます。広告に使われると、ハリーの過剰な消費を刺激したり、鳥かご効果を生み出したりします（例：新しいズボンを買うように勧められ、ズボンに合う靴を買い、靴に合う靴下を買う…終わりがありません）。

もしこれ以上に怖いことがあると感じたら、さらに怖いものがあります：

あなたの個人情報と経済状況が知られていると…悪用された場合、例えば誘拐や窃盗など、想像もできません。

現在のプライバシー保護方法

• 法律規制（例：SGS-BS10012 個人情報検証、CCPA、GDPR…）

• プライバシーポリシーと匿名化

主に法規による規制に頼っているため、サービスが常に100％遵守することを保証するのは難しく、ネット上には悪意のあるプログラムも多いため、サービスがハッキングされてデータ漏洩が起こらないとも限りません。つまり、「悪意ある技術はどんなに可能でも、法規と企業の良心だけに頼るしかない」のです。

それ以外にも、多くの場合、私たちは「強制的に」プライバシーポリシーを受け入れなければならず、個別のプライバシー許可を選べず、サービス全体を使わないか、すべてのプライバシーポリシーを受け入れて使うかのどちらかです。また、プライバシーポリシーが不透明で、どのようにデータが収集・利用されるか分からず、その背後に第三者が知らないうちにあなたのデータを収集している可能性もあります。

また、Appleは未成年者の個人情報についても言及しており、多くの場合、保護者の同意なしにサービスが情報を収集していることが多いです。

Appleのプライバシー原則

個人情報漏洩の危険性を理解した上で、次にAppleのプライバシーポリシーを見てみましょう。

Apple Privacy White Paperからの抜粋：Appleの理想は完全な遮断ではなくバランスです。例えば、近年多くの人がAD Blockを直接インストールして広告を完全に遮断していますが、これはAppleが望むことではありません。完全に遮断すると、より良いサービスの提供が難しくなるためです。

賈伯スは2010年のAll Things Digital Conferenceで次のように述べました：

私は人々は賢いと信じています。ある人は他の人よりもデータを共有したいと思うことがあります。毎回彼らに尋ねて、うんざりさせて「もう聞かないで」と言われるまで続け、彼らにあなたがどのようにデータを使うかを正確に理解してもらうのです。 — translate by Chun-Hsiu Liu

Appleはプライバシーを基本的人権と考えています

Appleの4つのプライバシー原則：

• Data Minimization：必要なデータのみを取得する

• On-Device Processing：Appleは強力なプロセッサチップを活用し、必要がない限り個人のプライバシーに関わるデータは端末内で処理することを推奨しています。

• User Transparency and Control：ユーザーがどのプライバシー情報を収集されているか、どのように利用されているかを理解できるようにし、個別のプライバシーデータの共有設定をユーザーが管理できるようにします。

• Security：データの保存および通信の安全を確保する

iOS は個人のプライバシー保護を目的とした年次機能調整

個人のプライバシー漏洩の危険性とAppleのプライバシー原則を理解した上で、技術的な手段に戻りましょう。ここでは、iOSがこれまでに個人のプライバシー保護のために行ってきた機能の変更を見ていきます。

サイト間

前にも述べたように

第一の方法はサードパーティクッキーを使って、ウェブサイト間で閲覧者のデータを連携することです：

🈲，iOS 11以降のSafariにはIntelligent Tracking Preventionが実装されています（WebKit）

デフォルトで有効になっており、ブラウザは追跡や広告に使われるサードパーティCookieを自動的に識別してブロックします。また、毎年のiOSバージョンで識別プログラムが強化され、見逃しを防いでいます。

サードパーティクッキーによるクロスサイトユーザー追跡は、Safariでは基本的にもう機能しません。

第二の方法は、IPアドレスとデバイス情報から算出したフィンガープリントで異なるサイト間で同一の閲覧者を識別することです：

🈲，iOS >= 15 Private Relay

特にサードパーティクッキーが禁止された後、この方法を採用するサービスが増えています。Appleもそれを認識しており…幸いにもiOS 15ではIP情報さえも混乱させています！

Private Relay サービスは、ユーザーの元のリクエストをまずランダムにAppleの Ingress Proxy に送信し、そこからAppleが提携するCDNの Egress Proxy にランダムに割り当て、Egress Proxy がターゲットのウェブサイトにリクエストを送ります。

全てのプロセスは暗号化されており、自分のiPhoneのチップだけが解読可能で、自分だけがIPとリクエスト先のウェブサイトを同時に知っています。AppleのIngress ProxyはあなたのIPのみを知り、CDNのEgress ProxyはAppleのIngress ProxyのIPとリクエスト先のウェブサイトのみを知り、ウェブサイトはCDNのEgress ProxyのIPのみを知っています。

アプリの観点から見ると、同じ地域のすべてのデバイスは共通のCDNのEgress Proxy IPを使ってターゲットサイトにリクエストを送ります。そのため、サイト側はもはやIPをFingerprint情報として使用できません。

技術的な詳細は「 WWDC 2021 — Get ready for iCloud Private Relay 」をご参照ください。

補足 Private Relay：

• Apple/CDNプロバイダーは完全なログを保持していないため追跡できません：
  調査したところ、Appleが悪用を防ぐ方法は見つかりませんでした；おそらくFBIが犯罪者のiPhoneロック解除をしないのと同じ考えでしょう；プライバシーはすべての人の基本的人権です。

• デフォルトで有効、特別な接続は不要

• 速度やパフォーマンスに影響しない

• IPは同じ国とタイムゾーン内で保証されます（ユーザーは都市のぼかしを選択可能）、IPの指定はできません

• 一部のトラフィックにのみ有効
  iCloud+ユーザー：Safariのすべてのトラフィック＋アプリ内の安全でないHTTPリクエスト
  一般ユーザー：Safariのウェブサイトに設置されたサードパーティのトラッキングツールにのみ有効

• 公式に CDN Egress IP List が提供されており、ウェブ開発者が識別に利用できます（Egress IPを誤ってブロックしないでください。大規模な影響が出ます）。

• ネットワーク管理者はすべての接続者に対してPrivate Relayを無効化するためにDNSをブロック可能

• iPhoneは特定のネットワーク接続に対してPrivate Relayを無効にできます

• VPNやプロキシに接続すると、Private Relayは無効になります。

• 現在はまだベータ版です（2021/10/24）。有効にすると、一部のサービス（中国地域、中国版TikTok）が接続できない場合や、サービスから頻繁にログアウトされることがあります。

Private Relay 実測画像

• 図1 無効：元のIPアドレス

• 図2 Private Relayを有効にする — 一般的な位置を維持：IPはCDNのIPに変わるが、依然としてTaipeiにある

• 図3 Private Relayを有効化 — 使用国とタイムゾーン（ぼかし拡大）：IPがCDNのIPに変わり、場所は台中になるが、同じタイムゾーンと国のまま

測試專案

AppはURLSessionTaskMetricsを使ってPrivate Relayの接続記録を分析できます。

話がそれましたが、そのためIPアドレスを使ってFingerprintでユーザーを識別する方法も、もう使えなくなりました。

アプリ間

最初の方法は、初期に直接デバイスUUIDにアクセスできたことです：

🈲，iOS 7以降でのデバイスUUIDへのアクセス禁止,

IDentifierForAdvertisers/IDentifierForVendor の代替としての使用

• IDFV： 同じ開発者アカウントのすべてのアプリが同じUUIDを取得可能；KeyChainと組み合わせて現在のユーザーUUID識別にも使われる。

• IDFA： 異なる開発者やアプリ間で同じUUIDを取得できるが、ユーザーはIDFAをリセットまたは無効化できる。

🈲，iOS >= 14.5ではIDentifierForAdvertisersはユーザーの許可を得てから使用する必要があります

iOS 14.5以降、AppleはIDFAの取得制限を強化しました。アプリはユーザーに追跡の許可を求めた上でのみ、IDFAのUUIDを取得できます。許可を得ていない場合や許可されなかった場合は、値を取得できません。

市場調査会社の初期調査データによると、約7割のユーザー（最新のデータでは9割とも言われている）がIDFAの追跡利用を許可していません。だからこそ、IDFAはもう終わったと言われているのです！

測試專案

アプリ間の連携の第二の方法はURLスキームです：

iOSアプリは canOpenURL を使って、ユーザーの端末に特定のアプリがインストールされているかどうかを検出できます。

🈲、iOS >= 9 では、アプリ内で事前に設定が必要で、自動検出はできません。

iOS ≥ 15 で新たに制限が追加され、他のアプリのSchemeは最大50組まで設定可能です。

iOS 15以降にリンクされたアプリは、LSApplicationQueriesSchemesキーで最大50件のエントリに制限されます。

ウェブサイトとアプリの間

前述の通り

第一の方法もCookieを使って連携する方法です：

初期のiOS SafariのCookieはAppのWebViewのCookieと共有でき、これによりウェブサイトとアプリ間のデータ連携が可能でした。

方法としては、App画面の背景に1ピクセルのWebViewコンポーネントをこっそり埋め込み、SafariのCookieを読み取って利用することができます。

🈲，iOS >= 11 では Safari とアプリの WebView 間での Cookie 共有は禁止されています

もし Safari の Cookie（例：直接ウェブサイトの Cookie を使ってログイン）を取得する必要がある場合は、SFSafariViewController コンポーネントを使用できます。ただし、このコンポーネントは必ず許可ダイアログを表示し、カスタマイズできないため、ユーザーが意図せずに Cookie を盗まれることを防ぎます。

第二の方法は、同じウェブサイトや異なるウェブサイトでIPアドレスとデバイス情報から算出したFingerprintを使って同一の閲覧者を識別することです：

前述の通り、iOS 15以降はPrivate Relayによって匿名化されています。

最後の方法であり唯一可能な方法 — Pasteboard ：

クリップボードを使ってクロスプラットフォームの情報を連携することは可能です。Appleはクリップボードのアプリ間利用を禁止できませんが、ユーザーに通知することはできます。

⚠️ iOS 14以降でクリップボードアクセス警告が追加されました

⚠️ 2022/07/22 更新：iOS 16 今後の変更点

iOS ≥ 16 以降、ユーザーが積極的に貼り付け操作を行わない限り、アプリがクリップボードを読み取ると確認ウィンドウが表示され、ユーザーが許可を押すまでアプリはクリップボードの情報を取得できません。

UIPasteBoardのiOS 16におけるプライバシー変更

Pasteboardを使用した Deferred Deep Link（遅延ディープリンク）の実装

ここでiOS 14のクリップボードに関するプライバシー懸念について少し触れておきます。詳しくは以前の記事「iOS 14 クリップボード盗用の恐怖、プライバシーと利便性のジレンマ」をご参照ください

クリップボードの読み取りが情報窃盗を目的としている可能性は否定できませんが、多くの場合、私たちのアプリがより良いユーザー体験を提供するために必要です：

Deferred Deep Link（遅延ディープリンク）を実装する前は、ユーザーをウェブサイトからAppのインストールへ誘導し、インストール後にAppを開くと、デフォルトでホーム画面が表示されます。より良いユーザー体験は、Appを開いた際にウェブ上で閲覧していたページに対応するApp内のページを表示することです。

この機能を実現するには、ウェブサイトとアプリ間でデータを連携する必要があります。前述の他の方法はすでに禁止されているため、現在はクリップボードを情報保存の手段として利用するしかありません（上図参照）。

Firebase Dynamic LinksやBranch.ioの最新版（以前はBranch.ioがIPアドレスのフィンガープリントを使用していた）も、Deferred Deep Linkにクリップボードを利用しています。

実装は以前の記事を参照してください： iOS Deferred Deep Link 遅延ディープリンク実装(Swift)

一般的に、Deferred Deep Linkを実現するためには、初回のアプリ起動時やアプリに戻った瞬間にのみクリップボードの情報を読み取ります。使用中や不適切なタイミングで読み取ることはありません。この点に注意が必要です。

より良い方法は、まず UIPasteboard.general.detectPatterns を使ってクリップボードのデータが必要なものかを検出し、それから読み取ることです。

測試專案

iOS ≥ 15 以降、クリップボードの通知が最適化され、ユーザー自身の貼り付け操作の場合は通知が表示されなくなりました！

広告効果ソリューション

前述のAppleのプライバシー原則が求めるのは、ユーザーとサービスの完全な遮断ではなく、バランスの取れた対応です。

ウェブサイトとウェブサイトの広告効果の統計：

SafariでIntelligent Tracking Preventionをブロックする機能に対して、Private Click Measurement（WebKit）は、個人のプライバシーを保護しつつ広告効果を測定するために使用されます。

具体的な流れは上図の通りで、ユーザーがAサイトの広告をクリックしてBサイトに移動すると、ブラウザにSource ID（同一ユーザーを識別するため）とDestination情報（目的のサイト）が記録されます。ユーザーがBサイトでコンバージョンを完了すると、Trigger ID（どのアクションかを示す）がブラウザに記録されます。

これら二つの情報は統合され、ランダムに24〜48時間後にAとBのウェブサイトに送信され、広告効果が得られます。

すべてはオンデバイスのSafariが処理し、悪意のあるクリックの防止もSafariが保護を提供しています。

アプリとウェブサイトまたはアプリ間の広告効果統計：

SKAdNetwork（Appleへの申請が必要）を使用できます。Private Click Measurementに似た方式であり、ここでは詳述しません。

アップルは独自に閉じこもっているわけではありません。現在バージョン2.0となったSKAdNetworkは、アップルが開発者や広告主のニーズを収集し、個人のプライバシー管理と統合しながらSDK機能を継続的に改善しています。

ここで心から願っています。Deferred Deep LinkがSDKで連携できるように、私たちはユーザー体験の向上を目的としており、個人のプライバシーを侵害する意図はありません。

技術的な詳細は「WWDC 2021 — Meet privacy-preserving ad attribution」をご参照ください。

クロスプラットフォーム

iOS ≥ 13 すべてのサードパーティログイン対応アプリは、Sign in with Apple を実装しなければならず、そうしないとAppの審査に通りません

• 名前は自由に編集可能です

• 実際のメールアドレスを隠す（Apple製の仮想メールアドレスを使用）

• ユーザーはアカウント削除を要求できます 2022/01/31 までにアプリで実装完了が必要 🆕

iOS 15以降のiCloud+ユーザーはHide My Emailに対応

• Safari、Appのすべてのメールフィールドをサポート

• ユーザーは設定から自由に仮想メールボックスを作成できます。

同じく「Sign in with Apple」では、Appleが生成した仮想メールアドレスを実際のメールアドレスの代わりに使用します。メールを受信すると、Appleがあなたの実際のメールアドレスに転送することで、メールアドレス情報を保護します。

10分間メールボックスに似ていますが、さらに強力です。使い続ける限り、その仮想メールアドレスは永久に保持されます。追加の上限もなく、無制限に新しいアドレスを作成可能です。Appleがどのように悪用を防いでいるかは不明です。

設定 -> Apple ID -> メールを非表示

その他

App Storeのアプリプライバシー詳細：

App は App Store で、どのユーザーデータが追跡されるかおよびその利用方法を説明する必要があります _。*

詳細については、「App privacy details on the App Store」をご参照ください。

個人プライバシーデータの細かな制御：

iOS 14以降、位置情報や写真へのアクセスをより細かく制御でき、特定の写真だけを許可したり、アプリ使用中のみ位置情報へのアクセスを許可したりできます。

測試專案

iOS 15以降では、CLLocationButton ボタンが追加され、ユーザー体験が向上しました。ユーザーの許可がなくても、ユーザーがボタンをタップすることで現在位置を取得できます。このボタンはカスタマイズ不可で、ユーザー操作でのみ起動します。

個人情報アクセスの通知：

iOS ≥ 15、個人のプライバシー機能使用時に許可を求める通知が追加されました。例：クリップボード、位置情報、カメラ、マイク

Appのプライバシーアクセスレポート：

iOS ≥ 15では、過去7日間におけるすべてのアプリのプライバシー機能の使用状況やネットワーク活動の記録レポートをエクスポート可能です。

1. 記録レポートファイルは .ndjson のテキストファイルで直接見るのが難しいため、まずはApp Storeから「隱私洞見」アプリをダウンロードしてレポートを確認してください。

2. 設定 -> プライバシー -> 一番下の「Appのアクティビティを記録」-> Appのアクティビティを記録を有効にする

3. Appのアクティビティを保存する

4. 「プライバシーインサイト にインポート」を選択してください

5. インポート完了後にプライバシーレポートを確認できます

同じくニュースで述べられているように、Wechatは確かにアプリ起動時にバックグラウンドで写真情報をこっそり読み取っています。

また、中国のいくつかのアプリが不正行為をしているのを発見したため、設定でそれらの権限をすべて無効にしました。

この機能がなければ、彼らはすぐにバレてしまい、私たちのデータがどれだけ長く盗まれていたか分からなかったでしょう！

まとめ

Appleのプライバシー原則

歴年のプライバシー機能の調整を理解した上で、改めてAppleのプライバシー原則を見てみましょう：

• Data Minimization：Appleは技術的手法で必要なデータの取得を制限しています

• On-Device Processing：プライバシーデータをクラウドにアップロードせず、すべてローカルで処理します。例えば、SafariのPrivate Click Measurementや、Appleの機械学習SDK CoreMLもローカルで実行されます。iOS 15以降のSiriやカメラのライブテキスト機能、Apple Map、News、写真認識機能なども含まれます。

• ユーザーの透明性とコントロール：新たに追加された各種プライバシーアクセスの通知、記録レポートおよび細かなプライバシー制御機能

• Security：データの保存と転送の安全性、UserDefaultの乱用禁止、iOS 15ではCryptoKitを使ってエンドツーエンドの暗号化が可能、Private Relayによる通信の安全保障

破損したデータ

最初に技術的手段でハリーの関連図を作成したように、ウェブサイト間やアプリ間の連携は遮断され、クリップボードだけが使える状態ですが、使用時には通知が表示されます。

サービス登録やサードパーティログインの個人情報は、Sign in with AppleやHide My Email機能を使って防止することができます。または、iOSネイティブアプリを多く利用する方法もあります。

オフラインイベントはApple Cardのプライバシー漏洩防止に役立つかもしれませんか？

もう誰もハリーの行動の輪郭をつなぎ合わせることはできない。

Appleは人間中心

したがって、「人を中心に据えること」は私がAppleに与える理念の代名詞であり、商業市場と逆行するには大きな信念が必要です。それに関連する「技術を中心に据えること」は私がGoogleに与える代名詞であり、Googleは常に多くのギークな技術プロジェクトを生み出しています。最後に「商業を中心に据えること」は私がFacebookに与える代名詞であり、Facebookは多くの面で商業的利益のみを追求しています。

プライバシー機能の調整に加えて、ここ数年のiOSはスマホ依存防止機能も強化しており、「スクリーンタイムレポート」「App使用時間制限」「集中モード」などの機能を導入し、スマホ中毒からの解放を支援しています。

最後に皆さんができることを願っています

• 個人のプライバシーを重視する

• 資本に支配されない

• 仮想依存症の軽減

• 社会の堕落を防ぐ

現実の世界で素晴らしい人生を送りましょう！

Private Relay/IDFA/Pasteboard/Location テストプロジェクト：

参考資料

• WWDC 2021 — Appleのプライバシーの柱に焦点を当てて

• Apple privacy white paper — A Day in the Life of Your Data

• WWDC 2021 — iCloudプライベートリレーの準備をしましょう

• WWDC 2021 — プライバシーを保護する広告アトリビューションの紹介

• iOS 14 クリップボード情報漏洩の恐怖、プライバシーと利便性のジレンマ

• iOS Deferred Deep Link 遅延ディープリンク実装(Swift)

• iOS UUID のあれこれ (Swift/iOS ≥ 6)

ご質問やご意見がありましたら、こちらからご連絡ください 。

Post MediumからZMediumToMarkdownを使って変換しました。

---

🍺 Buy me a beer on PayPal

👉👉👉 Follow Me On Medium! (1,053+ Followers) 👈👈👈

本記事は Medium にて初公開されました（こちらからオリジナル版を確認）。ZMediumToMarkdown による自動変換・同期技術を使用しています。

Improve this page on Github.