GrapheneOS：ユーザガイド（専門家向け）

システムナビゲーション

デフォルトでは、GrapheneOS はジェスチャーベースのナビゲーションを使用する。ジェスチャー・ナビゲーションに関するガイドを読み、気に入らないと思われる場合でも、一度試してみることをお勧めする。我々の経験では、適切な知識を得た場合には、大多数のユーザーは新たなジェスチャーナビゲーションアプローチを好んでいる。

システムナビゲーションモードは、設定 ➔ システム ➔ ジェスチャー ➔ システムナビゲーションで設定できる。同じメニューは、設定 ➔ ユーザ補助 ➔ システム操作 ➔ システムナビゲーションでも利用できる。

ジェスチャーナビゲーション

画面下部は、システムナビゲーションのための予約タッチゾーンになる。中央に線が表示され、画面下部全体にナビゲーションバーがあることを示す。ほとんどのアプリでは、この領域にパディングが表示される。

最近のアプリは、パディングがなくてもアプリのコンテンツを表示できることをOSに伝えることができるが、その一方で、アプリからのタッチを受け取ることはできない。例えば、「設定」アプリを開いてみよう。

ナビゲーションバーから上にスワイプして指を離すジェスチャーは、「ホーム」ジェスチャーである。

画面に指を置いたままナビゲーションバーを上にスワイプしてから離すと、「最近使ったアプリ」のジェスチャーになる。最近開いたアクティビティは常に一番右に表示される。左に1ステップ進むごとに、最近開いたアプリの履歴が1ステップ戻る。最近使ったアプリのアクティビティでアプリを開くと、新たなアプリを開いたときと同じように、最近使ったアプリの並び順で一番右に表示される。

「最近のアプリ」アクティビティには、スクリーンショットボタンがある。これは、アプリを使用中に電源と音量ダウンボタンを下げる動作の代わりになる。

訳注：たいていの機種では、スクリーンショット撮影のためのボタンとして、電源ボタンと音量ダウンボタンの同時押しという動作が割り当てられているが、これは少々操作しづらい。

「最近のアプリ」アクティビティを開く代わりに、ナビゲーションバーを左にスワイプして「前のアプリ」を、右にスワイプして「次のアプリ」を開くことができる。この場合、最近のアプリの順番は変わらない。これは通常、最近のアプリをナビゲートする最良の方法だ。

（ナビゲーションバーではなく）アプリ内で画面の左または右からスワイプすると、「戻る」ジェスチャーになる。アプリは競合するジェスチャの実装を避けることになっているが、本当にこのジェスチャを取り除く必要がある場合は、このジェスチャを上書きするオプションがある。Google Androidでは数年前からジェスチャーがデフォルトになっているにもかかわらず、UIを積極的に開発していない一部のレガシーアプリは、いまだにこの問題に対処していない。戻るジェスチャーのトリガーを回避するには、次の2つの簡単な方法がある。端の近くからスワイプしないようにするか、スワイプする前に画面の横に指をしばらく置いておく。より高度なオプションは、画面の下部を鋭く指す斜めのスワイプを使用することだ。これにより戻るジェスチャーは回避されるが、ほとんどのアプリのジェスチャーはトリガーされる。上級者向けのオプションは、慣れると最も便利な方法である。

ランチャーは、ホーム画面からアプリドロワーを開くために、画面上のどこからでもスワイプアップジェスチャーを使用する。ナビゲーションバーから始まるジェスチャーは、OSによってシステムナビゲーションジェスチャーとして処理されるため、システムナビゲーションバーより上でジェスチャーを開始する必要がある。

3ボタンナビゲーション

3ボタンナビゲーションは、Androidで最も古いタッチスクリーンベースのナビゲーションシステムである。ジェスチャーを簡単に使えないユーザーにアクセシビリティを提供するため、当面はサポートされ続ける。これは、2ボタンナビゲーションより古いが、レガシー機能とは考えられていない。

画面下部の大きな列はナビゲーションボタン用に確保されている。「戻る」ボタンは左側、「ホーム」ボタンは中央、「最近のアプリ」ボタンは右側にある。

「最近のアプリ」アクティビティでは、最近開いたアクティビティが常に一番右に表示される。左に進むごとに、最近開いたアプリの履歴が1ステップ戻る。最近のアプリのアクティビティでアプリを開くと、新しいアプリを開いたときと同じように、最近のアプリの並び順で一番右に表示される。

「最近のアプリ」アクティビティにはスクリーンショットボタンがあり、電源と音量を押しながらアプリを使用する代わりに使用できる。

ストレージアクセス

訳注：任意のアプリがスマフォ内の任意のファイルを読み書きできてしまうと困ったことになる。悪意のあるアプリが、銀行アプリの作ったファイルを読んでしまうなど。その一方で、アプリにファイルの読み書きを禁止してしまうと、何のデータも保存できなくなってしまう。このために、もともとのAndroidでも、アプリによる「ストレージアクセス」は制限付きで許可される。

GrapheneOSは、ストレージアクセスに対しての最新のAndroidと同じ基本アプローチを継承しつつも、ストレージスコープ機能でそれを拡張している。これは、標準的なAndroidストレージパーミッションの完全な代替機能とである。このセクションでは、主には、ストレージスコープ以前の前提として、（Androidのもともとの）ストレージアクセスの標準的アプローチの概要を説明する。

訳注：まず、もともとのAndroidのストレージアクセス機能について説明し、次にGrapheneOS独自のストレージスコープについて説明する

アプリがアクセス可能なストレージには2つのタイプがある：

アプリ・プライベート（「内部」）ストレージ：
- 他のアプリからはアクセスできない
- アクセスに何の許可も必要ない
- アプリがアンインストールされると消去される
共有（”外部”）ストレージ：
- 他のアプリと共有される
- アクセスはパーミッションで制御される
- ファイルはアンインストール後も保持される
  Android/data/およびAndroid/obb/ディレクトリは、共有ストレージの一部とはみなされない。

訳注：明らかにアプリのプライベート（内部）ストレージへのアクセスは問題無く、共有（外部）ストレージへのアクセスが問題になる。これについて、もともとのAndroidには様々なルールがあり、そのルールも都合に合わせて変更されてきたため、少々複雑になっている。

最近のアプリでは、共有ストレージへのアクセスは次のように制御される：

ストレージのパーミッションがない場合、アプリには以下が許可される：
- 標準ディレクトリにメディアファイルを作成する（オーディオはMusic/、Ringtones/などに、画像はPictures/とDCIM/に、ビデオはDCIM/とMovies/に）。
- Documents/とDownload/にあらゆるタイプのファイル（メディアと非メディアの両方）を作成する。
- 標準ディレクトリ内に新しいディレクトリを作成
- アプリ自身が作成したファイルのリネーム/削除
- ディレクトリ内のすべてのファイルの名前変更/削除が可能な場合、ディレクトリの名前変更/削除が可能
メディアアクセスパーミッション（「メディアのみへのアクセスを許可」、READ_EXTERNAL_STORAGE）は、アプリが他のアプリによって作成されたメディアファイルを読み取ることを許可する。メディア以外のファイルは不可視のままである。Android 13をターゲットとするアプリでは、メディアアクセス許可はREAD_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIOに分割される。
メディア管理特別アクセス許可（”Allow app to manage media”、MANAGE_MEDIA）は、アプリが他のアプリによって作成されたメディアファイルを削除したり、名前を変更したりすることを許可する。
“すべてのファイルへのアクセス “特別アクセス権限（MANAGE_EXTERNAL_STORAGE）により、アプリは共有ストレージの任意のディレクトリ（ルートディレクトリを含む）内の任意のタイプのファイルとディレクトリの読み取り、作成、名前の変更、削除が可能になる。

レガシーアプリ（Android 9以下をターゲットとするアプリ、Android 10をターゲットとし、レガシーステージモードを要求するアプリ）では、ストレージアクセスパーミッションの意味が異なる。

ストレージパーミッションがないと、アプリは共有ストレージ内のファイルやディレクトリにアクセスすることができない。
READ_EXTERNAL_STORAGEパーミッションは、アプリが任意のディレクトリ内のメディアファイルと非メディアファイルの両方を読み取ることを許可する。
WRITE_EXTERNAL_STORAGE権限により、アプリは共有ストレージの任意のディレクトリ（ルートディレクトリを含む）内のファイル（種類を問わない）やディレクトリを作成、名前変更、削除できる。

さらに、最新のAndroidアプリもレガシーなAndroidアプリも、システムファイルピッカーインターフェースを開いて、ユーザーに代わって1つ以上のファイル/ディレクトリを保存またはロードさせることができる。このタイプのアクセスには、上記のパーミッションは必要ない。このアプローチを使用することで、ユーザーは自分のホームディレクトリのどこにファイルが保存されているか、どのファイル/ディレクトリをアプリが使用できるかを制御できるようになる。これは、Android 4.4で導入されたストレージアクセスフレームワーク（SAF）に基づく。SAFは、ホームディレクトリ内のファイル/ディレクトリ、外付けドライブ、さらにネットワーク共有、クラウドストレージ、暗号化ボリューム、OSが外付けドライブをサポートしていないファイルシステムを持つ外付けドライブなど、アプリベースのストレージプロバイダへのアクセスをユーザーに許可することができる。これは、これらのアプリベースのストレージプロバイダを使用する唯一の方法であり、最新のAndroidは、外部ドライブにアクセスするためのレガシーアプローチを削除した。

ストレージスコープ

GrapheneOSは、Androidの標準的ストレージパーミッションの完全な代替機能として、ストレージスコープ機能を提供する。ストレージスコープは、アプリがストレージパーミッションを持っていない場合にのみ有効にできる。ストレージスコープを有効にすると、アプリはその要求するすべてのストレージパーミッションを持つものとみなされる。

これは、アプリが他アプリによって作成されたファイルを見れないことを意味する。このアプリは、ストレージへのアクセス権限を持っていない他の最新のアプリと同じように、ファイルやディレクトリを作成することはできる。

ストレージスコープが有効になると、通常はレガシーストレージモードを使用するアプリは、モダンストレージモードに切り替わる。

