iOSのプライバシーと利便性の歩み
Appleのプライバシー原則とiOSにおけるこれまでのプライバシー保護機能の調整

テーマ提供: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で宣言する必要があります。
現在、影響が大きいのは UserDefault、つまり宣言が必要なAPIです。
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…
したがって、FB/Googleのデータ統計はiOS 17以降で大幅に減少する可能性があります。権限を求めず、追跡を許可しない場合、データはまったく取得できません。これまでの追跡許可の実績によると、約7割のユーザーが「許可しない」を選択しています。
-
開発者自身がAPIを使って送信するトラッキング方法についても、Appleは同様にTracking Domainの管理が必要であると述べています。
-
もし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 を必ず実装しなければならず、そうでなければアプリの公開ができません。
-
iOS ≥ 14: クリップボードアクセスの警告表示
-
iOS ≥ 14.5: IDFAは許可がなければアクセスできず、実質的にIDFAの使用が禁止される形となる
-
iOS ≥ 15: Private Relayにより、プロキシを使ってユーザーの元のIPアドレスを隠す
-
iOS ≥ 16: クリップボードへのアクセスはユーザーの許可が必要
-
….まだまだ多くありますので、記事の最後で皆さんに共有します。
なぜ?
もしAppleのプライバシー原則を理解していなければ、なぜAppleがここ数年、開発者や広告主と対立しているのか疑問に思うかもしれません。多くのユーザーが慣れている機能が次々と制限されているからです。
「WWDC 2021 — Appleのプライバシーの柱に焦点を当てる」と「Appleプライバシーホワイトペーパー — あなたのデータの一日」の2つの資料を追いかけてみて、目が覚めたように気づきました。私たちは知らず知らずのうちに多くの個人情報を漏らし、広告主やソーシャルメディアが大いに儲けていることを。私たちの日常生活はすでに隅々まで浸透しているのです。
参考 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の4つのプライバシー原則:
-
データ最小化:必要なデータのみを収集する
-
デバイス内処理:Appleは高性能なプロセッサチップを活用し、必要な場合を除き個人のプライバシーに関わるデータをローカルで処理することを推奨しています
-
ユーザーの透明性と制御:ユーザーがどのプライバシー情報が収集され、どのように利用されているか理解できるようにし、個別のプライバシーデータの共有をユーザーがオン・オフできるようにします
-
セキュリティ:データの保存および送信の安全性を確保する
iOS における個人情報保護のための年次機能調整
個人情報漏洩の危険性とAppleのプライバシーポリシーを理解した上で、技術的な手段に戻りましょう。ここ数年のiOSにおける個人情報保護のための機能変更を見てみます。
ウェブサイト間
前にも述べたように
第一の方法は、Third-Party Cookieを使ってウェブサイト間で閲覧者のデータをつなげることです:
🈲、iOS 11以降のSafariにはインテリジェントトラッキング防止機能が実装されています(WebKit)。
デフォルトで有効になっており、ブラウザは追跡や広告に使用されるサードパーティのCookieを自動的に識別してブロックします。また、毎年のiOSアップデートで識別プログラムが強化され、見逃しを防いでいます。

Third-Party Cookie を使ったクロスサイトユーザー追跡は、Safari では基本的にもう機能しません。
第二の方法は、IPアドレス+デバイス情報から算出したフィンガープリントを使い、異なるサイト間で同じ閲覧者を識別することです:
🈲,iOS >= 15 プライベートリレー
特にサードパーティクッキーが禁止された後、この方法を採用するサービスが増えていますが、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が悪用を防ぐ方法は見つかりませんでした;おそらくAppleがFBIのために犯罪者のiPhoneを解除しないのと同じ考え方でしょう;プライバシーはすべての人の基本的人権です。 -
デフォルトで有効、特別な接続は不要
-
速度やパフォーマンスに影響しない
-
IPは同じ国とタイムゾーンを保証します(ユーザーは都市をぼかすことができます)、IPの指定はできません
-
一部のトラフィックにのみ有効
iCloud+ ユーザー:Safari上のすべてのトラフィック + アプリ内の安全でないHTTPリクエスト
一般ユーザー:Safari上のウェブサイトに設置されたサードパーティのトラッキングツールにのみ有効 -
公式に CDN Egress IP List が提供されており、ウェブ開発者が識別するために利用できます(Egress IPを誤ってブロックしないでください。大規模な影響が出る可能性があります)
-
iPhoneは特定のネットワーク接続に対してPrivate Relayを無効にできます
-
VPNやプロキシに接続するとPrivate Relayは無効になります
-
現在はまだベータ版です(2021/10/24)。有効にすると、一部のサービス(中国地域、中国版TikTok)に接続できなかったり、サービスから頻繁にログアウトされることがあります。

