forked from GrapheneOS/grapheneos.org
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfaq.html
1965 lines (1721 loc) · 140 KB
/
faq.html
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
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en" prefix="og: https://ogp.me/ns#">
<head>
<meta charset="utf-8"/>
<title>Frequently Asked Questions | GrapheneOS</title>
<meta name="description" content="Answers to frequently asked questions about GrapheneOS."/>
<meta name="theme-color" content="#212121"/>
<meta name="color-scheme" content="dark light"/>
<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 Frequently Asked Questions"/>
<meta property="og:description" content="Answers to 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:site_name" content="GrapheneOS"/>
<meta property="og:url" content="https://grapheneos.org/faq"/>
<link rel="canonical" href="https://grapheneos.org/faq"/>
<link rel="icon" href="/favicon.ico"/>
<link rel="icon" sizes="any" type="image/svg+xml" href="/favicon.svg"/>
<link rel="mask-icon" href="[[path|/mask-icon.svg]]" color="#1a1a1a"/>
<link rel="apple-touch-icon" href="/apple-touch-icon.png"/>
[[css|/main.css]]
<link rel="manifest" href="/manifest.webmanifest"/>
<link rel="license" href="/LICENSE.txt"/>
<link rel="me" href="https://grapheneos.social/@GrapheneOS"/>
[[js|/js/redirect.js]]
</head>
<body>
{% with current_page="faq" %}
{% include "header.html" %}
{% endwith %}
<main id="faq">
<h1><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>
<nav id="table-of-contents">
<h2><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>
<li><a href="#which-legacy-devices">Which devices did GrapheneOS support in the past?</a></li>
<li><a href="#device-lifetime">How long will GrapheneOS support my device for?</a></li>
</ul>
</li>
<li>
<a href="#security-and-privacy">Security and privacy</a>
<ul>
<li><a href="#encryption">How is disk encryption implemented?</a></li>
<li><a href="#clipboard">Can apps spy on the clipboard in the background
or inject content into it?</a></li>
<li><a href="#hardware-identifiers">Can apps access hardware
identifiers?</a></li>
<li><a href="#non-hardware-identifiers">What about non-hardware identifiers?</a></li>
<li><a href="#cellular-tracking">What does GrapheneOS do about cellular tracking,
interception and silent SMS?</a></li>
<li><a href="#wifi-privacy">How private is Wi-Fi?</a></li>
<li><a href="#default-connections">Which connections do the OS and
bundled apps make by default?</a></li>
<li><a href="#other-connections">Which additional connections can the
OS make with a non-default configuration?</a></li>
<li><a href="#privacy-policy">What is the privacy policy for GrapheneOS services?</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>
<li><a href="#baseband-isolation">Is the baseband isolated?</a></li>
<li><a href="#bootloader-locking-setup">Why am I seeing a message about my bootloader not being locked when setting up the device?</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 connecting the
device to the internet?</a></li>
<li><a href="#notifications">Do notifications properly work on GrapheneOS?</a></li>
<li><a href="#file-transfer">How do I transfer files to another device?</a></li>
</ul>
</li>
<li><a href="#google-services">Will GrapheneOS include support for Google services?</a></li>
<li><a href="#features">What features does GrapheneOS implement?</a></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>
<li><a href="#roadmap">What is the roadmap for GrapheneOS?</a></li>
<li><a href="#install">How do I install GrapheneOS?</a></li>
<li><a href="#build">How do I build GrapheneOS?</a></li>
<li><a href="#donate">How can I donate to GrapheneOS?</a></li>
<li><a href="#upstream">Does GrapheneOS make upstream contributions?</a></li>
<li><a href="#audit">Is GrapheneOS audited?</a></li>
<li><a href="#founding">When was the GrapheneOS project founded?</a></li>
<li><a href="#copperheados">How is CopperheadOS related to GrapheneOS?</a></li>
<li><a href="#company">Will GrapheneOS create a company?</a></li>
<li><a href="#copyright-and-licensing">Who owns the GrapheneOS code and how is it licensed?</a></li>
<li><a href="#trademark">What about the GrapheneOS name and logo?</a></li>
</ul>
</nav>
<section id="device-support">
<h2><a href="#device-support">Device support</a></h2>
<article id="supported-devices">
<h3><a href="#supported-devices">Which devices are supported?</a></h3>
<p>GrapheneOS has official production support for the following devices:</p>
<ul>
<li>Pixel 8 Pro (husky)</li>
<li>Pixel 8 (shiba)</li>
<li>Pixel Fold (felix)</li>
<li>Pixel Tablet (tangorpro)</li>
<li>Pixel 7a (lynx)</li>
<li>Pixel 7 Pro (cheetah)</li>
<li>Pixel 7 (panther)</li>
<li>Pixel 6a (bluejay)</li>
<li>Pixel 6 Pro (raven)</li>
<li>Pixel 6 (oriole)</li>
<li>Pixel 5a (barbet)</li>
</ul>
<p>The following devices are end-of-life, no longer receive firmware or most
driver security updates and receive extended support from GrapheneOS as part
of the main releases with all GrapheneOS changes including all of the latest
Android Open Source Project changes:</p>
<ul>
<li>Pixel 5 (redfin)</li>
<li>Pixel 4a (5G) (bramble)</li>
</ul>
<p>The following devices are end-of-life, no longer receive firmware or driver
security updates and receive extended support from GrapheneOS via a legacy
branch based on Android 13 with only the Android Open Source Project security
backports, certain other security patches and other minimal changes to keep
them working:</p>
<ul>
<li>Pixel 4a (sunfish)</li>
<li>Pixel 4 XL (coral)</li>
<li>Pixel 4 (flame)</li>
</ul>
<p>We provide extended support releases as a stopgap for users to transition
to the far more secure current generation devices.</p>
<p>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 does not support being used as a Generic System Image, which
only exists for development/testing purposes and isn't usable for GrapheneOS
since we require kernel changes and the userspace part of the OS cannot run on
top of a kernel without the required functionality. 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">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>
</article>
<article id="recommended-devices">
<h3><a href="#recommended-devices">Which devices are recommended?</a></h3>
<p>We <strong>strongly recommend</strong> only purchasing one of the following
devices for GrapheneOS due to better security and a long minimum support
guarantee from launch for full security updates and other improvements:</p>
<ul>
<li><strong>Pixel 8 Pro</strong> — minimum 7 years support and hardware memory tagging support</li>
<li><strong>Pixel 8</strong> — minimum 7 years support and hardware memory tagging support</li>
<li>Pixel Fold</li>
<li>Pixel Tablet</li>
<li>Pixel 7a</li>
<li>Pixel 7 Pro</li>
<li>Pixel 7</li>
<li>Pixel 6a</li>
<li>Pixel 6 Pro</li>
<li>Pixel 6</li>
</ul>
<p>8th generation Pixels provide a minimum guarantee of 7 years of support
from launch instead of the previous 5 year minimum guarantee. 8th generation
Pixels also bring support for the incredibly powerful hardware memory tagging
security feature as part of moving to new ARMv9 CPU cores. GrapheneOS uses
hardware memory tagging by default to protect the base OS and known compatible
user installed apps against exploitation, with the option to use it for all
apps and opt-out on a case-by-case basis for the few incompatible with it.</p>
<p>Both 7th and 6th generation Pixels have a minimum guarantee of 5 years from
launch. 7th generation Pixels are a year newer so they have an extra year of
their guarantee remaining.</p>
<p>The Pixel 7 and Pixel 7 Pro are all around improvements over the Pixel 6
and Pixel 6 Pro with a significantly better GPU and cellular radio along with
an incremental CPU upgrade. The 7th generation Pixels are far more similar to
the previous generation than any prior Pixels.</p>
<p>Pixel 7a is nearly the same as the Pixel 7 other than having slow wireless
charging and weaker dust/water protection. Pixel 7a offers the best value when
buying a new device.</p>
<p>The Pixel Tablet is a tablet variant of the 7th generation devices and the
Pixel Fold is a hybrid phone/tablet. These share the same SoC and are nearly
the same as the other 7th generation devices under the hood.</p>
<p>Pixel 6, Pixel 6 Pro and Pixel 6a can still be worth buying if you can get
a good deal due to the long support time. They still have around 3 years of
their minimum support guarantee remaining.</p>
</article>
<article id="future-devices">
<h3><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>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>
<p>Non-exhaustive list of requirements for future devices, which are standards
met or exceeded by current Pixel devices:</p>
<ul>
<li>Support for using alternate operating systems including full hardware
security functionality</li>
<li>Complete monthly Android Security Bulletin patches without any regular
delays longer than a week</li>
<li>At least 5 years of updates from launch for phones (Pixels now have 7)
and 7 years for tablets</li>
<li>Vendor code updated to new monthly, quarterly and yearly releases of
AOSP within several months to provide new security improvements (Pixels
receive these in the month they're released)</li>
<li>Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support</li>
<li>Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM
to match Pixels but another usable implementation may be acceptable)</li>
<li>Hardware memory tagging (ARM MTE or equivalent)</li>
<li>BTI/PAC, CET or equivalent</li>
<li>PXN, SMEP or equivalent</li>
<li>PAN, SMAP or equivalent</li>
<li>Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD,
media encode / decode, image processor and other components</li>
<li>Support for A/B updates of both the firmware and OS images with
automatic rollback if the initial boot fails one or more times</li>
<li>Verified boot with rollback protection for firmware</li>
<li>Verified boot with rollback protection for the OS (Android Verified
Boot)</li>
<li>Verified boot key fingerprint for yellow boot state displayed with a
secure hash (non-truncated SHA-256 or better)</li>
<li>StrongBox keystore provided by secure element</li>
<li>Hardware key attestation support for the StrongBox keystore</li>
<li>Attest key support for hardware key attestation to provide pinning
support</li>
<li>Weaver disk encryption key derivation throttling provided by secure
element</li>
<li>Insider attack resistance for updates to the secure element (Owner
user authentication required before updates are accepted)</li>
<li>Inline disk encryption acceleration with wrapped key support</li>
<li>64-bit-only device support code</li>
<li>Wi-Fi anonymity support including MAC address randomization, probe
sequence number randomization and no other leaked identifiers</li>
<li>Support for disabling USB data and also USB as a whole at a hardware
level in the USB controller</li>
</ul>
<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>
</article>
<article id="when-devices">
<h3><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>
</article>
<article id="legacy-devices">
<h3><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 maintenance 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 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>
</article>
<article id="which-legacy-devices">
<h3><a href="#which-legacy-devices">Which devices did GrapheneOS support in the past?</a></h3>
<p>The following devices are no longer supported:</p>
<ul>
<li>Pixel 3a XL (bonito)</li>
<li>Pixel 3a (sargo)</li>
<li>Pixel 3 XL (crosshatch)</li>
<li>Pixel 3 (blueline)</li>
<li>Pixel 2 XL (taimen)</li>
<li>Pixel 2 (walleye)</li>
<li>Pixel XL (marlin)</li>
<li>Pixel (sailfish)</li>
<li>Nexus 6P (angler)</li>
<li>Nexus 5X (bullhead)</li>
<li>Nexus 9 (flounder)</li>
<li>Nexus 5 (hammerhead)</li>
<li>Samsung Galaxy S4 (jflte)</li>
</ul>
<p>GrapheneOS also used to provide official support for the following
development boards (without publishing official builds) but dropped support
due to lack of community interest and lack of hardware availability:</p>
<ul>
<li>HiKey 960 (hikey960)</li>
<li>HiKey (hikey)</li>
</ul>
</article>
<article id="device-lifetime">
<h3><a href="#device-lifetime">How long can GrapheneOS support my device for?</a></h3>
<p>GrapheneOS can only fully provide security updates to a device provided
that the OEM is releasing them. When an OEM is no longer providing security
updates, GrapheneOS aims to provide harm reduction releases for devices which
only have a minimum of 3 years support. Extended support updates at minimum
will be done until the next Android version. It is likely that we will make a
decision around harm reduction releases for other devices with longer
lifetimes in Q4 2024. Harm reduction releases do not have complete security
patches because it's not possible to provide full security updates for the
device without OEM support and they are intended to buy users some limited
time to migrate to a supported device.</p>
<table>
<tr>
<th>Device</th>
<th>OEM minimum support end</th>
<th>OEM minimum support length</th>
</tr>
<tr>
<td>Google Pixel 8 Pro</td>
<td>October 2030</td>
<td>7 years</td>
</tr>
<tr>
<td>Google Pixel 8</td>
<td>October 2030</td>
<td>7 years</td>
</tr>
<tr>
<td>Google Pixel Fold</td>
<td>June 2028</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel Tablet</td>
<td>June 2028</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 7a</td>
<td>May 2028</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 7 Pro</td>
<td>October 2027</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 7</td>
<td>October 2027</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 6a</td>
<td>July 2027</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 6 Pro</td>
<td>October 2026</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 6</td>
<td>October 2026</td>
<td>5 years</td>
</tr>
<tr>
<td>Google Pixel 5a</td>
<td>August 2024</td>
<td>3 years</td>
</tr>
</table>
</article>
</section>
<section id="security-and-privacy">
<h2><a href="#security-and-privacy">Security and privacy</a></h2>
<article id="encryption">
<h3><a href="#encryption">How is disk encryption implemented?</a></h3>
<p>GrapheneOS uses an enhanced version of the modern filesystem-based disk
encryption implementation in the Android Open Source Project. The officially
supported devices have substantial hardware-based support for enhancing the
security of the encryption implementation. GrapheneOS has full support for the
hardware-based encryption features just as it does with other hardware-based
security features.</p>
<p>Firmware and OS partitions are identical copies of the images published in
the official releases. The authenticity and integrity of these partitions is
verified from a root of trust on every boot. No data is read from any of these
images without being cryptographically verified. Encryption is out of scope
due to the images being publicly available. Verified boot offers much stronger
security properties than disk encryption. Further details will be provided in
another section on verified boot in the future.</p>
<p>The data partition stores all of the persistent state for the operating
system. Full disk encryption is implemented via filesystem-based encryption
with metadata encryption. All data, file names and other metadata is always
stored encrypted. This is often referred to as file-based encryption but it
makes more sense to call it filesystem-based encryption. It's implemented by
the Linux kernel as part of the ext4 / f2fs implementation rather than running
a block-based encryption layer. The advantage of filesystem-based encryption
is the ability to use fine-grained keys rather than a single global key that's
always in memory once the device is booted.</p>
<p>Disk encryption keys are randomly generated with a high quality CSPRNG and
stored encrypted with a key encryption key. Key encryption keys are derived at
runtime and are never stored anywhere.</p>
<p>Sensitive data is stored in user profiles. User profiles each have their
own unique, randomly generated disk encryption key and their own unique key
encryption key is used to encrypt it. The owner profile is special and is used
to store sensitive system-wide operating system data. This is why the owner
profile needs to be logged in after a reboot before other user profiles can be
used. The owner profile does not have access to the data in other profiles.
Filesystem-based encryption is designed so that files can be deleted without
having the keys for their data and file names, which enables the owner profile
to delete other profiles without them being active.</p>
<p>GrapheneOS enables support for ending secondary user profile sessions after
logging into them. It adds an end session button to the lockscreen and in the
global action menu accessed by holding the power button. This fully purges the
encryption keys and puts the profiles back at rest. This can't be done for the
owner profile without rebooting due to it encrypting the sensitive system-wide
operating system data.</p>
<p>Using a secondary profile for regular usage allows you to make use of the
device without decrypting the data in your regular usage profile. It also
allows putting it at rest without rebooting the device. Even if you use the
same passphrase for multiple profiles, each of those profiles still ends up
with a unique key encryption key and a compromise of the OS while one of them
is active won't leak the passphrase. The advantage to using separate
passphrases is in case an attacker records you entering it.</p>
<p>File data is encrypted with AES-256-XTS and file names with AES-256-CTS. A
unique key is derived using HKDF-SHA512 for each regular file, directory and
symbolic link from the per-profile encryption keys, or the global encryption
key for non-sensitive data stored outside of profiles. The directory key is
used to encrypt the file names. GrapheneOS increases the file name padding
from 16 bytes to 32 bytes. AES-256-XTS with the global encryption key is also
used to encrypt filesystem metadata as a whole beyond the finer-grained file
name encryption.</p>
<p>The OS derives a password token from the profile's lock method credential
using scrypt. This is used as the main input for key derivation.</p>
<p>The OS stores a high entropy random value as the Weaver token on the secure
element (Titan M on Pixels) and uses it as another input for key derivation.
The Weaver token is stored alongside a Weaver key derived by the OS from the
password token. In order to retrieve the Weaver token, the secure element
requires the correct Weaver key. A secure internal timer is used to implement
hardware-based delays for each attempt at key derivation. It quickly ramps up
to 1 day delays before the next attempt. Weaver also provides reliable wiping
of data since the secure element can reliably wipe a Weaver slot. Deleting a
profile will wipe the corresponding Weaver slot and a factory reset of the
device wipes all of the Weaver slots. The secure element also provides insider
attack resistance preventing firmware updates before authenticating with the
owner profile.</p>
<p>Standard delays for encryption key derivation enforced by the secure
element:</p>
<ul>
<li>0 to 4 failed attempts: no delay</li>
<li>5 failed attempts: 30 second delay</li>
<li>6 to 9 failed attempts: no delay</li>
<li>10 to 29 failed attempts: 30 second delay</li>
<li>30 to 139 failed attempts: 30 × 2<sup>⌊(<var>n</var> - 30) ÷ 10⌋</sup>
where <var>n</var> is the number of failed attempts. This means the delay
doubles after every 10 attempts. There's a 30 second delay after 30 failed
attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s
after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after
120 and 30720s after 130</li>
<li>140 or more failed attempts: 86400 second delay (1 day)</li>
</ul>
<p>Invalid input outside the minimum or maximum length limits of the UI won't
trigger an attempt at authentication or key derivation.</p>
<p>GrapheneOS only officially supports devices with Weaver. The fallback
implementation for devices without it is out-of-scope for this FAQ.</p>
<p>The password token, Weaver token and other values like the OS verified boot
key are used by the TEE as inputs to a hardware-bound key derivation algorithm
provided by the SoC. The general concept is having the SoC perform hardware
accelerated key derivation using an algorithm like AES or HMAC keyed with a
hard-wired hardware key inaccessible to software or firmware. This is meant to
prevent offloading a brute force attack onto more powerful hardware without an
expensive process of extracting the hardware key from the SoC.</p>
<p>Many apps use the hardware keystore, their own encryption implementation or
a combination of those to provide an additional layer of encryption. As an
example, an app can use the hardware keystore to encrypt their data with a key
only available when the device is unlocked to keep their data at rest when the
profile is locked but not logged out. This is beyond the scope of this FAQ
section.</p>
</article>
<article id="clipboard">
<h3><a href="#clipboard">Can apps spy on the clipboard in the background or inject content into it?</a></h3>
<p>As of Android 10, only the configured default input method editor (your
keyboard of choice) and the currently focused app can read the clipboard
content. Apps without focus cannot read the clipboard. This is a stricter
restriction than preventing apps in the background from reading it, since an
app in the foreground or a foreground service cannot read it, only the
foreground app that's currently focused. Clipboard managers need to be
implemented by the keyboard chosen as the default by the user.</p>
<p>Both background and foreground apps can write data to the clipboard.</p>
<p>GrapheneOS previously restricted background clipboard access as a much earlier and
slightly less strict implementation of this feature. It provided a toggle for users to
whitelist clipboard managers, which is no longer needed now that keyboards are
expected to provide it.</p>
<p>As of Android 12, the user is notified when an app reads clipboard content
which was set by a different app. This notice is enabled by default and can be
toggled under <b>Settings <span aria-label="and then">></span>
Privacy <span aria-label="and then">></span> Show clipboard
access</b>.</p>
</article>
<article id="hardware-identifiers">
<h3><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. It used to need more extensive changes such as disallowing
access to the serial number but those restrictions are now standard.</p>
<p>Apps can determine the model of the device (such as it being a Pixel 6) either
directly or indirectly through the properties of the hardware and software. There
isn't a way to avoid this short of the OS supporting running apps in a virtual machine
with limited functionality and hardware acceleration. Hiding the CPU/SoC model would
require not even using basic hardware virtualization support and these things could
probably still be detected via performance measurements.</p>
</article>
<article id="non-hardware-identifiers">
<h3><a href="#non-hardware-identifiers">What about non-hardware identifiers?</a></h3>
<p>In addition to not having a way to identify the hardware, apps cannot directly
identify the installation of the OS on the hardware. Apps only have a small portion of
the OS configuration exposed to them and there is not much for device owners to change
which could identify their installation. Apps can detect that they're being run on
GrapheneOS via the privacy and security features placing further restrictions on them
and hardening them against further exploitation. Apps can identify their own app
installation via their app data and can directly (until that's removed) or indirectly
identify a profile. Profiles should be used when separate identities are desired.
Profiles can be used as temporary ephemeral identities by creating them for a specific
need and then deleting them. The rest of this answer only provides more technical
details, so you can stop reading here if you only want an overview and actionable
advice (i.e. use profiles as identities not inherently tied to each other).</p>
<p>Examples of the global OS configuration available to apps are time zone,
network country code and other similar global settings. Per-profile examples
are dark mode and language. Similar to extension and browser configuration /
state being fingerprinted by web sites, an app could use a combination of
these things in an attempt to identify the installation. All of these things
vary at runtime and can be changed, but some are fairly unlikely to change in
practice after the initial setup of the device such as the ones listed above.
GrapheneOS will likely add further restrictions in this area and a couple
toggles for certain cases like time zones to use a standard value instead.</p>
<p>Apps can generate their own 128-bit or larger random value and use that as an
identifier for the app installation. Apps can create data in their app-specific
external storage directory by default without needing permission, and in the legacy
storage model before API 29 that data persists after the app is uninstalled, so it can
be used to store an ID that persists through the app being uninstalled and
reinstalled. However, external storage is under control of the user and the user can
delete this data at any time, including after uninstalling the app. In the modern
storage model, this data is automatically removed when the app is uninstalled.
GrapheneOS includes Seedvault as an OS backup service which must be explicitly
enabled, and it has the option to automatically restore app data when an app is
reinstalled, so it wouldn't lose track of it being the same profile.</p>
<p>The <var>ANDROID_ID</var> string is a 64-bit random number, unique to each
combination of profile and app signing key. The 64-bit limitation means it isn't
particularly useful due to the possibility of collisions. It's tied to the lifetime of
profiles and does not persist through profile deletion or a factory reset. This is
comparable to an app targeting the legacy storage model storing a 64-bit random value
in the app-specific external storage directory. In the future, GrapheneOS will likely
change this to be tied to the lifetime of app installations rather than profiles. An
app could still track the identity of the profile through data you give it access to or
via data another app chooses to share with them.</p>
<p>The advertising ID is a Google Play services feature not included in the baseline
Android API, so it isn't an API included in GrapheneOS. The advertising ID is unique
to each profile. It isn't unique to each app signing key like <var>ANDROID_ID</var>,
but that makes little difference since apps within the same profile can communicate
with each other with mutual consent. It's comparable to <var>ANDROID_ID</var> but
provides an 128-bit value so it provides a strong cryptographic guarantee against
collisions, although a device messing with apps could set it to the same value used in
another profile. The advertising ID is exposed via the Settings app and can be reset
to a new random value, unlike <var>ANDROID_ID</var> which remains the same for the
lifetime of the profile, but apps can tie it to the previous ID since they can detect
that it changed via their own ID in their app data. The advertising ID can
also now be disabled (zeroed).</p>
<p>Apps do not have access to user data by default and cannot ever access the data of
other apps without those apps going out of the way to share it with them. If apps are
granted read access to user data like media or contacts, they could use it to identify
the profile. If apps are granted write access to user data, they could tag it to keep
track of the profile. Apps previously had little reason to do things like this because
they were able to persist data through an uninstall and reinstallation by default. The
modern storage model means they need to request access to user data to do this. The
existence of <var>ANDROID_ID</var> means they don't yet need to bother with that but
that will change on GrapheneOS and will likely change for baseline Android too.
However, profiles are the only way to provide a strong assurance of separate
identities since the application model of the OS is designed to support communication
between apps within the same profile, but never between them.</p>
</article>
<article id="cellular-tracking">
<h3><a href="#cellular-tracking">What does GrapheneOS do about cellular tracking, interception and silent SMS?</a></h3>
<p>GrapheneOS always considers networks to be hostile and avoids placing trust in
them. It leaves out various carrier apps included in the stock OS granting carriers
varying levels of administrative access beyond standard carrier configuration.
GrapheneOS also avoids trust in the cellular network in other ways including providing
a secure network time update implementation rather than trusting the cellular network
for this. Time is sensitive and can be used to bypass security checks depending on
certificate / key expiry.</p>
<p>Cellular networks use inherently insecure protocols and have many trusted parties.
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.</p>
<p>Authenticated transport encryption such as HTTPS for web sites avoids trusting the
cellular network. End-to-end encrypted protocols such as the Signal messaging protocol
also avoid trusting the servers. GrapheneOS uses authenticated encryption with modern
protocols, forward secrecy and strong cipher configurations for our services. We only
recommend apps taking a decent approach in this area.</p>
<p>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>GrapheneOS does not add gimmicks without a proper threat model and
rationale. We won't include flawed heuristics to guess when the cellular
network should be trusted. These kinds of features provide a false sense of
security and encourage unwarranted trust in cellular protocols and carrier
networks as the default. These also trigger false positives causing
unnecessary concern and panic. The correct approach is avoiding trusting the
network as explained above.</p>
<p>Connecting to your carrier's network inherently depends on you identifying yourself to
it and anyone able to obtain administrative access. 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>The <a href="/usage#lte-only-mode">LTE-only mode added by GrapheneOS is solely
intended for attack surface reduction</a>. It should not be mistaken as a way to make
the cellular network into something that can be trusted.</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>
<p>Airplane mode is the only way to avoid the cellular network tracking your
device and works correctly on the devices we support.</p>
</article>
<article id="wifi-privacy">
<h3><a href="#wifi-privacy">How private is Wi-Fi?</a></h3>
<p>See the <a href="/usage#wifi-privacy">usage guide section on Wi-Fi privacy</a>.</p>
</article>
<article id="default-connections">
<h3><a href="#default-connections">What kind of connections do the OS and bundled apps make by default?</a></h3>
<p>By default, GrapheneOS only makes remote connections to GrapheneOS services
and the network provided DNS resolvers. There aren't any analytics/telemetry
in GrapheneOS. The only information revealed to the GrapheneOS servers are the
generic device model (such as Pixel 7 Pro) and OS version which are necessary
for obtaining updates. The default connections provide the OS and apps with
updates, set the system clock, check each network connection for internet
connectivity, download a global database (does not vary based on location)
with predicted satellite locations when using Location and obtain attestation
chain signing keys for the hardware keystore needed for the hardware-based
attestation feature.</p>
<p>Make sure to read the <a href="#other-connections">other connections</a>
section below this one too which covers non-default connections triggered by
having a certain carrier, having apps installed, etc.</p>
<p>The expected default connections by GrapheneOS (including all base system apps) are
the following:</p>
<ul>
<li>
<p>The GrapheneOS System Updater app fetches update metadata from
https://releases.grapheneos.org/<var>DEVICE</var>-<var>CHANNEL</var> 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/<var>DEVICE</var>-incremental-<var>OLD_VERSION</var>-<var>NEW_VERSION</var>.zip
for a delta update, and then falls back to
https://releases.grapheneos.org/<var>DEVICE</var>-ota_update-<var>NEW_VERSION</var>.zip.</p>
<p>No query / data is sent to the server, so the only information given to it
are the variables in these 3 URLs (device, channel, current version) which is
necessary to obtain the update.</p>
<p>Users are in control of which types of networks the Updater app will use
and can disable the Updater app in extreme cases. It's strongly recommended to
leave it enabled to quickly receive security updates including updates outside
the regular monthly schedule.</p>
<p>The update client avoids trusting the data obtained from the update server
via signature verification with downgrade protection. Verified boot provides
another layer of signature verification with downgrade protection. GrapheneOS
servers do not have access to GrapheneOS signing keys.</p>
<p>See the <a href="/usage#updates">usage guide's section on updates</a> for
more information.</p>
</li>
<li>
<p>The GrapheneOS app repository client (Apps) fetches generic signed
update metadata and signed package updates (APKs) from
https://apps.grapheneos.org/ (a separate name for the same servers as
https://releases.grapheneos.org). It provides out-of-band updates to
certain apps bundled with the OS and other apps available in our
repository.</p>
</li>
<li>
<p>Vanadium, our browser and WebView implementation, uses
<code>update.vanadium.app</code> to check for updates to components
providing revoked certificates and other data. It downloads the
components from <code>dl.vanadium.app</code>.</p>
</li>
<li>
<p>An HTTPS connection is made to
https://time.grapheneos.org/generate_204 to update the time with a
millisecond precision X-Time header. As part of future support for
using other services, it falls back to the standard Date header with
second precision.</p>
<p>This is a full replacement for Android's standard network time
update implementation, which uses unauthentication SNTP (Simple
Network Time Protocol) with fallback to the cellular network when it's
not available (GNSS can also be used as a time source but is disabled
by default, and OEMs can choose the priority order). Network time
updates are security sensitive since certificate validation depends on
having an accurate time, but the standard NTP / SNTP protocols used
across most OSes have no authentication or encryption.</p>
<p>We plan to offer a toggle to use the standard functionality instead of
HTTPS-based time updates in order to blend in with other devices.</p>
<p>Network time can be disabled with the toggle at
<b>Settings <span aria-label="and then">></span>
System <span aria-label="and then">></span> Date &
time <span aria-label="and then">></span> Set time automatically</b>.
Unlike AOSP or the stock OS on the supported devices, GrapheneOS stops making
network time connections when using network time is disabled rather than just
not setting the clock based on it. The time zone is still obtained directly
via the time zone provided by the mobile network (NITZ) when available which
you can also disable by the <b>Set time zone automatically</b> toggle.</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.</p>
<p>The connectivity checks are done by performing an empty GET request to a
server returning an empty response with a 204 No Content response code. The
request uses a standard, frozen value for the user agent matching the same
value used by billions of other Android devices:</p>
<pre>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36</pre>
<p>No query / data is sent to the servers and the response is unused beyond
checking the response code.</p>
<p>Connectivity checks are performed for each network connection and
for VPN connections on top of those. This allows the OS to choose the
right underlying network for a VPN and to handle many types of captive
portals without the user turning off their VPN.</p>
<p>You can change the connectivity check URLs via the
<b>Settings <span aria-label="and then">></span> Network &
internet <span aria-label="and then">></span> Internet
connectivity check</b> setting. At the moment, it can be toggled between
the <b>GrapheneOS server</b> (default), the <b>Standard (Google) server</b>
used by billions of other Android devices or <b>Off</b>.</p>
<p>By default, the <b>GrapheneOS server</b> is used via the following
URLs:</p>
<ul>
<li>HTTPS: https://connectivitycheck.grapheneos.network/generate_204</li>
<li>HTTP: http://connectivitycheck.grapheneos.network/generate_204</li>
<li>HTTP fallback: http://grapheneos.online/gen_204</li>
<li>HTTP other fallback: http://grapheneos.online/generate_204</li>
</ul>
<p>Changing this to <b>Standard (Google) server</b> will use the same
URLs used by AOSP and the stock OS along with the vast majority of
other devices, blending in with billions of other Android devices both
with and without Play services:</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>GrapheneOS also adds the ability to fully turn <b>Off</b> the
connectivity checks. This results in the OS no longer handling captive
portals itself, not falling back to other networks when some don't
have internet access and not being able to delay scheduled jobs
depending on internet access until it becomes available.</p>
</li>
<li>
<p>HTTPS connections are made to fetch
<a href="https://en.wikipedia.org/wiki/GPS_signals#Almanac">PSDS
information</a> to assist with satellite based location. These are
static files and are downloaded automatically to improve location
resolution speed and accuracy. No query or data is sent to these
servers. These contain orbits and statuses of satellites, Earth
environmental data and time adjustment information.</p>
<p>On 6th generation Pixels onwards (which use a Broadcom GNSS chip),
almanacs are downloaded from
https://broadcom.psds.grapheneos.org/lto2.dat,
https://broadcom.psds.grapheneos.org/rto.dat and
https://broadcom.psds.grapheneos.org/rtistatus.dat which are a cache
for Broadcom's data available at
https://gllto.glpals.com/7day/v5/latest/lto2.dat,
https://gllto.glpals.com/rto/v1/latest/rto.dat and
https://gllto.glpals.com/rtistatus4.dat. Alternatively, the standard
servers can be enabled in the Settings app which are
https://agnss.goog/lto2.dat, https://agnss.goog/rto.dat and
https://agnss.goog/rtistatus.dat providing a similar cache of
Broadcom's data currently (as of October 2022) hosted on GCP (Google
Cloud Platform).</p>
<p>On 4th and 5th generation Pixels (which use a Qualcomm baseband
providing cellular, Wi-Fi, Bluetooth and GNSS in separate sandboxes),
almanacs are downloaded from
https://qualcomm.psds.grapheneos.org/xtra3Mgrbeji.bin which is a cache
of Qualcomm's data. Alternatively, the standard servers can be enabled
in the Settings app which will use
https://path1.xtracloud.net/xtra3Mgrbeji.bin,
https://path2.xtracloud.net/xtra3Mgrbeji.bin and
https://path3.xtracloud.net/xtra3Mgrbeji.bin. GrapheneOS improves the
privacy of Qualcomm PSDS (XTRA) by removing the User-Agent header
normally containing an SoC serial number (unique hardware identifier),
random ID and information on the phone including manufacturer, brand
and model. We also always fetch the most complete XTRA database variant
(xtra3Mgrbeji.bin) instead of model/carrier/region dependent variants
to avoid leaking a small amount of information based on the database
variant.</p>