アプリが “All files access “パーミッションを要求する場合（またはWRITE_EXTERNAL_STORAGEパーミッションを要求するレガシーアプリの場合）、ストレージアクセスパーミッションを持たないアプリに通常適用される書き込み制限が緩和され、アプリに “All files access “パーミッションが付与された場合と同じ書き込みアクセスが提供される。これは、たとえば共有ストレージのルートに新しいディレクトリを作成したり、Music/ディレクトリにテキストファイル（lyrics.txtなど）を書き込んだりするアプリとの互換性を確保するためである（通常は、オーディオファイルのみ置くことができる）。このようなアプリには、追加の読み取りアクセス権は付与されない。

その他のアプリについては、ストレージスコープを有効にしても、ストレージパーミッションを持たない最新のアプリがすでに持っている以上の追加のストレージアクセス権は付与されない。

オプションとして、ユーザはアプリがアクセスできる他のアプリによって作成されたファイルを指定することができる。特定のファイル、またはディレクトリ内のすべてのファイルへのアクセスを許可することができる。標準のSAFピッカーは、共有ストレージファイル/ディレクトリのみを表示する特別なモードでこの目的に使用される。

ストレージスコープの最も重要な制限は、アプリがアンインストールされ、再度インストールされた場合、そのアプリが作成したファイルへのアクセスが失われるという事実である。回避策として、ユーザーはSAFピッカー経由でこれらのファイル/ディレクトリへのアクセスを手動で許可することができる。

アクセシビリティ

訳注：アクセシビリティとは色覚・聴覚・視覚障害者がスマフォを使えるようにすること。

GrapheneOSは、Android Open Source Projectのアクセシビリティ機能をすべて含み、Googleアプリやサービスを含まないことによるギャップを埋めるように努めている。オープンソースのTalkBackアクセシビリティサービスを独自にフォークし、標準の色調補正メニューにMonochromacyオプションを追加している。

GrapheneOSは、利用可能なオプションの制限のため、基本OSにテキスト読み上げ（TTS）サービスをまだ含んでいない。将来、適切なオプションが利用可能になったときに、これを含める予定だ。RHVoiceとeSpeak NGはどちらもオープンソースであり、GrapheneOSユーザーが最もよく選択するものである。eSpeak NGは、我々の要求に基づいてDirect Bootを追加しており、最初のアンロック前に機能することができる。RHVoiceにはDirect Bootがなく、最初のアンロック前に実行することができない。このどちらか、または別のTTSアプリをインストールしてセットアップすれば、TalkBackが動作するようになる。TalkBack自体はDirect Bootに対応しており、最初のロック解除前に動作するが、最初のロック解除前に起動音を再生する以上のことを行うには、TTSアプリが対応している必要がある。TTSサービスをインストールした後、OSのコンフィギュレーションでそれを選択し、アクティベーションを許可する必要がある。OSはそのうちの1つを選択済みと表示するが、安全ではないため、インストールしただけでは動作しない。これは純正OSと同じだが、すでに1つ設定されている。

GrapheneOSはデフォルトでパスワードの入力時に文字を表示しないようになっている。設定➤プライバシーで有効にできる。

サードパーティのアクセシビリティサービスをインストールして有効にすることもできる。これにはGoogle製のものも含まれる。ほとんどのアクセシビリティサービスは動作するが、一部のアクセシビリティサービスはGoogle Playサービスの機能に依存する場合がある。アクセシビリティ・サービスは非常に強力なものであるため、サードパーティ製の実装を使わなくても十分やっていけるのであれば、使わないことを強くお勧めする。我々は、問題なくアクセシビリティサービスを動作させながら、この分野でのセーフガードを追加する予定だ。

Auditor

Auditorサブプロジェクトについては、サイトのチュートリアルページ（英語）を参照のこと。

アップデート

アップデートシステムは、バックグラウンドでの自動アップデートを実装している。ネットワークに接続できる環境であれば、約4時間に一度、アップデートの有無を確認し、バックグラウンドでアップデートをダウンロード、インストールする。ダウンロードが中断されても、そこから再開されるので心配はない。同様に、アップデートはGrapheneOSのセカンダリインストールにインストールされ、アップデートが完了した後にアクティブなインストールになるので、インストールを中断するリスクはない。アップデートが完了すると、通知が表示されるので、通知内のボタンで再起動するか、通常の再起動を行うだけでよい。新たなバージョンの起動に失敗した場合、OSは過去のバージョンにロールバックされ、アップデーターは再度アップデートのダウンロードとインストールを試行する。

アップデータは、インストール済みのバージョンから最新バージョンに直接移行するために、OS全体ではなく、変更点のみをダウンロードする増分（デルタ）更新をする。定期的にネットワーク接続を行い、要求されたら再起動すれば、ほぼ常に過去数バージョンのOSを使用することができ、増分アップデートが常に利用可能なので、帯域幅の使用量を最小限に抑えられる。

訳注：OSのアップデートとは言っても、数ギガバイトをダウンロードするわけではなく、変更点だけのダウンロードのため、非常に軽い。

アップデータは、デバイスがロック/アイドル状態であるあいだに機能する。そしてまた、最初のロック解除前にもである。ユーザーデータの復号化以前に実行できるように明確に設計されているからだ。

訳注：少々意味がわかりません。

リリースの変更履歴は、リリースページで見ることができる。

設定

設定は、設定の「システム」➤「システムアップデート」からできる。

「Check for updates」オプションは、手動でできるだけ早くアップデートチェックを開始する。ただし、以下に示す設定条件が満たされるまでは待機する。許可されたネットワークタイプでのネット接続中であることだ。

テストに協力したい場合は、「リリースチャンネル」設定をデフォルトの「stable」チャンネルから「beta」チャンネルに変更できる。ベータ版チャンネルは通常、stableチャンネルに従うだけだが、ベータ版チャンネルは新機能の実験に使用できる。

Permitted networks（許可されたネットワーク）設定は、アップデート実行のためにどのネットワークを使用するかを制御する。デフォルトでは、すべてのネットワーク接続が使われる。”Non-roaming “に設定すると、携帯電話サービスがローミングとマークされている場合に無効となり、”Unmetered “に設定すると、携帯電話ネットワークと、従量制とマークされているWi-Fiネットワークで無効となるように設定できる。

訳注：通常は、Unmeteredに設定すべきだろう。無料Wifi接続時のみアップデートを行うことになる。

”Require battery above warning level “は、バッテリーが警告メッセージを表示するレベル以上になってからアップデートを実行するかを制御する。標準値は、バッテリー残量が15％である。

“Automatic reboot”を有効にすると、アップデート後にデバイスが長時間アイドル状態になると、アップデーターがデバイスをリブートする。この設定を有効にすると、デバイスが完全にアイドル状態のままでも、任意の数のアップデートを完全に自動で処理できる。

“Notification settings”オプションは、システムアップデータ通知設定へのショートカットで、通知ドット、ロック画面、ノイズ/サイレント通知など、システムアップデータからの通知設定を制御することができる。これらの通知には、アップデータエラー、進行状況、すでに最新の状態であること、および再起動プロンプトが含まれる。デフォルトでは、すべての通知が有効である。

セキュリティ

アップデートサーバーは信頼できる当事者ではない（訳注：無くてもよい？）。アップデートは署名されており、ダウングレード攻撃の防止とともに検証されるためだ。（訳注：GrapheneOS内の）アップデートプロトコルは、アップデートサーバに個人を特定できる情報を送信しない。また、VPN/Tor 経由でも問題なく動作する。GrapheneOSは、IMEIやシリアル番号などの情報に基づいた特定のユーザーのデバイス向けの悪意のあるアップデートを構築、署名、出荷するという政府の命令には従うことができない。アップデートサーバーは、接続に使用されたIPアドレスと、要求されたインクリメンタルに基づくアップグレード元のバージョンしか知らないまま終了する。

訳注：アップデートは署名されているため、どのサーバからダウンロードしても良いと言っていると思われる。また、アップデートを行う時のGrapheneOSの動作としては、IMEIやシリアル番号の特定情報をサーバに送信しないため、スマフォを特定しての攻撃は不可能ということ。

Androidのアップデートは、特定のデバイスでのみ有効なシリアル番号の制約をサポートできるが、GrapheneOS は、無線アップデート（アップデータアプリ）およびサイドロードされたアップデート（リカバリ）の両方でシリアル番号の制約があるアップデートをする。

訳注：Androidのアップデートでは、要するにスマフォを特定して、特別なプログラムを仕込むことができるということ。GrapheneOSでは不可能。

無効化

モバイルデータ接続で帯域幅の使用が問題になる場合（訳注：携帯パケット制限のこと）は、自動アップデートを有効にしておきつつも、許可するネットワークを設定することを強くお勧めする。また、[設定] ➤ [アプリ] で [システムを表示] を有効にし、[システム更新] を選択してアプリを無効にすれば、更新クライアントをオフにすることも可能だ。この場合、アップデートの受信を開始するために、再度有効にする必要があります。

訳注：先ほど示したように、無料Wifi接続の時にだけアップデートを許可するようにすべき。また、全くアップデートを行わないようにするには、System updaterというシステムアプリを無効にする。

サイドローディング

訳注：普通の人はこれは必要ありません。

アップデートはリリースページからダウンロードすることもできる。そして、adb sideloading を使ってリカバリからインストールできる。zip ファイルは、OS 内のアップデートクライアントと同様に、リカバリによって署名および検証される。これには、バージョンをダウングレードしようとするのを防ぐ、ダウングレード保護の提供も含む。もしリカバリーがこれらを強制しなかったとしても、ダウングレード保護を含む検証済みブートによって強制され、試みられたアップデートはブートに失敗してロールバックされるだけである。

サイドロードでインストールするには、まず、リカバリで起動する。OSから「adb reboot recovery」を使うか、ブートローダーのインターフェースで「Recovery」オプションを選択することで行える。

緑色のAndroidが仰向けになって修復されているのが見えるはずだ。「No command」というテキストは、リカバリにコマンドが渡されていないことを意味しています。