Private Relay 実測画像
-
図1 無効:元のIPアドレス
-
図2 Private Relayを有効化 — 一般的な位置を維持:IPはCDNのIPに変わるが、依然として台北にある
-
図3 Private Relayを有効化 — 使用国とタイムゾーン(ぼかしを拡大):IPがCDNのIPに変わり、場所は台中になるが、同じタイムゾーンと国のまま

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

話が逸れましたが、そのためIPアドレスを使ってFingerprintでユーザーを識別する方法も、もう使えなくなりました。
アプリ間
第一の方法は、初期に直接デバイスのUUIDにアクセスできたことです:
🈲,iOS >= 7 ではデバイスのUUIDへのアクセスは禁止されています,
IDentifierForAdvertisers/IDentifierForVendor の代わりに使用

-
IDFV: 同じ開発者アカウントのすべてのアプリが同じUUIDを取得できる;KeyChainと組み合わせて現在のユーザーUUIDの識別方法でもある。
-
IDFA: 異なる開発者や異なるApp間で同じUUIDを取得できますが、IDFAはユーザーがリセットまたは無効化できます。
🈲,iOS >= 14.5 ではIDentifierForAdvertisersの使用は許可を得てから行う必要があります

iOS 14.5以降、AppleはIDFAの取得制限を強化しました。アプリはユーザーに追跡の許可を求めてからでないとIDFAのUUIDを取得できません。許可を得ていない場合や許可されていない場合は、IDFAの値を取得できません。
市場調査会社の初期調査データによると、約7割のユーザー(最新データでは9割と言われている)がIDFAの追跡利用を許可していません。だからこそ、IDFAはもう終わったと言われているのです!

App間の連携のもう一つの方法はURL Schemeです:
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によって匿名化されています。
最後の方法であり唯一可能な方法 — ペーストボード:
クリップボードを使ってプラットフォームをまたいだ情報連携を行うことは可能ですが、Appleはクリップボードのアプリ間利用を禁止できないため、ユーザーに通知を表示します。
⚠️ iOS >= 14 クリップボードアクセス警告の追加

⚠️ 2022/07/22 更新:iOS 16 の今後の変更点
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(どのアクションかを示す)もブラウザに記録されます。

これらの2つの情報は統合され、ランダムに24〜48時間後にAとBのウェブサイトに送信されて広告効果が得られます。
すべてはオンデバイスのSafariが処理し、悪意のあるクリックの防止もSafariが保護を提供しています。
アプリとウェブサイトまたはアプリ間の広告効果測定:

SKAdNetwork(Appleへの申請が必要)を使用できます。Private Click Measurementと同様の方法で、詳細は省略します。
Appleは閉鎖的に開発しているわけではありません。現在SKAdNetworkはバージョン2.0に達しており、Appleは開発者や広告主のニーズを収集しつつ、個人のプライバシー管理を統合し、SDK機能の継続的な改善を行っています。
ここで心から願っています。Deferred Deep LinkがSDKで連携できるように、私たちはユーザー体験の向上を目的としており、個人のプライバシーを侵害する意図はありません。
技術的な詳細は「 WWDC 2021 — Meet privacy-preserving ad attribution 」をご参照ください。
クロスプラットフォーム

iOS 13以降のすべてのサードパーティログイン対応アプリは、必ずSign in with Appleを実装しなければならず、そうでなければアプリのリリースができません
-
名前は自由に編集できます
-
実際のメールアドレスを隠せる(Appleが生成した仮想メールアドレスを代わりに使用)
-
ユーザーはアカウント削除を要求できます 2022/01/31 までにアプリ実装が必要 🆕

