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
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
|
<!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?16"/>
<link rel="manifest" href="/manifest.webmanifest"/>
<link rel="canonical" href="https://grapheneos.org/faq"/>
<script type="module" src="/redirect.js?6"></script>
</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>
<p>This page contains answers to frequently asked questions about GrapheneOS. It's not
an overview of the project or a list of interesting topics about GrapheneOS. Many of
the answers would be nearly the same or identical for the latest release of the
Android Open Source Project. The goal is to provide high quality answers to some of
the most common questions about the project, so the developers and other community
members can link to these and save lots of time while also providing higher quality
answers.</p>
<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="#cellular-tracking">What does GrapheneOS do about cellular
tracking and silent SMS?</a></li>
<li><a href="#default-connections">Which connections do the OS and
bundled apps make by default?</a></li>
<li><a href="#default-dns">Which DNS servers are used by default?</a></li>
<li><a href="#custom-dns">How do I use a custom DNS server?</a></li>
<li><a href="#private-dns-ip">Why does Private DNS not accept IP
addresses?</a></li>
<li><a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect
other connections?</a></li>
<li><a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide
which sites are visited, etc.?</a></li>
<li><a href="#vpn-support">What kind of VPN and Tor support is available?</a></li>
<li><a href="#network-monitoring">Can apps monitor network connections or
statistics?</a></li>
<li><a href="#firewall">Does GrapheneOS provide a firewall?</a></li>
<li><a href="#ad-blocking">How can I set up system-wide ad-blocking?</a></li>
<li><a href="#ad-blocking-apps">Are ad-blocking apps supported?</a></li>
</ul>
</li>
<li>
<a href="#day-to-day-use">Day to day use</a>
<ul>
<li><a href="#updates">How do I keep the OS updated?</a></li>
<li><a href="#updates-sideloading">How do I update without giving the
device internet access?</a></li>
</ul>
</li>
<li><a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a></li>
<li><a href="#bundled-apps">Why aren't my favorite apps bundled with GrapheneOS?</a></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 (legacy), Pixel 2 XL
(legacy), 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>Since these restrictions became standard, 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="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>
<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="default-dns">
<a href="#default-dns">Which DNS servers are used by default?</a>
</h3>
<p>By default, the OS uses the network-provided DNS servers, whether those come from
DHCP or static network configuration. If no DNS servers are provided, GrapheneOS uses
<a href="https://developers.cloudflare.com/1.1.1.1/what-is-1.1.1.1/">Cloudflare DNS</a>
as the fallback rather than Google Public DNS. In practice, the fallback is rarely
used and has little real world impact.</p>
<h3 id="custom-dns">
<a href="#custom-dns">How do I use a custom DNS server?</a>
</h3>
<p>It isn't possible to directly override the DNS servers provided by the network via
DHCP. Instead, use the Private DNS feature in Settings ➔ Network & internet ➔
Advanced ➔ Private DNS to set the hostname of a DNS-over-TLS server. It needs to have
a valid certificate such as a free certificate from Let's Encrypt. The OS will look up
the Private DNS hostname via the network provided DNS servers and will then force all
other DNS requests through the Private DNS server. Unlike an option to override the
network-provided DNS servers, this prevents the network from monitoring or tampering
with DNS requests/responses.</p>
<p>As an example, set the hostname to <code>one.one.one.one</code> for Cloudflare DNS.
There are various other mainstream DNS-over-TLS options available including Quad9,
Google and AdGuard.</p>
<p>Configuring a static IP address for a network requires entering DNS servers
manually, but you should still use the Private DNS feature with it, and you shouldn't
misuse the static IP address option just to override the DNS servers.</p>
<p>VPN service apps can also provide their own DNS implementation and/or servers,
including an alternate implementation of encrypted DNS. Private DNS takes precedence
over VPN-provided DNS and using Private DNS is still recommended with a VPN.</p>
<h3 id="private-dns-ip">
<a href="#private-dns-ip">Why does Private DNS not accept IP addresses?</a>
</h3>
<p>By default, in the automatic mode, the Private DNS feature provides opportunistic
encryption by using DNS-over-TLS when supported by the DNS server IP addresses
provided by the network (DHCP) or the static IP configuration. Opportunistic
encryption provides protection against a passive listener, not an active attacker,
since they can force falling back to unencrypted DNS by blocking DNS-over-TLS. In the
automatic mode, certificate validation is not enforced, as it would provide no
additional security and would reduce the availability of opportunistic encryption.</p>
<p>When Private DNS is explicitly enabled, it uses authenticated encryption without a
fallback. The authentication is performed based on the hostname of the server, so it
isn't possible to provide an IP address. The OS will look up the hostname of the Private
DNS server via unencrypted DNS and then force all other DNS lookups via DNS-over-TLS
with the identity of the server authenticated as part of providing authenticated
encryption.</p>
<h3 id="private-dns-other">
<a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect other connections?</a>
</h3>
<p>No, it only provides privacy for DNS resolution. Even authenticating DNS results
with DNSSEC does not protect other connections, unless the DNS records are part of the
system used to provide authenticated encryption, and DNS-over-TLS is not a substitute
for DNSSEC. If connections have authenticated encryption, they're secure even if DNS
resolution is hijacked by an attacker. If connections do not have authenticated
encryption, an attacker can listen in and tamper with them without hijacking DNS.
There are other ways to perform a MITM attack than DNS hijacking and internet routing
is fundamentally insecure. DNS-over-TLS may make a MITM harder for some attackers, but
don't count on it at all.</p>
<h3 id="private-dns-visited">
<a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide which sites are visited, etc.?</a>
</h3>
<p>Private DNS only encrypts DNS, and an adversary monitoring connections can still
see the IP address at the other end of those connections. Many domains resolve to
ambiguous IP addresses, so encrypted DNS is part of what's required to take away a lot
of the information leaked to adversaries. However, TLS currently leaks domains via
SNI, so encrypted DNS is not yet accomplishing much. It's a forward looking feature
that will become more useful in the future. Using it is recommended, but it's not an
alternative to using Tor or a VPN.</p>
<h3 id="vpn-support">
<a href="#vpn-support">What kind of VPN and Tor support is available?</a>
</h3>
<p>VPNs can be configured under Settings ➔ Network & Internet ➔ Advanced ➔ VPN.
Support for the following protocols is included: PPTP (insecure, obsolete), L2TP/IPSec
PSK, L2TP/IPSec RSA, IPSec Xauth PSK, IPSec Xauth RSA and IPSec Hybrid RSA. Apps can
also provide userspace VPN implementations and the following open source apps are
recommended: Orbot (Tor), WireGuard, OpenVPN for Android and the Private Internet
Access client (OpenVPN).</p>
<p>VPN configurations created with the built-in support can be set as the always-on
VPN in the configuration panel. This will keep the VPN running, reconnecting as
necessary and will force all connections through them. An app providing a VPN service
can also be set as the always-on VPN via the entry in the Settings page. For app-based
VPN implementations, there's also an additional "Block connections without VPN" toggle
which is needed to prevent leaks when the app's VPN service isn't running.</p>
<h3 id="network-monitoring">
<a href="#network-monitoring">Can apps monitor network connections or statistics?</a>
</h3>
<p>Apps cannot monitor network connections unless they're made into the active VPN
service by the user. Apps cannot normally access network stats and cannot directly
request access to them. However, app-based stats can be explicitly granted by users as
part of access to app usage stats in Settings ➔ Apps & notifications ➔ Special app
access ➔ Usage access.</p>
<p>This was previously part of the GrapheneOS privacy improvements, but became a
standard Android feature with Android 10.</p>
<h3 id="firewall">
<a href="#firewall">Does GrapheneOS provide a firewall?</a>
</h3>
<p>Yes, GrapheneOS inherits the deeply integrated firewall from the Android Open
Source Project, which is used to implement portions of the security model and various
other features. The GrapheneOS project historically made various improvements to the
firewall but over time most of these changes were been integrated upstream or became
irrelevant.</p>
<p>GrapheneOS adds a user-facing Network permission toggle providing a robust way to
deny both direct and indirect network access to applications. It builds upon the
standard non-user-facing INTERNET permission, so it's already fully adopted by the app
ecosystem. Revoking the permission denies indirect access via OS components and apps
enforcing the INTERNET permission, such as DownloadManager. Direct access is denied
by blocking low-level network socket access.</p>
<h3 id="ad-blocking">
<a href="#ad-blocking">How can I set up system-wide ad-blocking?</a>
</h3>
<p>The recommended approach to system-wide ad-blocking is setting up domain-based
ad-blocking as part of DNS resolution. You can do this by
<a href="#custom-dns">choosing a Private DNS (DNS-over-TLS) server</a> with support
for blocking ad domains. As an example, AdGuard DNS can be used by setting
<code>dns.adguard.com</code> as the Private DNS domain. In the future, GrapheneOS
plans on adding back <a
href="https://github.com/GrapheneOS/os_issue_tracker/issues/184">an efficient
user-defined blacklist for the local DNS resolver</a>. This feature used to be
included by the project many years ago, but it needs to be reimplemented, and it's a
low priority feature depending on contributors stepping up to work on it.</p>
<h3 id="ad-blocking-apps">
<a href="#ad-blocking-apps">Are ad-blocking apps supported?</a>
</h3>
<p>Content filtering apps are fully compatible with GrapheneOS, but they have serious
drawbacks and are not recommended. These apps use the VPN service feature to route
traffic through themselves to perform filtering.</p>
<p>The approach of intercepting traffic is inherently incompatible with encryption
from the client to the server. The AdGuard app works around encryption by supporting
optional
<a href="https://kb.adguard.com/en/general/https-filtering">HTTPS interception</a> by
having the user trust a local certificate authority, which is a security risk and
weakens HTTPS security even if their implementation is flawless (which they openly
acknowledge in their documentation, although it understates the risks). It also can't
intercept connections using certificate pinning, with the exception of browsers which
go out of the way to allow overriding pinning with locally added certificate
authorities. Many of these apps only provide domain-based filtering, unlike the deeper
filtering by AdGuard, but they're still impacted by encryption due to Private DNS
(DNS-over-TLS) and require disabling the feature. They could provide their own
DNS-over-TLS resolver to avoid losing the feature, but few of the developers care
enough to do that.</p>
<p>Using the VPN service to provide something other than a VPN also means that these
apps need to provide an actual VPN implementation or a way to forward to apps
providing one, and very few have bothered to implement this. NetGuard is an one
example implementing SOCKS5 forwarding, which can be used to forward to apps like
Orbot (Tor).</p>
<h2 id="day-to-day-use">
<a href="#day-to-day-use">Day to day use</a>
</h2>
<h3 id="updates">
<a href="#updates">How do I keep the OS updated?</a>
</h3>
<p>GrapheneOS has entirely automatic background updates. More details are available in
the <a href="/usage#updates">the usage guide's updates section</a>.</p>
<h3 id="updates-sideloading">
<a href="#updates-sideloading">How do I update without giving the device internet
access?</a>
</h3>
<p>Updates can be <a href="/usage#updates-sideloading">sideloaded via
recovery</a>.</p>
<h2 id="anti-theft">
<a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a>
</h2>
<p>No, since this is strictly a theft deterrence feature, not a security feature, and
the standard implementation depends on having the device tied to an account on an
online service. The only advantage would be encouraging thieves to return a stolen
device for a potential reward after realizing that it has no value beyond scrapping it
for parts.</p>
<p>Google's Factory Reset Protection ties devices to a Google account using a tiny,
special region of persistent state not wiped by a factory reset. It prevents a thief
from wiping the device to a fresh state for resale without being stuck at a screen for
authenticating with the Google account persisted on the device after wiping.</p>
<p>It would be possible to make an implementation not reliant upon an online service
where the user has the option to enable Factory Reset Protection and is given a seed
phrase required to use the device after wiping data from recovery. However, since this
has no security value and the ability to deter theft is questionable, implementing
this is an extremely low priority.</p>
<p>Providing the option to disable wiping from recovery would be simpler, but would be
incompatible with features designed to wipe data automatically in certain cases. This
will not be implemented by GrapheneOS since it isn't a good approach and it conflicts
with other planned features.</p>
<h2 id="bundled-apps">
<a href="#bundled-apps">Why aren't my favorite apps bundled with GrapheneOS?</a>
</h2>
<p>There are drawbacks to bundling apps into the OS and few advantages in most cases.
Rather than GrapheneOS bundling a bunch of apps, it makes far more sense for users to
install their preferred apps via F-Droid, Aurora Store or other sources. GrapheneOS is
also working on designing and implementing a first party app update system for a first
party repository with higher robustness and security than the existing options. Rather
than bundling apps, it could just offer recommendations as part of an initial setup
wizard. Users have unique needs and preferences and there has to be a very compelling
reason to bundle additional apps with the OS. For example, it's useful to have the
Auditor app available before connecting to the internet (see the
<a href="/install#verifying-installation">installation guide</a> documentation on
this).</p>
<p>Bundling additional apps with the OS can increase attack surface, unless users go
out of the way to disable apps they aren't using. Bundling an app into the base OS is
also painful to reverse, since removing the app without implementing a migration
mechanism will lose user data stored in the app. Some users are also going to take
issue with the choices made by the project or will want to make suggestions for
bundling more apps, and having this as a regular topic of discussion and debate is
unproductive and distracts from the real work of the project. Each bundled app also
increases the size of the base OS, and shipping the app updates as part of the OS
updates results in more overall bandwidth usage. It would be possible to ship only
out-of-band app updates to avoid wasted bandwidth for apps users have disabled, but
then the apps would be temporarily out-of-date and vulnerable to patched security
issues after a factory reset or the user re-enabling them. If the updates aren't going
to be shipped with the OS, it really makes no sense to bundle them.</p>
<p>GrapheneOS is focused on making meaningful improvements to privacy and security,
and bundling assorted apps into the OS is not only usually outside of that focus but
often counter to it.</p>
</div>
<footer>
<a href="/"><img src="/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>
|