次に、電源ボタンを押しながらボリュームアップボタンを1回押して、リカバリーメニューにアクセスする。このキーの組み合わせで、メニューとログが出力されるGUIモードとテキストベースモードが切り替わる。

最後に、リカバリーメニューの「ADBからアップデートを適用」を選択し、adbでアップデートをサイドロードする。例えば、以下である。

adb sideload raven-ota_update-2021122018.zip

リカバリーにアップデートをサイドロードするために、OS内でadbを有効にしたり、ホストのADBキーをOS内でホワイトリストに登録したりする必要はない。リカバリーモードでは、接続されたコンピュータを信頼しないため、これは製品版機能と考えることができる。OS 内の ADB アクセスを持つコンピュータを信頼することは、はるかに異なっており、デバイスを膨大な量の攻撃対象や信頼されたコンピュータによるコントロールにさらすことになる。

USB周辺機器

GrapheneOSのデフォルトでは、デバイス起動中で画面ロック中の場合、接続されたUSB周辺機器は無視される。ブート時にすでに接続されているUSBデバイスは動作する。その目的は、ユーザー・プロファイルへのログイン・セッションが有効なロック中デバイスの攻撃面を減らし、静止していないデータを保護することである。

訳注：おそらくは、起動中でロック中の場合には、悪者が何かしらのUSB機器を接続して悪さをする可能性があるということだろうか。

これは、設定➤セキュリティ➤USB accessories（現在はUSB peripherals）で制御できる。オプションは以下の通り：

Disallow new USB peripherals
新たなUSB周辺機器を許可しない
Allow new USB peripherals when unlocked (default)
ロック解除時に新たなUSB周辺機器を許可する（デフォルト）
Allow new USB peripherals (like stock Android)
新しいUSB周辺機器を許可する（純正Androidのように）。

このオプションは、コンピュータに接続されたときにデバイスがUSB周辺機器として動作することには影響しない。Androidのデフォルトは充電のみモードであり、ファイル転送、USBテザリング、MIDI、PTPにデバイスを使用するにはオプトインが必要である。

訳注：スマフォに何らかのUSB機器を接続するのではなく、スマフォをパソコンに接続した場合、デフォルトでは充電を行うのみであり、それ以外の機能を果たすには、それを指定する必要がある。例えば、スマフォを大容量ストレージとみなして、パソコンから中身を操作するには、それを選択する必要がある。

ウェブブラウズ

GrapheneOSは、プライバシーとセキュリティを強化したChromiumのリリースを提供するVanadiumサブプロジェクトを含む。

訳注：Chromiumとは、主にGoogleが開発しているオープンソース（設計図公開）のブラウザ。これをベースとして、様々な他のブラウザが開発されている。Vanadiumはその一つであり、他にBrave, Vivaldi, Edgeなどがある。

Vanadiumは、OSが含むユーザー向けブラウザであると同時に、他のアプリケーションがウェブコンテンツをレンダリングするために使用するWebViewのプロバイダでもある。WebViewは、ウェブコンテンツを埋め込んだり、ウェブ技術を他の用途に使用したりする他のほとんどすべてのアプリで使用されるブラウザエンジンである。

訳注：Vanadiumアプリや他のブラウザ以外の様々な一般的なアプリでも、ブラウザと同様にウェブページ（HTMLコンテンツ）を表示しなければならない場合があるが、これらはWebView機能を使っている。GrapheneOSの場合、VanadiumがWebViewプロバイダなので、結局のところ、GrapheneOS上で動作する一般アプリがウェブページを表示するときには、間接的にVanadiumを使うことになる。

これはまた、Chromium全体をフォークしていない多くのマイナーなウェブブラウザでも使用されている。WebViewを使用するこれらのアプリは、Vanadiumハードニングのサブセットの恩恵を受けている。

訳注：ならば、ブラウザが必要であってもブラウザを作る必要はなく、ブラウザと称してその中身はWebViewを利用すれば良いはずで、この場合にも、セキュリティ強化したVanadiumの恩恵を受けられる。

Vanadiumは、以前は主にセキュリティの強化に重点を置いていたが、我々は、さまざまなプライバシーとユーザビリティの機能を追加する予定だ。近い将来、常時シークレットモードのサポート、コンテンツフィルタリング（広告ブロックなど）、状態パーティショニングの改善、バックアップ／リストア、その他多くの機能を追加する予定である。

VanadiumのようなChromiumベースのブラウザは、他のブラウザを大きく引き離して最強のサンドボックス実装を提供する。サンドボックスから逃れるのは難しく、OSの他の部分を危険にさらすための障壁として機能する以上のものを提供している。サイトの分離は、各サイトを分離されたサンドボックスに置くことで、サンドボックスを使用する各サイトのセキュリティ境界を強制する。

訳注：一つのブラウザで複数のウェブページを表示するのはごく普通のことだが、例えばそれらの間で安易に互いのデータが読み込めてしまうとまずいことになる。ここで言うサンドボックスとは、どうやろうが閉じ込められた箱以外には手を出せないということ。

全てのIPC APIにこのルールを適用しなければならないため、ブラウザの大幅な見直しが必要だった。サイトの分離はサイドチャネルのために妥協がなくても重要だ。サイト分離のないブラウザはSpectreのような攻撃に対して非常に脆弱である。モバイルではアプリが利用できるメモリが少ないため、サイト分離には様々なモードがある。Vanadiumは厳密なサイト分離をオンにし、デスクトップのChromiumと同じように厳密なオリジン分離を行う。

Chromiumには、利用可能な代替品とは異なり、適切なエクスプロイト緩和機能がある。Vanadiumでは、上流で開発されたもののコードサイズやメモリ使用量、パフォーマンスなどの理由でまだ完全には有効化されていないものも含め、さらなる緩和策を有効にすることでこれを改善している。例えば、デスクトップでChromiumのような型ベースのCFIを有効にし、より強力なSSP設定を使用し、デフォルトで変数をゼロ初期化するなどである。緩和策のいくつかはOS自体から受け継がれており、少なくともそれを壊すようなことをしなければ、他のブラウザにも適用される。

我々は、ブラウザの拡張機能や修正を重ねることで、ブラウザのプライバシーやセキュリティを達成しようとしないことをお勧めする。ブラウザのプライバシー機能のほとんどは明確な脅威モデルのないプライバシー劇場であり、これらの機能はしばしばフィンガープリンティングを助長し、サイト間で共有される状態を増やすことでプライバシーを低下させる。あなたが変更を加えるたびに、あなたは群衆から目立つことになり、一般的にあなたを追跡する方法を増やすことになる。コンテンツフィルタリングによって悪意を列挙することは、アンチウイルスがまともなセキュリティを達成するための実行可能な方法ではないのと同様に、まともなプライバシーを達成するための実行可能なアプローチではない。これらは負け戦であり、本当のプライバシーとセキュリティ機能を待つ間、せいぜいその場しのぎで露出を減らすのが関の山だ。

Vanadiumは、Torや多くのユーザー間で共有される信頼できるVPNを通じてIPアドレスを隠すことが本質的なベースラインであり、ブラウザがサイトに基づいて状態を分割し、フィンガープリンティングを緩和することで、それが些細なことで回避されるのを避けるという流儀に従うだろう。Torブラウザのアプローチは、現在の実装にどんなに欠陥があろうとも、本当の可能性を秘めた唯一のものである。この作業は現在非常に初期段階にあり、利用可能な最も強力なステート・パーティショニングの実装により、大部分がアップストリームで実装されている。ChromiumはNetwork Isolation Keysを使用して、接続プール、キャッシュ、その他の状態をサイトに基づいて分割しており、これがプライバシーの基礎となる。Chromium自体が、クッキー以外のメカニズムによるトラッキングを防ぐことを目指しており、下流の作業がカバーすべき範囲を大幅に狭めている。すべてがまとまる準備ができる前に、この断片を配備することにあまりメリットがないと考えられるため、現在は研究に重点を置いている。現時点では、プライバシーのかけらもないブラウザはTorブラウザだけだが、アンチフィンガープリントやステート・パーティショニングをバイパスする方法はたくさんある。Torブラウザーのセキュリティは弱く、それがプライバシー保護を弱くしている。多様性（フィンガープリンティング）を避ける必要性が、最も興味深いターゲットに対するモノカルチャーを作り出している。特にTor自体が人々を(ローカルと出口ノードの両方で)よりターゲットにするので、これは変える必要がある。

WebView ベースのブラウザは、強化された Vanadium レンダリングエンジンを使用しているが、WebView ウィジェットでサポートされる機能に制限されているため、多くのプライバシーと制御を提供することはできない。例えば、センサーへのアクセスをトグルする設定を提供することはできない。なぜなら、この機能はかなり新しく、WebView WebSettings APIは、JavaScript、位置情報、クッキー、DOMストレージ、その他の古い機能に対するサポートと同様に、まだこの機能に対するサポートを含んでいないからだ。センサーについては、GrapheneOS によって追加された Sensors app permission をブラウザアプリ全体に対してオフに切り替えることができる。WebViewサンドボックスは現在、すべてのインスタンスを同じサンドボックス内で実行し、サイトの分離をサポートしていない。

FirefoxのようなGeckoベースのブラウザは、現在のところ悪用されやすく、本質的に攻撃対象が膨大になるため避けてほしい。Gecko には WebView の実装がないため（GeckoView は WebView の実装ではない）、Chromium の代わりに Chromium ベースの WebView と一緒に使う必要がある。Firefox / Geckoはまた、アプリのためのアップストリームとGrapheneOSのハードニング作業のかなりの部分を迂回したり麻痺させたりする。最悪なことに、FirefoxはAndroid上で内部サンドボックス機能を持っていない。Android上のChromiumセマンティック・サンドボックス・レイヤーはOSのisolatedProcess機能によって実装されているにもかかわらずだ。これはアプリ・サービス・プロセスのための非常に使いやすいブール値のプロパティで、標準のサービスAPIを介してアプリと通信する能力だけを持つ強力な隔離を提供する。デスクトップ版でさえ、Firefox のサンドボックスは（特に Linux では）まだかなり弱く、コンテンツを全体として含むだけでなく、サイトを互いに隔離するための完全なサポートが欠けている。サンドボックスはデスクトップでは徐々に改善されているが、Androidブラウザではまだ実現していない。