iOS 15以降のiCloud+ユーザーはHide My Emailに対応しています
-
Safariやアプリのすべてのメールアドレス欄をサポート
-
ユーザーは設定で自由に仮想メールアドレスを作成できます。
Sign in with Appleと同様に、Appleが生成した仮想メールアドレスを実際のメールアドレスの代わりに使用します。メールを受け取ると、Appleがあなたの実際のメールアドレスに転送し、メールアドレス情報を保護します。
10分間メールボックスのようですが、さらに強力です。使い続ける限り、その仮想メールアドレスは永久に保持されます。追加の上限もなく、無制限に作成可能です。Appleがどのように悪用を防いでいるかは不明です。



設定 -> Apple ID -> メールを非表示
その他
App Storeでのアプリのプライバシー詳細:

詳細については、こちらをご参照ください:「 App privacy details on the App Store 」。
個人プライバシーデータの細かな制御:

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

iOS 15以降では、CLLocationButton ボタンが追加され、ユーザー体験が向上しました。ユーザーの許可がなくても、ユーザーがボタンをタップすることで現在地を取得できます。このボタンはカスタマイズ不可で、ユーザーの操作によってのみ起動します。
個人情報のアクセス通知:

iOS 15以上、個人のプライバシー機能使用時に通知を追加(例:クリップボード、位置情報、カメラ、マイク)
Appのプライバシー使用レポート:
iOS 15以降、過去7日間におけるすべてのアプリのプライバシー機能の使用状況やネットワーク活動の記録レポートをエクスポート可能です。
-
記録レポートファイルは
.ndjsonのテキストファイルであるため、直接見るのは難しいです。まずはApp Storeから「隠私洞見」アプリをダウンロードしてレポートを確認してください。 -
設定 -> プライバシー -> 一番下の「Appのアクティビティを記録」-> 「Appのアクティビティを記録」を有効にする
-
Appのアクティビティを保存する
-
「プライバシーインサイト にインポートを選択」
-
インポートが完了すると、プライバシーレポートを確認できます



同じくニュースで述べられているように、Wechatは確かにアプリ起動時にバックグラウンドで写真情報をこっそり読み取っています。
さらに、中国のいくつかのアプリが不正行為をしているのを見つけたため、設定でそれらの権限をすべて無効にしました。
この機能がなければ、彼らが明るみに出て、私たちのデータがどれだけ長く盗まれていたか分からなかったでしょう!
まとめ
Appleのプライバシー原則

歴年のプライバシー機能の調整を理解した上で、改めてAppleのプライバシー原則を見てみましょう:
-
データ最小化:Appleは技術的手段で必要なデータの取得を制限しています
-
オンデバイス処理:プライバシー情報はクラウドにアップロードせず、すべてローカルで処理されます。例えば、SafariのPrivate Click MeasurementやAppleの機械学習SDK CoreMLもローカルで実行されます。iOS 15以降のSiriやカメラのライブテキスト機能、Apple Maps、News、写真認識機能なども同様です。
-
ユーザーの透明性とコントロール:新たに追加された各種プライバシーアクセス通知、記録レポートおよび細かなプライバシー制御機能
-
セキュリティ:データの保存と伝送の安全性、UserDefaultの乱用防止、iOS 15ではCryptoKitを使ってエンドツーエンドの暗号化が可能、Private Relayによる伝送の安全性
断片化データ

最初に技術的手段でハリーの関連図を作成したとき、ウェブサイト間やアプリ間のつながりは遮断され、クリップボードだけが使えますが、通知が表示されます。
サービス登録やサードパーティログインの個人情報は、Sign in with AppleやHide My Email機能を使って防止できます。または、iOSネイティブアプリを多く利用する方法もあります。
オフラインイベントはApple Cardのプライバシー漏洩防止に役立つかもしれませんか?
もう誰もハリーの行動の輪郭をつなぎ合わせることはできない。
Appleは人間中心

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

プライバシー機能の調整に加えて、ここ数年のiOSはスマホ依存防止機能も強化し、「スクリーンタイムレポート」「App使用時間制限」「集中モード」などの機能を導入し、スマホ中毒からの解放を支援しています。
最後に皆さんができることを願っています
-
個人のプライバシーを重視
-
資本に支配されない
-
デジタル依存の軽減
-
社会の堕落防止
現実世界で素晴らしい人生を生きる!
Private Relay/IDFA/Pasteboard/Location テストプロジェクト:
参考資料
Post MediumからZMediumToMarkdownによって変換されました。



コメント