1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
|
<!DOCTYPE html>
<html lang="en" prefix="og: http://ogp.me/ns#">
<head>
<meta charset="utf-8"/>
<title>FAQ | GrapheneOS</title>
<meta name="description" content="Frequently asked questions about GrapheneOS."/>
<meta name="theme-color" content="#212121"/>
<meta name="msapplication-TileColor" content="#ffffff"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<meta name="twitter:site" content="@GrapheneOS"/>
<meta name="twitter:creator" content="@GrapheneOS"/>
<meta property="og:title" content="GrapheneOS FAQ"/>
<meta property="og:description" content="Frequently asked questions about GrapheneOS."/>
<meta property="og:type" content="website"/>
<meta property="og:image" content="https://grapheneos.org/opengraph.png"/>
<meta property="og:image:width" content="512"/>
<meta property="og:image:height" content="512"/>
<meta property="og:image:alt" content="GrapheneOS logo"/>
<meta property="og:url" content="https://grapheneos.org/faq"/>
<meta property="og:site_name" content="GrapheneOS"/>
<link rel="icon" type="image/vnd.microsoft.icon" href="/favicon.ico"/>
<link rel="mask-icon" href="/mask-icon.svg" color="#1a1a1a"/>
<link rel="stylesheet" href="/grapheneos.css?14"/>
<link rel="manifest" href="/manifest.webmanifest"/>
<link rel="canonical" href="https://grapheneos.org/faq"/>
</head>
<body>
<nav>
<ul>
<li><a href="/">GrapheneOS</a></li>
<li><a href="/install">Install</a></li>
<li><a href="/build">Build</a></li>
<li><a href="/usage">Usage</a></li>
<li class="active"><a href="/faq">FAQ</a></li>
<li><a href="/releases">Releases</a></li>
<li><a href="/source">Source</a></li>
<li><a href="/donate">Donate</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</nav>
<div id="content">
<h1 id="faq">
<a href="#faq">Frequently Asked Questions</a>
</h1>
<h2 id="table-of-contents">
<a href="#table-of-contents">Table of contents</a>
</h2>
<ul>
<li>
<a href="#device-support">Device support</a>
<ul>
<li><a href="#supported-devices">Which devices are supported?</a></li>
<li><a href="#recommended-devices">Which devices are recommended?</a></li>
<li><a href="#future-devices">Which devices will be supported in the future?</a></li>
<li><a href="#when-devices">When will more devices be supported?</a></li>
<li><a href="#legacy-devices">Why are older devices no longer supported?</a></li>
</ul>
</li>
<li>
<a href="#security-and-privacy">Security and privacy</a>
<ul>
<li><a href="#hardware-identifiers">Can apps access hardware
identifiers?</a></li>
<li><a href="#default-connections">Which connections do the OS and
bundled apps make by default?</a></li>
<li><a href="#cellular-tracking">What does GrapheneOS do about cellular
tracking and silent SMS?</a></li>
</ul>
</li>
</ul>
<h2 id="device-support">
<a href="#device-support">Device support</a>
</h2>
<h3 id="supported-devices">
<a href="#supported-devices">Which devices are supported?</a>
</h3>
<p>GrapheneOS has official production support for the Pixel 2, Pixel 2 XL, Pixel 3,
Pixel 3 XL, Pixel 3a and Pixel 3a XL. The release tags for these devices have official
builds and updates available. These devices meet the stringent privacy and security
standards and have substantial upstream and downstream hardening specific to the
devices.</p>
<p>Many other devices are supported by GrapheneOS at a source level, and it can be
built for them without modifications to the existing GrapheneOS source tree. Device
support repositories for the Android Open Source Project can simply be dropped into
the source tree, with at most minor modifications within them to support GrapheneOS.
In most cases, substantial work beyond that will be needed to bring the support up to
the same standards. For most devices, the hardware and firmware will prevent providing
a reasonably secure device, regardless of the work put into device support.</p>
<p>GrapheneOS also supports generic targets, but these aren't suitable for production
usage and are only intended for development and testing use. For mobile devices, the
generic targets simply run on top of the underlying device support code (firmware,
kernel, device trees, vendor code) rather than shipping it and keeping it updated. It
would be possible to ship generic system images with separate updates for the device
support code. However, it would be drastically more complicated to maintain and
support due to combinations of different versions and it would cause complications for
the hardening done by GrapheneOS. The motivation doesn't exist for GrapheneOS, since
full updates with deltas to minimize bandwidth can be shipped for every device and
GrapheneOS is the only party involved in providing the updates. For the same reason,
it has little use for the ability to provide out-of-band updates to system image
components including all the apps and many other components.</p>
<p>Some of the GrapheneOS sub-projects support other operating systems on a broader
range of devices. Device support for Auditor and AttestationServer is documented in
the <a href="https://attestation.app/about">overview of those projects</a>. The
<a href="https://github.com/GrapheneOS">hardened_malloc</a> project supports nearly
any Linux-based environment due to official support for musl, glibc and Bionic along
with easily added support for other environments. It can easily run on non-Linux-based
operating systems too, and supporting some like HardenedBSD is planned but depends on
contributors from those communities.</p>
<h3 id="recommended-devices">
<a href="#recommended-devices">Which devices are recommended?</a>
</h3>
<p>The recommended devices with the best hardware, firmware and software security
along with the longest future support time are the Pixel 3a, Pixel 3a XL, Pixel 3 and
Pixel 3 XL. The Pixel 3a and 3a XL are budget devices meeting the same security
standards as the more expensive flagship devices. Compared to the Pixel 3a and 3a XL,
the flagship Pixel 3 and Pixel 3 XL have wireless charging, dual front-facing speakers,
the Pixel Visual Core supporting HDR+ with compatible apps on GrapheneOS, IP68 dust
and water protection, a higher-end screen, slightly more durable glass and of course a
stronger CPU, GPU, cellular radio, etc. You should get one of the budget devices if
these things aren't compelling to you. The Pixel 3a and 3a XL do have one extra
feature: an analog headphone port as an alternative to wireless audio and digital
USB-C audio.</p>
<h3 id="future-devices">
<a href="#future-devices">Which devices will be supported in the future?</a>
</h3>
<p>Devices are carefully chosen based on their merits rather than the project aiming
to have broad device support. Broad device support is counter to the aims of the
project, and the project will eventually be engaging in hardware and firmware level
improvements rather than only offering suggestions and bug reports upstream for those
areas. Much of the work on the project involves changes that are specific to different
devices, and officially supported devices are the ones targeted by most of this
ongoing work.</p>
<p>Devices need to be meeting the standards of the project in order to be considered as
potential targets. In addition to support for installing other operating systems,
standard hardware-based security features like the hardware-backed keystores, verified
boot, attestation and various hardware-based exploit mitigations need to be available.
Devices also need to have decent integration of IOMMUs for isolating components such
as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image
processor, etc., because if the hardware / firmware support is missing or broken,
there's not much that the OS can do to provide an alternative. Devices with support for
alternative operating systems as an afterthought will not be considered. Devices need
to have proper ongoing support for their firmware and software specific to the hardware
like drivers in order to provide proper full security updates too. Devices that are
end-of-life and no longer receiving these updates will not be supported.</p>
<p>In order to support a device, the appropriate resources also need to be available
and dedicated towards it. Releases for each supported device need to be robust and
stable, with all standard functionality working properly and testing for each of the
releases.</p>
<p>Hardware, firmware and software specific to devices like drivers play a huge role
in the overall security of a device. The goal of the project is not to slightly
improve some aspects of insecure devices and supporting a broad set of devices would
be directly counter to the values of the project. A lot of the low-level work also
ends up being fairly tied to the hardware.</p>
<h3 id="when-devices">
<a href="#when-devices">When will more devices be supported?</a>
</h3>
<p>Broader device support can only happen after the community (companies,
organizations and individuals) steps up to make substantial, ongoing contributions to
making the existing device support sustainable. Once the existing device support is
more sustainable, early research and development work for other devices can begin.
Once a device is deemed to be a worthwhile target, the project needs maintainers to
develop and maintain support for it including addressing device-specific issues that
are uncovered, which will include issues uncovered in the device support code by
GrapheneOS hardening features.</p>
<p>It's not really a matter of time but rather a need for community support for the
project increasing. As an open source project, the way to get something to happen in
GrapheneOS is to contribute to it, and this is particularly true for device support
since it's very self-contained and can be delegated to separate teams for each
device. If you want to see more devices supported sooner, you should get to work on
identifying good devices with full support for alternative operating systems with
verified boot, etc. and then start working on integrating and testing support.</p>
<p>It should also be clear that the expectation is for people to buy a device to run
GrapheneOS, rather than GrapheneOS supporting their existing devices. This will only
become more true if GrapheneOS is successful enough to accomplish the goal of having
devices produced based on an SoC reference design with minor improvements for privacy
and security. Broad device support is the opposite of what the project wants to
achieve in the long term.</p>
<h3 id="legacy-devices">
<a href="#legacy-devices">Why are older devices no longer supported?</a>
</h3>
<p>GrapheneOS aims to provide reasonably private and secure devices. It cannot do that
once device support code like firmware, kernel and vendor code is no longer actively
maintained. Even if the community was prepared to take over maintainance of the open
source code and to replace the rest, firmware would present a major issue, and the
community has never been active or interested enough in in device support to consider
attempting this. Unlike many other platforms, GrapheneOS has a much higher minimum
standard than simply having devices fully functional, as they also need to provide the
expected level of security. It would start to become realistic to provide
substantially longer device support once GrapheneOS controls the hardware and firmware
via custom hardware manufactured for it. Until then, the lifetime of devices will
remain based on manufacturer support. It's also important to keep in mind that phone
vendors claiming to provide longer support often aren't actually doing it and some
never even ship firmware updates when the hardware is still supported by the
vendors...</p>
<p>GrapheneOS also has high standards for the privacy and security properties of the
hardware and firmware, and these standards are regularly advancing. The rapid pace of
improvement has been slowing down, but each hardware generation still brings major
improvements. Over time, the older hardware starts to become a substantial liability
and holds back the project. It becomes complex to simply make statements about the
security of the project when exceptions for old devices need to be listed out. The
project ends up wanting to drop devices for this reason but has always kept them going
until the end-of-life date to provide more time for people to migrate.</p>
<h2 id="security-and-privacy">
<a href="#security-and-privacy">Security and privacy</a>
</h2>
<h3 id="hardware-identifiers">
<a href="#hardware-identifiers">Can apps access hardware identifiers?</a>
</h3>
<p>As of Android 10, apps cannot obtain permission to access non-resettable hardware
identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial
numbers and subscriber IDs. Only privileged apps included in the base system with
<code>READ_PRIVILEGED_PHONE_STATE</code> whitelisted can access these hardware
identifiers. Apps targeting Android 10 will receive a <code>SecurityException</code>
and older apps will receive an empty value for compatibility.</p>
<p>GrapheneOS only makes a small change to remove a legacy form of access to the
serial number by legacy apps, which was still around for compatibility.</p>
<h3 id="default-connections">
<a href="#default-connections">What kind of connections do the OS and bundled apps
make by default?</a>
</h3>
<p>GrapheneOS makes connections to the outside world to test connectivity, detect
captive portals and download updates. No data varying per user / installation is sent
in these connections. There aren't analytics / telemetry in GrapheneOS.</p>
<p>The expected default connections by GrapheneOS (including all base system apps) are
the following:</p>
<ul>
<li>
<p>The GrapheneOS Updater app fetches update metadata from
https://releases.grapheneos.org/DEVICE-CHANNEL approximately once every four hours
when connected to a permitted network for updates.</p>
<p>Once an update is available, it tries to download
https://releases.grapheneos.org/DEVICE-incremental-OLD_VERSION-NEW_VERSION.zip
for a delta update, and then falls back to
https://releases.grapheneos.org/DEVICE-ota_update-NEW_VERSION.zip.</p>
<p>No query / data is sent to the server, so the only information leaked to it
are the variables in these 3 URLs (device, channel, current version) which is
necessary to obtain the update.</p>
<p>Users can control which types of connections the Updater app will use, and
although it's strongly recommended to always leave it enabled it can be
disabled.</p>
</li>
<li>
<p>An HTTPS connection is made to https://time.grapheneos.org/ to update the
time from the date header field. This is a full replacement of Android's
standard network time update implementation, which uses the cellular network
when available with a fallback to SNTP when it's not available. This can be
disabled with the toggle at Settings ➔ System ➔ Date & time ➔ Use
network-provided time. The time zone is still obtained directly via the time
zone provided by the mobile network when available.</p>
</li>
<li>
<p>On devices with a Qualcomm baseband (which provides GPS), when location
functionality is being used,
<a href="https://en.wikipedia.org/wiki/GPS_signals#Almanac">GPS almanacs</a>
are downloaded from https://xtrapath1.izatcloud.net/xtra3grc.bin,
https://xtrapath2.izatcloud.net/xtra3grc.bin or
https://xtrapath3.izatcloud.net/xtra3grc.bin. GrapheneOS has modified all
references to these servers to use HTTPS rather than a mix of HTTP and HTTPS.
No query / data is sent to the server.</p>
</li>
<li>
<p>Connectivity checks designed to mimic a web browser user agent are performed
by using HTTP and HTTPS to fetch standard URLs generating an HTTP 204 status
code. This is used to detect when internet connectivity is lost on a network,
which triggers fallback to other available networks if possible. These checks
are designed to detect and handle captive portals which substitute the
expected empty 204 response with their own web page. These need use a very
common domain and URL in order to bypass whitelisting systems only permitting
access to common domains / URLs so a domain like grapheneos.org would likely
be inadequate. GrapheneOS leaves these set to the standard four URLs to blend
into the crowd of billions of other Android devices with and without Google
Mobile Services performing the same empty GET requests. For privacy reasons,
it isn't desirable to stand out from the crowd and changing these URLs or even
disabling the feature will likely reduce your privacy by giving your device a
more unique fingerprint. GrapheneOS aims to appear like any other common
mobile device on the network.</p>
<ul>
<li>HTTPS: https://www.google.com/generate_204</li>
<li>HTTP: http://connectivitycheck.gstatic.com/generate_204</li>
<li>HTTP fallback: http://www.google.com/gen_204</li>
<li>HTTP other fallback: http://play.googleapis.com/generate_204</li>
</ul>
<p>Standard AOSP user agent for the GET request:</p>
<p>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36</p>
<p>No query / data is sent to the servers and the response is unused beyond
checking the response code.</p>
<p>Similar connectivity checks are also performed by Vanadium.</p>
</li>
<li>
<p>DNS connectivity and functionality tests</p>
</li>
<li>
<p>DNS resolution for other connections</p>
</li>
</ul>
<h3 id="cellular-tracking">
<a href="#cellular-tracking">What does GrapheneOS do about cellular tracking and
silent SMS?</a>
</h3>
<p>GrapheneOS always considers the network to be hostile and does not implement weak
or useless mitigations. Therefore, it does not have the assorted gimmicks seen elsewhere
providing privacy/security theatre to make users feel better about these issues. One
of the core tenets of GrapheneOS is being honest with users and avoiding scams/frills
based around marketing rather than real world privacy/security threat models.</p>
<p>Activating airplane mode will fully disable the cellular radio transmit and receive
capabilities, which will prevent your phone from being reached from the cellular
network and stop your carrier (and anyone impersonating them to you) from tracking the
device via the cellular radio. The baseband implements other functionality such as
Wi-Fi and GPS functionality, but each of these components is separately sandboxed on
the baseband and independent of each other. Enabling airplane mode disables the
cellular radio, but Wi-Fi can be re-enabled and used without activating the cellular
radio again. This allows using the device as a Wi-Fi only device.</p>
<p>Even if interception of the connection or some other man-in-the-middle attack along
the network is not currently occurring, the network is still untrustworthy and
information should not be sent unencrypted. Legacy calls and texts should be avoided
as they're not secure and trust the carrier / network along with having weak security
against other parties. Trying to detect some forms of interception rather than dealing
with the root of the problem (unencrypted communications / data transfer) would be
foolish and doomed to failure.</p>
<p>Receiving a silent SMS is not a good indicator of being targeted by your cell
carrier, police or government because <em>anyone on the cell network can send
them</em> including yourself. Cellular triangulation will happen regardless of whether
or not SMS texts are being sent or received by the phone. Even if an SMS did serve a
useful purpose for tracking, a silent SMS would be little different than receiving
unsolicited spam. In fact, sending spam would be stealthier since it wouldn't trigger
alerts for silent SMS but rather would be ignored with the rest of the spam. Regardless,
sending texts or other data is not required or particularly useful to track devices
connected to a network for an adversary with the appropriate access.</p>
</div>
<footer>
<a href="/"><img src="https://grapheneos.org/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>
<ul id="social">
<li><a href="https://twitter.com/GrapheneOS">Twitter</a></li>
<li><a href="https://github.com/GrapheneOS">GitHub</a></li>
<li><a href="https://reddit.com/r/GrapheneOS">Reddit</a></li>
</ul>
</footer>
</body>
</html>
|