カメラ

GrapheneOSには純正OSと同じカメラ機能と品質がある。各OS上で同アプリを比較した場合、純正OSに匹敵するだろう。GrapheneOSは、標準のAOSPカメラアプリではなく、独自のモダンなカメラアプリを使用している。

訳注：オープンソースであるAOSPにもカメラアプリが提供されているが、GrapheneOSはそれではなく、独自のものを提供している。

GrapheneOSカメラは、ポータブルなオープンソースのカメラアプリや、有料アプリを含むほとんどのプロプライエタリなカメラアプリよりはるかに優れている。Pixelスマフォでは、Google Cameraがより多くの機能を備えた代替アプリとして使用できる（つまり、GrapheneOSではGoogle Cameraも使える）。以下のセクションでは、GrapheneOS Cameraの使用方法について詳しく説明し、その次のセクションでは、PixelでのGoogle Cameraの残りの利点について説明する。

GrapheneOSカメラアプリ

GrapheneOSは、プライバシーとセキュリティに重点を置いた独自の最新カメラアプリを含む。このアプリには、画像、ビデオ、QR / バーコードスキャン用のモードと、CameraXベンダー拡張機能（ポートレート、HDR、ナイト、フェイスレタッチ、オート）に基づく追加モードを含む（これはPixelではまだ利用できない〜訳注：おそらく純正OSでは利用できないの意）。

訳注：CameraXとは、Androidにおけるカメラアプリの作成を用意にするライブラリのこと。

モードは画面下部にタブとして表示される。タブのインターフェイスを使用するか、画面上の任意の場所を左右にスワイプすることでモードを切り替えられる。画面上部の矢印ボタンは設定パネルを開き、設定パネル外のどこかを押すことで閉じることができる。また、下にスワイプして設定を開き、上にスワイプして閉じることもできる。QRスキャンモード以外では、タブバーの上に大きなボタンが並んでおり、カメラの切り替え（左）、画像の取り込みとビデオ撮影の開始／停止（中央）、ギャラリーを開く（右）ことができる。ボリュームキーは、キャプチャボタンを押すのと同じように使うこともできる。ビデオ録画中は、ギャラリー・ボタンが画像をキャプチャするための画像キャプチャ・ボタンになる。

我々のカメラアプリは、他のアプリが使用するシステムメディアインテントを提供する。他アプリは、OSが提供するカメラ実装を介して画像をキャプチャ／ビデオを録画するのである。Android 11以降、これらのインテントはシステムアプリによってのみ提供されるため、システムカメラの品質は非常に重要だ。

訳注：GrapheneOSのカメラアプリはシステムアプリであり、一般のアプリがカメラ機能を必要とする場合に、カメラアプリの機能が利用される。結局あらゆるアプリがこれを使うので、品質が重要になる。

このアプリには、アプリ内のギャラリーと、それで撮影した画像/動画のビデオプレーヤーがある。現在、編集操作のために外部エディタ・アクティビティを開いている。GrapheneOSには、エディタ・アクティビティを提供するAOSPギャラリーが付属する。より良いフォトエディタをインストールすれば、カメラアプリはそれを使用できるようになる。将来的には、AOSPギャラリーをカメラアプリ用に開発中のスタンドアロン型のギャラリーに置き換える予定だ。

訳注：撮影済写真や動画を見るのは、AOSPで提供されているギャラリーアプリを呼び出しているが、将来的には独自のものになるらしい。

画像としてはデフォルトの4:3アスペクト比の使用をお勧めする。16:9はすべてのサポートデバイスで単にトリミングされた出力だからだ。動画撮影に特化したデバイスであれば、実際にはより広いイメージセンサーを搭載しているかもないが、Pixelや他のほぼすべてのスマートフォンではそうではない。

訳注：Pixelのカメラは4:3の比率なので、この比率の画像が最も解像度が高い。

画像キャプチャは、対応するすべてのPixelで軽量のHDR+を使用し、第5世代Pixelではプレビュー用にHDRnetを使用する。トーチやカメラのフラッシュを使うとHDR+が無効になるため、自動フラッシュはデフォルトでは有効になっていない。軽量なHDR+は、より積極的なGoogle Camera HDR+ほど多くのフレームを使用しない。

訳注：例えば、太陽を背にした人物の写真を撮ると、人物自体が暗くなってしまうことを避けられるという類の話。

CameraXの拡張機能では、最終的に、よりアグレッシブなHDR+で3フレーム程度以上の撮影／合成を行うHDRモードと、フレームを合成することでシーンの明るさを増加させるHDR+のNight Sightバリアントを提供するNightモードがサポートされる予定だ。ポートレートモードのような他の派手な機能も、将来提供されるCameraXの拡張機能に依存する。これに関するスケジュールはないが、最初の実装は来年中にPixels向けに出荷される可能性が高い。

ピンチ・トゥ・ズームまたはズーム・スライダーによるズームは、Pixelの広角カメラと望遠カメラを自動的に利用する。第5世代と第6世代のPixel（4a（5G）、5、5a、6、6 Pro）には広角カメラが搭載されており、1倍以下までズームアウトしてより広い視野を撮影することができる。広角レンズで撮影した画像は、特に第6世代Pixelでは、通常のカメラの画質には及ばない。フラッグシップの第4世代Pixel（4、4 XL）には光学2倍ズームの望遠カメラがあり、Pixel 6 Proには光学4倍ズームの望遠カメラがある。

デフォルトでは、シーン全体で連続オートフォーカス、自動露出、オートホワイトバランスが使用される。フォーカスをタップすると、その場所に応じたオートフォーカス、オート露出、オートホワイトバランスに切り替わる。

フォーカスのタイムアウト設定は、デフォルトモードに切り替わるまでのタイムアウトを決定する。左側の露出補正スライダーは、露出を手動で調整することができ、軽量HDR+サポートを中断することなく、シャッタースピード、絞り、ISOを自動的に調整する。さらなる設定/チューニングは将来提供される予定だ。

QRスキャンモードは、画面に表示されたスキャン用正方形内のみをスキャンする。QRコードは正方形の端に揃える必要があるが、90度の向きは自由だ。非標準の反転QRコードも完全にサポートしている。ピクセルから非常に高密度のQRコードを簡単にスキャンできる、非常に迅速で高品質のQRスキャナーである。2秒ごとにオートフォーカス、オート露出、オートホワイトバランスを更新する。ズームイン、ズームアウトにも対応している。トーチは中央下のボタンで切り替え可能。左下の自動トグルは、サポートされているすべてのバーコードタイプのスキャンを切り替えるために使用できる。また、上部メニューからスキャンするバーコードの種類を選択できる。デフォルトではQRコードのみをスキャンする。他のほとんどの種類のバーコードは誤検出する可能性がある。有効なタイプはそれぞれスキャンの速度を遅くし、特に高密度なQRコードのようなスキャンが難しいバーコードでは誤検出を起こしやすくなる。

カメラの許可が唯一必要だ。画像や動画はMedia Store API経由で保存されるため、メディア／ストレージパーミッションは必要ない。Microphoneパーミッションは、デフォルトではビデオ録画に必要だが、オーディオを含めない場合は必要ない。位置情報のパーミッションは、位置情報のタグ付けを明示的に有効にしている場合にのみ必要だ（これは実験的な機能である）。

訳注：カメラアプリには位置情報を許可しないのが得策と思われる。なぜなら、撮った写真をそのままうっかり公にしてしまうと、その写真には位置情報が含まれ、場所が特定されてしまうから。

デフォルトでは、キャプチャした画像のEXIFメタデータは取り除かれ、向きのみが含まれる。動画のメタデータは削除される予定だが、まだサポートされていない。オリエンテーションメタデータは、画像の表示方法から完全に見えるため、隠しメタデータとしてカウントされず、適切な表示に必要なため、取り除かれない。EXIFメタデータのストリッピングは、設定ダイアログから開く「その他の設定」メニューでオフに切り替えできる。メタデータのストリッピングを無効にすると、タイムスタンプ、電話機モデル、露出設定、およびその他のメタデータが残る。位置情報のタグ付けはデフォルトで無効になっており、有効にすると剥がされなくなる。

電子式手ブレ補正（EIS）は、Camera2 API経由で提供されているデバイスではデフォルトで有効になっており、ビデオ設定ダイアログを使用して無効にできる。

Zero Shutter Lag (ZSL)は、More Settingsのオプトイントグルで利用可能で、フラッシュが無効の場合、Cameraモードの画像キャプチャを高速化する。

Googleカメラ

GrapheneOS では、GSF やサンドボックス化された Google Play は必要ない。Google Cameraを含むGoogleアプリによるTPUとGXPへの直接アクセスは、GrapheneOSによって追加されたトグルによって制御され、データへの追加アクセスは提供されない。このトグルは攻撃対象領域を減らすために存在する。すべてのアプリは、Android Neural Networks APIとCamera2 APIを含む標準的なAPIを介して、TPUとGXPを使用できる。

我々は、特にPixel上で、GrapheneOS Cameraと比較してGoogle Cameraの利点を減らすことを目指している。Google Cameraの多くの機能は、より積極的なHDR+、Night Sight、Portraitを含むCameraXの拡張機能を通じて、来年かそこらでGrapheneOS Cameraでも利用できるようになるだろう。スローモーションやタイムラプスなどのビデオ機能は、来年中というよりもっと先のことになりそうだ。これらのビデオ機能は、CameraXベンダーによる拡張機能で提供される可能性があるし、ビデオ出力の独自の後処理で実装される可能性もある。パノラマ、Photo Sphere、天体写真、モーションフォト、Frequent Faces、Dual Exposure Controls、Google LensなどはGrapheneOS Cameraのロードマップにはない。ビデオフレームレート設定とH.265のサポートは、CameraXの改良によって近い将来GrapheneOS Cameraで利用できるようになり、さらに将来DNG（RAW）をサポートするようになるはずだ。

Exec Spawning

GrapheneOSは、アプリケーションをスポーンする際に、従来のZygote Spawningモデルを使わず、（execを介して）新たなプロセスを作成する。これにより、プライバシーとセキュリティが向上するが、コールドスタート時のアプリケーション起動時間と初期メモリ使用量が増加する。（しかし）最初のスポーン時間以上のランタイム・パフォーマンスには影響しない。フラッグシップ・デバイスのアプリ起動時間には200ms程度追加され、CPUが弱く、ストレージが遅いローエンド・デバイスでのみ顕著になる。スポーンタイムの影響は、アプリがまだアプリ・プロセスを持っていない場合にのみ適用され、OSは、メモリ・プレッシャーがアプリ・プロセスを強制的に殺し始めるまで、アプリ・プロセスをバックグラウンドにキャッシュしておこうとする。

訳注；何かしらのアプリを起動する場合、通常のAndroidでは、Zygoteという方式を使い、「どんなアプリにも使えるレディ状態のもの」をコピーすることで起動時間を短縮しているが、GrpaheneOSでは、いわばゼロからプロセスを作り出すため、若干遅くなる。しかし、フラッグシップ（トップに位置する製品）では、200msの遅延だという。また、一度アプリを起動すれば、メモリ不足にならない限りメモリ内にとどまるので、それ以降の起動は変わらない。

典型的なZygoteモデルでは、ブート時にテンプレートアプリプロセスが作成され、すべてのアプリがそのクローンとしてスポーンされる。この結果、すべてのアプリが同じ初期メモリコンテンツとレイアウトを共有することになり、プロセスごとにランダム化されるはずのシークレットも共有されてしまう。初期化作業を再利用することで、時間を節約できるのだ。コピーオンライト・セマンティクスにより、初期化時にのみ書き込まれるメモリがアプリ・プロセス間で共有されるため、初期メモリの使用量が削減される。

訳注：他Androidで使われるZygoteモデルでは、システム起動時にテンプレートが作成されて、アプリの起動時には、このコピーが作られて使われる。つまり、同じもののコピーなので、ランダムであるべきシークレットも同じものになってしまう。

Zygoteモデルは、アドレス空間レイアウトのランダム化（ASLR）、スタック・カナリア、ヒープ・カナリア、ヒープ・レイアウトのランダム化、メモリ・タグなど、ランダムな秘密に基づく機能によって提供されるセキュリティを弱めてしまう。すべてのアプリが他のすべてのアプリの値を持ち、再起動するまで新たなアプリ・プロセスで値が変更されないため、これらのセキュリティが機能しなくなる。OS自体の多くは、OSコンポーネントのために予約された特権を持つ非ユーザー向けアプリを介して実装されている。Zygoteテンプレートはユーザープロファイル間で再利用されるため、共有されたランダム化された値を介して、起動ごとにプロファイル間でデバイス識別子の一時的なセットも提供する。

この機能は、設定 ➤ セキュリティ ➤ Secure app Spawningにて無効にすることができる（デフォルトは有効＝enabled）、コールドスタート時のアプリの起動時間の短縮や、アプリプロセスのメモリ使用量の削減をお望みであればだ。つまり、実質的なセキュリティ上の利点や、プロファイル間で唯一残っている既知の直接デバイス識別子の削除（フィンガープリンティングのグローバル設定や利用可能なストレージ容量などに依存しない、サイドチャネルを使用しない）ではなく、ということである。

セキュリティ機能により発見されるバグ

GrapheneOS は、メモリ破壊の脆弱性に対する標準的軽減策を大幅に拡大している。これらの機能のいくつかは、明示的なチェックまたはメモリ保護によってメモリ破壊のバグを直接検出し、悪用されないようにプログラムを中断するように設計されている。他の機能としては、次に示すように直接的に軽減するものではない。例えば、解放時に即座にデータをゼロにする、隔離されたメモリ領域、ヒープのランダム化などだ。

訳注：標準的なAndroidでは、アプリによるメモリ破壊という脆弱性を受け入れてしまうが、GrapheneOSは、このようなアプリを中断するということらしい。また、他アプリが使用した後のメモリ内容が利用不可能にすべく工夫をしている。

つまり、アプリの潜在的なメモリ破壊バグの多くは、OS自体のバグとともに捕捉されることになる。これらのバグはGrapheneOSが引き起こしたものではなく、すでに存在しており、この機能によって発見されるものだ。GrapheneOSの機能は、バグを発見することではなく、悪用を防止または妨害することを目的としているが、それがその実際の仕事の一部として行われる。

訳注：他のAndroidで正常動作するアプリでも、GrapheneOSでは中断してしまうことがあるが、それはGrapheneOSの問題ではなく、アプリ自体の問題である。

同様に、他のプライバシーとセキュリティの改善の一部は、アプリケーションが利用可能なアクセスを減少させ、それらがクラッシュする可能性がある。これらの機能のいくつかは、舞台裏で常に有効になっているが、ネットワークやセンサーのトグルのような他のものは、オプトインまたはオプトアウトのトグルによってユーザーが制御することができる。アプリはこのようにアクセス権を奪われることに対処できないかもしれないが、概して問題は発生しない。アプリが規則に違反したときにアプリを殺すのではなく、アプリに友好的で完全な互換性があるように設計されているためだ。

訳注：例えば、GrapheneOSでは、アプリのネットワークアクセスを禁止できるが、ネットワークアクセスを前提としたアプリでも、それをストップさせてしまうのではなく、互換性があるように設計されているらしい。

Exploit protection compatibility modeは、設定 ➔ アプリ ➔ 何かしらのアプリ ➔ 詳細設定から有効にできる。Exploit protection compatibility modeのトグルは（ONにすることにより）、（GrapheneOSデフォルトの）hardened_mallocからAndroidの標準アロケータ（Scudo）に切り替え、アドレス空間サイズを48ビットからAndroidの標準39ビットに縮小する。また、原因を特定の機能に絞り込みたい場合は、Configure hardeningメニューにこれらの機能の個別のトグルがある。

訳注：mallocとはアプリがメモリを必要とする場合に、それを与えるためのライブラリ関数。これもまた標準のAndroidで使用されているものとは異なるセキュリティに配慮したものになっている。ちなみに、Configure hardeningメニューは表示されない場合がある。次にディスカッションがある。https://discuss.grapheneos.org/d/2410-where-would-i-find-the-configure-hardening-menu/11

もしアプリケーションが異常終了した場合は、その問題を再現するためのプロセスを考え、開発者オプションの「バグレポートを取る」機能を使ってバグレポートをキャプチャしてほしい。GrapheneOS OSのissue trackerに問題を報告し、件名に「Bug report capture for issue #104」のようにissue tracker番号を入れ、バグレポートのキャプチャZIPをcontact@grapheneos.org。バグレポート・キャプチャーには、ログ、トレースバック、アドレス空間のレイアウト、レジスタの内容、およびデバッグに興味深い領域のメモリからのほんの少しのコンテキストを含むプレーンテキストの「墓碑銘」が含まれる。これには機密データが含まれている可能性がある。関連するクラッシュの墓石だけを提供し、送信したくない情報をフィルタリングするのは自由だ。ただし、提供する情報が少ないとデバッグが難しくなる。アプリが機密情報で動作しない場合は、墓石全体を送信してほしい。

訳注：常にそうだが、開発者は完全に状況が再現できないとバグの修正はできず、「アプリが中断します」などの報告は、何の助けにもならない。

Wi-Fiのプライバシー

GrapheneOSのWi-Fiは非常にプライバシーに配慮しており、アプリによって一意識別可能な情報がネットワークに漏らされない限り、基本的に匿名である（訳注：OS自体ではなく、インストールしたアプリによっては一意情報を流してしまい、特定されてしまう）。GrapheneOSは、明示した接続（デフォルト接続のFAQを参照）以外では、GrapheneOSと認識されることを避け、簡単に無効にしたり、VPNサービスを通じて強制したりすることが可能である。

スキャニング

Wi-Fiスキャンにおいて、常にMACランダム化が実行される。Pixelスマフォ（訳注：GrapheneOSが唯一対象としているGoogle製のスマフォ）は、MACランダム化のスキャンをファームウェアでサポートしており、通常の実装を大幅に超えている。他多くのデバイスでは、パケットシーケンス番号やプローブ要求内の各種識別情報など、MACアドレス以外の識別子がWi-Fiスキャンによって公開されることがある。

訳注：GrapheneOSが唯一対象としているGoogle製のPixelという機種では、MACアドレスのランダム化をサポートし、なおかつ、他情報を隠すことができるため、他の機種とは異なり、端末を特定する情報を取得されることがない。

SSIDをブロードキャストしていないAP（アクセスポイント、Wifiルータ）の使用は避けてほしい。既知の隠しSSIDはすべて、ネットワーク再発見のためのスキャンの一部としてブロードキャストされるためである。SSID は、標準的な非表示のAPではブロードキャストはされない。隠しAPは、デバイスが接続されていないときしか隠されないので、プライバシー機能としてはほぼ意味がない。特に、移動しないAPの場合、APの存在を知っても、移動しないので追跡には使用できない。この機能は、プライバシーを高めるどころか、むしろ低下させるのである。隠しAPを使用する必要がある場合は、保存したネットワークを後で必ず削除することである。

訳注：WifiリストにSSIDが表示されない隠しAPを使用することはほとんど無いと思われるが、もし使うとしても、プライバシーを増すわけではなく、意味が無いということ。

純正OS（訳注：Googleによる元から入っているAndroidのこと）と異なり、位置検出向上のためのWi-FiとBluetoothのスキャンは、GrapheneOSではデフォルトで無効化されている。これらは、「設定」➤「位置情報サービス」➤「Wi-FiとBluetoothのスキャン」で切り替えが可能である。これらの機能は、Wi-FiやBluetoothを無効にしてもスキャンを有効のままにするので、Wi-FiやBluetoothを無効にしたときに無線を完全に無効にしたい場合には、これらを無効にしておく必要がある。GrapheneOS自体には、現在のところWi-FiおよびBluetoothスキャンに基づく補助的な位置情報サービスは含まれていない。これらのオプションは、サンドボックス化されたGoogle Playなどのアプリに位置情報の許可を与えた場合に、その機能を使用できるかどうかに影響する。GrapheneOSは、位置情報を利用する際に、ネットワークベースのサービスではなく、ローカルのデータベースに基づくOSサービスを最終的には搭載する予定である。

訳注：現在位置の検出には通常GPSが使用されるが、GPS以上に正確な位置を割り出すために、Googleは「どのWifiに接続しているのか」等という情報にもアクセスしている。当然のことながら、これはGoogleがユーザをスパイするための一手段である。が、GrapheneOSにこの機能は無い。

アクセスポイント(AP)との関連付け

関連付けられたMACのランダム化は、デフォルトで実行される。これは、設定 ➤ ネットワークとインターネット ➤ インターネット ➤ <ネットワーク> ➤ プライバシーでネットワークごとに制御できる。

純正OSでは、デフォルトで各ネットワークに一意の永続的なランダムMACアドレスが使用される。「ランダムMACアドレスの使用 (デフォルト)」と「デバイスMACアドレスの使用」の二つの選択肢がある。GrapheneOSでは、デフォルトでは、ネットワークに接続する際に新たなランダムなMACアドレスが生成される。三つの選択肢を用意している。「接続ごとにランダムなMACアドレスを使用する（デフォルト）」、「ネットワークごとにランダムなMACアドレスを使用する」、「デバイスMACアドレスを使用する」である。

DHCPクライアントは、ホスト名を送信するのではなく、匿名プロファイルを使用するため、MACランダム化によるプライバシーを損なうことはない。GrapheneOSによって追加された接続ごとのMACランダム化を使う場合、ネットワークに再接続する前にDHCPクライアントの状態がフラッシュされ、以前と同じデバイスである可能性が明らかにならないようにする。

訳注：基本的にはデフォルトのままで、端末の特定は不可能と思われる。つまり、カフェやホテル等のWifiに接続しても、「前回接続したスマフォと同じ」といった情報は取得できない。

また、GrapheneOSは、安定したリンクローカルIPv6アドレスのサポートを無効にしている。リンクローカル端末は両方にアクセスできるため、（ランダム化された）MACアドレスに基づく典型的なリンクローカルアドレス生成を使用する方がより賢明である。Android 11では、MACランダム化が無効の場合のみ、安定したリンクローカル・プライバシー・アドレスを使用するため、この機能を無効にする必要はなくなった。

LTE専用モード

通信事業者から信頼できるLTE接続がある場合、設定 ➤ ネットワークとインターネット ➤ SIM ➤ 優先ネットワークタイプで2G、3G、5G接続を無効にして攻撃表面を減らすことができる。従来の音声通話は、LTE接続とVoLTE（Voice over LTE）対応、またはWi-Fi接続とVoWi-Fi（Voice over Wi-Fi）対応のいずれかの場合のみ、LTE専用モードでも機能する。VoLTE / VoWi-Fi は、キャリア携帯に制限されない限り、ほとんどのキャリアの GrapheneOS で動作する。一部の通信事業者では、当社独自のアプリが含まれていないため、VoWi-Fiが利用できない場合がある。AT&Tは、LTEサービスを5Geと表記することでユーザーに誤解を与えているため、LTE Onlyモードを有効にすると5Geが使用されているように見えることがあるが、これはAT&Tが意図的にLTEサービスを「5Ge」と表記しているためだ。

この機能は、従来の通話やテキストの機密性を向上させるものではないが、ある種の傍受のハードルを多少上げる可能性がある。エンドツーエンドの暗号化された通話／テキストや、トランスポート層の暗号化の代わりとなるものではない。LTE は、基本的なネットワーク認証／暗号化を提供するが、それはネットワーク自体に対するものである。LTEのみの機能は、膨大な量のレガシーコードを無効化することで、リモートからの搾取に対するハードニングを意図しているに過ぎない。

訳注：正直、ここの記述は何を意味しているのかわかりません。

サンドボックス化されたGoogle Play

訳注：前提として、ごく普通のAndroidスマフォには、Googleサービスフレームワーク、Playサービス、Playストアがあらかじめインストールされている。これらが存在しなくとも動作するアプリも多いが、無いと全く動作しないものもある。

その一方で、これらの機能がまさに「Googleがユーザをスパイする方法」となっている。その存在を必要とすることもあるが、あるとスパイされるという問題の解決のため、LineageOS等では、micro-GというGoogle互換ソフトを利用している。その一方、GrapheneOSでは、Googleのプログラムそのものをインストールし、その「侵略的な行動」を許さないように制御している。

もちろん、ユーザ側で、これがなくとも動作するアプリのみを使うのであれば、存在自体を気にする必要はないし、以下を読む必要もない。

訳注：通常のAndroidには、Google Playアプリストアや他のGoogleのサービスがインストールされている。

使いたい一般アプリによっては、Googleのサービスが無いと動作しないものがあるため、Google Play他をインストールしたいのだが、これらによって、Googleの監視下に置かれてしまう。これを何とかするため、GrapheneOSでは、「サンドボックス化されたGoogle Play」という仕組みが提供されている。

GrapheneOSは、互換レイヤーを備えており、Google Playの公式リリースを標準のアプリサンドボックスにインストールして使うことができる。GrapheneOSにおいては、Google Playは特別なアクセスや特権が全く無い。これは、アプリサンドボックスをバイパスして大量の特権アクセスを受けるのとは対照的だ。そうではなく、互換レイヤーが、Google Playに対して、完全なアプリサンドボックス内で動作する方法を教えこむ。また、GrapheneOS自体は、Google Playがインストールされてもそれを使わないため、他のスマフォで使われるようなOSサービスのバックエンドとして使われることもない。

訳注：サンドボックスとは、猫砂を入れた箱のこと。ここで何をしようが、粗相をしようが、大勢には影響が無いということ。

Google Playをインストールしても、それは特権的アクセスが得られないし、GrapheneOS自体がそれを使うことも無い。単にGoogle Playを必要とするアプリに対し、そのサービスが提供されるだけ。

Google Playアプリは、GrapheneOS上ではただの普通のアプリなので、特定のユーザープロファイルや仕事用プロファイル内にインストールすると、そのプロファイル内でしか利用できない。同じプロファイル内のアプリだけが使うことができ、明示的に使用を選択する必要がある。他のアプリと同じように動作し、特別な機能は無い。他のアプリと同様に、他のアプリのデータにアクセスすることはできない。プロファイルデータにアクセスするためには、ユーザーの明示的な同意または標準のアクセス許可が必要になる。同じプロファイル内のアプリは、相互の同意があれば通信可能であり、サンドボックス化されたGoogle Playでもそれは同じである。

訳注：最近のAndroidには、プロファイルという機能があり、これは、一つのスマフォを複数のユーザが使えるというイメージである。それぞれのプロファイルは完全に独立しており、それぞれログインが必要になる。

例えば、一つのスマフォを複数の人間で使う場合には、ユーザプロファイルを追加していけば良い。それぞれのプロファイルのデータ領域は分離しているし、もちろんアプリも好みのものをインストールできる。一台のスマフォを、完全に別のスマフォとして使える。

仕事用プロファイルとは、一つのスマフォを仕事中に使う状態と、プライベートの状態に切り替えるものらしいが、スマフォ自体の他に、このプロファイルを管理するためのシステムが販売されているらしく、簡単に試すことはできないようだ。

ともあれ、これを利用することにより、「全くGoogleを必要としないプロファイル」、「Googleがなければ動作しないアプリ用のプロファイル」を切り替えることができる。

後者のGoogle Playをインストールするプロファイルでは、ある程度Googleに監視されてしまうと思われるが（推測）、その利用時間を制限することで、常時監視されることはなくなる。

サンドボックス化されたGoogle Playは完全な機能に近く、Google Playに依存するアプリのエコシステムとほぼ完全な互換性を提供する。（しかし）まだ互換レイヤーで異なるアプローチに移植していない特権的な機能の小さなサブセットだけの利用はできない。一部の機能は、本質的に特権的であり、互換性レイヤーの一部として提供することはできない。

訳注：Google Playは、そもそも特権的な機能であり、その特権を与えられないため、一部機能は利用できない。したがって、一部のアプリは全く動作しないかもしれない。

Playサービス機能の大部分は完全に動作する。動的にダウンロード/更新されるモジュール（dynamiteモジュール）や、Google Play Games などのモジュラーアプリコンポーネントが提供する機能などである。デフォルトでは、位置情報リクエストはGrapheneOSの提供するPlayジオロケーションサービスの部分的な実装にリルートされる。再ルーティングを無効にして、代わりに完全なPlayサービスのジオロケーションサービスを使用することもできる。

訳注：位置情報サービスをPlayサービスに任せてしまうと、Google側に位置が知られることになるが、デフォルトでは、これは起こらないということ。

我々の互換レイヤーは、Playストアを完全にサポートしている。アプリ内課金、Play Asset Delivery、Play Feature Delivery、アプリ/コンテンツのライセンスチェックなど、Playストアのサービスを完全に利用することができる。アプリのインストール、アップデート、アンインストールは、ユーザーがアプリのソースとして承認し、各アクションに同意することを必要とする標準的なアプローチで行うことができる。Android 12+の標準的な無人アップデート機能を使用して、最後のインストーラであるアプリの自動アップデートを実行する。サンドボックス化されたアプリによる無人アップデートは抑制されており、アップデートが限界に達して一括インストールする際に、同意を求めることがある。今後、しばらく待ってから無人アップデートを再試行するようにさせるよう、この点を改善する予定だ。

インストール

Google Playは、3つのアプリに分かれている。

Googleサービスフレームワーク（com.google.android.gsf)
Google Playサービス（com.google.android.gms)
Google Playストア (com.android.vending)

サンドボックス化されたGoogle Playを利用するには、これら3つのアプリの正式版を、利用したいユーザープロファイルや仕事用プロファイルにインストールするだけだ。

訳注：GSF(Googleサービスフレームワーク）、GMS（Playサービス）、Playストアは独立のアプリとしてインストールされる。三つすべてをインストールしないか、あるいは三つともインストールしてしまうのが最も簡単で、個別にインストールする人はいないと思われる。

デフォルトのユーザプロファイル（Owner）にインストールすることもできるし、別のユーザプロファイル、仕事用プロファイルにインストールすることもできる。

最もシンプルな方法は、Ownerユーザープロファイルのみを使用してしまうことだ。Ownerプロファイルにインストールされたアプリは、他の場所と同じようにサンドボックス化され、特別なアクセス権を受けることはない。すべてのアプリにGoogle Playを使わせるのではなく、それを利用するアプリを選択したい場合には、Google Playに依存するアプリ用に別のユーザープロファイルあるいは仕事用プロファイルを作り、そこにインストールする。その逆も可能だが、Google Playの不使用を例外とするのではなく、通常はGoogle Playを使わないようにする方が理にかなっている。

訳注：上述のように、デフォルト（Owner）とは別のユーザプロファイルを作成し、そこにGoogle PlayやGoogle Playを必要とするアプリをインストールするのが良い方法かと思われる。

この逆、デフォルト（Owner）にGoogleを入れてしまい、別のユーザプロファイルにGoogleの必要の無いアプリを集めるといったこともできるが、考えにくい構成だろう。

我々のアプリリポジトリのクライアント（Apps）を開き、私たちのリポジトリでミラーリングされた三つのコアGoogle Playアプリをインストールすることができる。我々のアプリリポジトリクライアントは依存関係のインストールをサポートしているので、単にPlayストアを直接インストールすることができ、それが依存するGSFとGMSを自動インストールする。

訳注：Appsというアプリが初めからGrapheneOSに入っているので、そこから単にPlayストアをインストールすれば、三つとも自動的にインストールされる。

プッシュ通知などの機能をバックグラウンドで適切に動作させるために、Google Play サービスにバッテリー最適化の例外を与える必要がある。他の二つのアプリには必要ない。

訳注：自動的に行われているものと思われる。

Playストアは、Play Asset Delivery、Play Feature Delivery、アプリ内課金、有料アプリのライセンスチェックなど、アプリが使う多くのサービスを提供する。Playストアなしでサンドボックス化された Google Playを使用することもできるが、多くのアプリは、Playストアなしでは正常に動作しない。また、Playストアアプリは、Playストアからアプリをインストールし、更新するための最も安全な方法である。一般的な用途ではインストールが強く推奨されるが、使いたいものに必要とわかっている場合は、GSFのみ、またはGSF/GMSのみをインストールすることも可能である。

訳注：三つすべてをインストールする必要は無い。Playストアの代わりにAurora Storeが使える。

Google Play をインストールした後、Play サービスを初期化する必要がある。おすすめの方法は、Playストアを開き、サインインボタンを押して、サインインページがロードされるのを待つことだ。サインインページがロードされたら、Playサービスの初期化が終了したことを意味する。アカウントにサインインせずにこのアプリを放置してもよい。Googleアカウントへのサインインは、アカウントへのサインインに依存する機能を使用したい場合にのみ必要である。例えば、一部のアプリでは、自身のアカウントとしてのユーザー名とパスワードの代わりに、Googleアカウントの認証を使用する。Playストアでは、アプリのインストールやアプリ内課金を利用するために、アカウントへのログインが必要になる。これは、Playストアの代替フロントエンドであっても同様だ。Aurora Storeでもアカウントは必要だが、デフォルトでAurora Storeのサービスから共有アカウントの認証情報を取得する。

これらのアプリのアップデートは、我々のアプリリポジトリクライアントから取得できる。我々の互換レイヤーは、Playストア自体の更新とPlayサービスもサポートしているが、我々は、テスト後に我々のリポジトリを介しての更新提供のために、更新されないようにブロックすることを選択した。彼らはこれらのアプリの更新のために長いステージングされたロールアウトを使っており、それは別のユーザーで古いバージョンをインストールできない場合に混乱を招く結果となっている。これは、更新を我々自身で処理することによって解決される。

我々の互換レイヤーは、Play Games Services をサポートしている。これは、Playストアから Google Play Games をインストールすることで得られる。Playストアにある多くのゲームは、Google Play Gamesがインストールに依存している。

コンフィグレーション

互換レイヤーは、設定 ➤ アプリ ➤ サンドボックス化された Google Play で設定メニューが利用可能である。

訳注：これらの機能をインストールしている場合のみに設定画面に表示される。

デフォルトでは、Google Playのジオロケーションを使用するアプリは、標準OSジオロケーションサービス（Googleのもの）ではなく、我々の独自の実装にリダイレクトされる。Googleのジオロケーションサービスを使いたい場合は、「Reroute location requests to OS APIs」トグルを無効にして、手動でGoogle Playサービスへのロケーションアクセスを「Allow all the time」許可をすることができる。また、これを完全に機能させるためには、「Google Location Accuracy」リンクを使用して、Google Playサービスのメニューにアクセスし、ネットワーク位置情報サービスにオプトインする必要がある。これは、位置推定を取得するために彼らのサービスに位置情報のアクセス許可を介して提供される近くのWi-Fiと携帯電話のネットワークを送信する。近くのデバイスの権限はまた、それが近くのBluetoothデバイスIDへのアクセスを与えるために付与することができる。デフォルトで有効なリダイレクトモードにこだわる場合には、これらの許可を与える必要はない。アプリではジオロケーション取得ができる。Wi-FiとBluetoothのスキャンを完全に活用するには、設定➤位置情報➤位置情報サービスのスキャンのトグルも有効にする必要があるが、これは純正OSのようにデフォルトで有効ではなく、無効になっている。

訳注：この設定を行うと、Googleのスパイ行為に加担することになると思われる。Playストアをインストールしたときにログインしていれば、自身の位置がわかってしまい、ログインしていなくとも、Googleのほしい情報を代わりに取得してあげることになる。

ただし、GrapheneOSがどの程度「Googleへの情報送信」を許しているのかは、この文章からは定かではない。

このOSのジオロケーションサービスへの位置情報の再ルーティングは、ネットワークベースの位置情報サービスを提供せず、GNSS/A-GPS（要するにGPS）のみで実装しているため、Google Playのジオロケーションサービスを利用するより多くの電力を消費する。将来的には、セルタワーのローカルデータベースを利用した擬似的なネットワーク型ジオロケーションサービスをOSに提供する予定であり、位置情報のリダイレクト機能も、将来的にこのOSの実装を利用して、ネットワーク型の位置情報要求を実現することが可能である。

訳注：Googleの位置情報サービスはGPSだけではなく、「近くにあるWifi」の膨大なデータベースを使っていると思われ、GPSよりも簡単に正確な位置が把握できている。

Google Location AccuracyとGoogle settingsは、通常OSに統合されているが、Google Playとの統合はしていないので、それらにアクセスするためのアプリが必要となる。

メニューには、この使用ガイド、Play サービスのシステム設定、Play ストアのシステム設定、および Google 設定へのリンクもある。Play サービスと Play ストアのシステム設定は、他のアプリと同様に設定 ➤ アプリからアクセスできるため、便宜上記載しているだけである。

制限

Playサービスの視点からは、侵略的アクセスや統合ができるものと思い込んでいるが、それらを一切行わさせずに通常のアプリとして動作するよう、我々の互換性レイヤーをケースバイケースで拡張していく必要がある。多くの場合、Playサービスはアクセスなど必要としないし、通常のアプリで利用可能な通常のアプローチを使うように教え込むことができる。しかし、それが提供する機能は、基本的に特権的なアクセスを必要とし、サポートできない場合がある。例えば、Android Autoがサポートされる可能性は低いだろう。その他、OSの統合／制御やハードウェアへの特権的アクセスなど、侵略性の高いものも同様だ。その一方で、FIDO2セキュリティキーのサポートなど、多くの特権APIに依存しながらも完全に動作させることができる機能も多い（同社のFIDO2サービスはすでに一部動作している）。FIDO2の場合、ジオロケーションのためにデフォルトで行っているのと同様に、私たち自身の実装へのリダイレクトもいずれはサポートできるようになるはずである。我々の互換性レイヤーは非常に活発に開発作業中であり、残りの利用できない機能のほとんどはすぐにサポートされるようになってきている。

OSにPlayサービスが統合され、それをバックエンドとして使用される機能は使用できない。Playを統合するOSは、ジオロケーションなどのOSサービスのバックエンドとして使用される。GrapheneOSが、これをOSサービスのバックエンド/プロバイダとして使用することは決してない。音声合成（TTS）のように、OSがプロバイダを選択できる場合は、Playのサービスを利用することが多いようである。GrapheneOS上の他のアプリと同じ土俵に立っているのである。

特権的eSIM管理

訳注：eSIMとは、SIMという物理的なカードをスマフォに入れる代わりに、何の物理的カードも必要なく、電子的にスマフォにSIM情報を登録する仕組みのこと。

GrapheneOSはデフォルトで常にeSIMのベースライン・サポートを搭載して出荷されており、ユーザーはデバイスに以前インストールされたeSIMを使用することができる。しかし、eSIMの管理と追加には、Google独自の機能が必要になる。これはデフォルトで完全に無効化されている。

訳注：例えば、Pixel 5aという機種はeSIMが使えるが、Googleの機能をインストールしていない状態では、設定画面を開いても無効化されている。

特権的eSIM管理は、設定➤ネットワークとインターネット➤Privileged eSIM managementで有効化できる。この機能はサンドボックス化されたGoogle Playに依存しているため、インストールされていなければ、トグルはグレーアウトして使用不能である。

トグルを有効にすることで、Google独自の機能が有効になり、OSはこれを、eSIMのプロビジョニングと管理に使用するようになる。

なお、ネット接続が安定しているにもかかわらず、eSIMのインストール作業が「ネットワーク情報の確認」段階まで進まない場合は、USSDコード*#*#4636#*#に電話をかけ、表示されたメニューでDSDSを有効にする必要があるかもしれない（おそらく米国内の話）。

銀行アプリ

銀行アプリは、代替OSの互換性において特に問題のあるアプリのカテゴリーである。どのGrapheneOSコンフィギュレーションでも問題なく動作するものもある（つまり、Playサービス無しで動くものもある）が、ほとんどのアプリはPlayサービスに広範囲に依存している。これらのアプリの多くは、同じプロファイルでGrapheneOSのサンドボックス化されたGoogle Play機能を設定するだけで十分だ。（しかし）残念ながら、非金融アプリ（一般のアプリ）では一般的に遭遇しない、さらなる複雑さがある。

これらのアプリの多くは、セキュリティ研究者からコードやAPIを隠そうとする弱い試みを行っており、アプリの検査や修正を防ごうとする独自の粗雑な改ざん防止メカニズムを持っている。GrapheneOSは、アプリのサンドボックスの改善のために、ユーザーが設定➔セキュリティのトグルでネイティブコードのデバッグを無効にすることができる。これはアプリを分析するための障壁を追加するので、独自のコードをデバッグするアプリを妨害しうる。無効にしていて、この種のアプリで互換性の問題が発生している場合は、再度有効にしてみてほしい。

訳注：設定→セキュリティ→Native code debuggingのこと。これはデフォルトでEnabled（有効）になっているので、特別な理由の無い限り操作する必要はない。

銀行アプリは、OSの完全性と認証ステータスをチェックするために、GoogleのSafetyNet Attestationサービスを使うようになってきている。GrapheneOSは、そのbasicIntegrityチェックには合格しているが、Googleの認証を受けていないため、ctsProfileMatchチェックには不合格である。ほとんどのアプリは現在、弱いソフトウェアベースの認証しか実施していないため、チェックする内容を詐称することで回避できる。GrapheneOSは、チェックをバイパスすることはしない。これは、非常に脆弱であり、チェックが改善されるにつれて繰り返し壊れてしまうためだ。Android 8以降で発売されたデバイスは、ハードウェア認証をサポートしており、漏洩したキーや深刻な脆弱性がなければ回避できないため、結果を詐称することでこれらのチェックを回避できる時代は終わりつつある。

ハードウェア認証機能はAndroidオープンソースプロジェクトの一部であり、GrapheneOSによって完全にサポートされている。SafetyNet Attestationは、Google認証オペレーティング・システムの使用を強制するためにこの使用を選択している。しかし、アプリ開発者はこれを直接使用し、セキュリティモデルを支持する他の適切に署名されたオペレーティングシステムを許可することができる。GrapheneOSは、ハードウェア認証APIでGrapheneOSをサポートする方法について、アプリ開発者向けの詳細なガイドを用意している。ハードウェア認証APIの直接使用は、SafetyNetを使用するよりもはるかに高い保証を提供するので、これらのアプリは、より有意義なAPIを使用し、より安全なOSをサポートすることによって失うものは何もない。

アプリのリンク検証

Androidアプリは、アプリ内でそれらのURLを自動的に処理するために、ドメインとの関連付けを宣言することができる。セキュリティ上の理由から、アプリが任意のURLを傍受するのを防ぐため、アプリのリンクはデフォルトで無効になっている。ドメインに関連付けられたファーストパーティアプリは、ドメインによって認可されていることが期待される。アプリは、マニフェストでautoVerifyとマークすることにより、OSによるアプリリンクの検証を求めることができる。OSは、ドメインがドメインのURLを扱うことをアプリに許可していることを安全に確認する。ユーザーは、設定 ➔ アプリ ➔ 「アプリ名称」 ➔ デフォルトで開く ➔ リンクを追加を使用して、アプリのリンクの関連付けを手動で有効にすることもできる。アプリはユーザーに関連付けを有効にするよう求め、設定アプリのこのページに送ることができる。

例として、ファーストパーティーのYouTubeアプリは、アプリリンクがOSによって自動的に検証されるが、NewPipeアプリはYouTubeや他のサイトのリンクを手動で有効にする必要がある。

訳注：例えば、友人からメッセージでYouTube動画のリンクが送られてきた場合、それをタップするとどうなるか。YouTubeアプリがインストールされていない場合は、ブラウザが開いて動画を見ることになる。YouTubeアプリがインストールされている場合は、（おそらくは）それが起動して動画が表示される。NewPipeは、YouTube等の動画サイトの動画を閲覧するためのオープンソースアプリだが、これをインストールした後にURLのタップで自動的に開きたい場合には、先の説明の通り「リンクを追加」を使って、対応するドメインについてNewPipeを起動することを指定する必要がある。

OSによるアプリリンクの検証は、Intent Filter Verification Serviceシステムアプリによって行われる。これは、HTTPS GETリクエストによりhttps://example.com/.well-known/assetlinks.jsonを取得するが、アプリがexample.comのリンクを処理できるかどうかを確認するリクエストを処理するためだ。検証を成功させるために、アプリはドメインによって承認されたアプリ ID と署名鍵を持つ必要がある。

ドメインとアプリの関連付けを検証するためのインテント・フィルタ検証サービスによるこれらのネットワーク要求は、一般にアプリによるネットワーク要求と混同される。これは識別情報のない単なる HTTPS GET リクエストであり、アプリとの通信チャネルを提供しない。リダイレクトは追跡されないため、ドメインを確認する各試行に対して1回のリクエストとなる。

アプリリンクの自動検証を望まない場合は、GrapheneOSがIntent Filter Verification Serviceシステムアプリに追加したNetwork権限を無効にすることができる。将来的には、検証の動作を停止する代わりに、検証を直接無効にする方法を提供する可能性がある。それは、保守的なJobSchedulerベースの実装のため、バッテリ寿命に悪影響を与えないチェックが失敗した後、ドメインを検証するために大きくスロットルされた試みを行う。

詳細については、アプリのリンク検証に関する開発者向けドキュメント（英語）を参照のこと。

キャリアサポート

GrapheneOSは、Pixelデバイスの純正OS上でGoogleが公式にサポートするすべてのキャリアでの動作を目指している。Wi-Fi通話、VoLTE、Visual Voicemail、MMS、SMS、通話、5G（SAおよびNSA）はすべてサポートされている。しかし、Googleが純正OSでキャリアを公式にサポートしていないか、あるいはGrapheneOSがキャリアによって機能動作に必要な専用アプリを出荷しておらず、一部機能が使用できない場合がある。GrapheneOSは、CarrierConfigs、APN、モデム設定、Visual Voicemail設定、およびMMS設定を純正オペレーティングシステムから抽出し、「単に動作する」簡単なキャリアサポートをユーザーが得られるようにする。

一部の地域では、LTEは4Gと呼ばれていることに注意してほしい。

一般的に5G、SMS、MMS、通話、VoLTEは、Googleが公式にサポートする通信事業者であればGrapheneOSで問題なく動作する。Wi-Fi通話は、GrapheneOSが出荷していないGoogle独自のアプリに依存するため、異なる場合がある。

ビジュアルボイスメールに問題がある場合、AT&T USAのユーザーはAOSPのサポートがないため、現在この機能を使用できないことをご了承いただきたい。その他のキャリアはベストエフォートで対応している。この機能を使用できない場合は、サンドボックス化された Google Play で Google Dialer を使用することをお勧めする。

SMS/MMSメッセージの送受信に問題がある場合は、以下の手順の実行をお勧めする：

Apple iMessage から電話番号を登録解除する。
Googleチャット機能から電話番号を登録解除する。
キャリアのRCSサービスから電話番号の登録を解除する（すべてのキャリアにあるわけではない）

上記の手順に従っても問題が解決しない場合、またはキャリアに関連する別の問題がある場合は、次の手順の実行をお勧めする：

キャリアによっては、Wi-Fi通話などのサービスを利用するために、明示的にオプトインする必要がある。この手順については、各キャリアのマニュアルを参照するか、各キャリアに問い合わせいただきたい。
「設定」➤「システム」➤「オプションのリセット」➤「Wi-Fi、モバイル、Bluetoothのリセット」でモバイルネットワークの設定をリセットし、デバイスを再起動する。
米国ユーザーのみ：問題がある場合は、CDMA-lessモードを有効にするようキャリアに依頼する必要があるかもしれない。
各キャリアの指示に従ってAPNを設定してほしい。設定 ➔ ネットワークとインターネット ➔ SIM ➔ アクセスポイント名で確認できる。
通話がうまくいかず、LTE専用モードが有効になっている場合は、オフにしてみてほしい。「2G を許可」が無効になっている場合は、オンに切り替えてみてほしい。キャリアがVoLTEを正しくサポートしていない可能性がある。
最後の手段としては、キャリアにSIMカードの交換を依頼する必要があるかもしれない。

キャリアによっては、輸入されたPixelデバイスのVoLTEなどの機能を制限している場合がある。GrapheneOS上のSKUは、設定 ➔ デバイス情報 ➔ モデル ➔ Hardware SKU に進み、Googleの公式ドキュメントを利用して確認できる。トラブルシューティングを行うには、このような機能が純正OSで動作するかどうかを確認する必要がある。生産デバイス（商品）でIMEIを変更することは不可能であり、GrapheneOSがこのサポートを追加することはない。

Android 12ではGSMA TS.43標準のサポートが導入され、VoLTE、VoNR、Wi-Fi通話のプロビジョニングがGoogle Firebaseによって処理されるようになった。現在のところ、キャリアがFirebaseを使用してこれを処理することは非常にまれである。そのようなキャリアでは、SMS経由のフォールバック・プロビジョニングが実装されていない場合、前述した機能を得るためにサンドボックス化されたGoogle Playをインストールする必要がある可能性は低いが、技術的には可能である。現在、US Cellular、Orange France、Cspire US、Cellcom USのみがこの標準を使用している。

GrapheneOSには、APN編集、USB、イーサネット、Bluetooth、Wi-Fi経由のテザリング、2Gを無効にする機能（第6世代と第7世代のPixelデバイスのみ）など、キャリアの制限を回避する機能が含まれており、これらは純正OSでは必ずしも可能ではなかった。