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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
|
<!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="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="/mask-icon.svg" color="#1a1a1a"/>
<link rel="apple-touch-icon" href="/apple-touch-icon.png"/>
<link rel="stylesheet" href="/main.css"/>
<link rel="manifest" href="/manifest.webmanifest"/>
<link rel="license" href="/LICENSE.txt"/>
<script type="module" src="/js/redirect.js"></script>
</head>
<body>
<header>
<nav id="site-menu">
<ul>
<li><a href="/"><img src="/mask-icon.svg" alt=""/>GrapheneOS</a></li>
<li><a href="/features">Features</a></li>
<li><a href="/install/">Install</a></li>
<li><a href="/build">Build</a></li>
<li><a href="/usage">Usage</a></li>
<li aria-current="page"><a href="/faq">FAQ</a></li>
<li><a href="/releases">Releases</a></li>
<li><a href="/source">Source</a></li>
<li><a href="/history/">History</a></li>
<li><a href="/articles/">Articles</a></li>
<li><a href="/donate">Donate</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</nav>
</header>
<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>
</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="#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>
</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="#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 5 (redfin)</li>
<li>Pixel 4a (5G) (bramble)</li>
<li>Pixel 4a (sunfish)</li>
<li>Pixel 4 XL (coral)</li>
<li>Pixel 4 (flame)</li>
<li>Pixel 3a XL (bonito)</li>
<li>Pixel 3a (sargo)</li>
<li>Pixel 3 XL (crosshatch)</li>
<li>Pixel 3 (blueline)</li>
</ul>
<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 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">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>The following devices offer the best hardware, firmware and software
security along with the longest future support time and are strongly
recommended:</p>
<ul>
<li>Pixel 5 (redfin)</li>
<li>Pixel 4a (5G) (bramble)</li>
<li>Pixel 4a (sunfish)</li>
</ul>
<p>The Pixel 5 and Pixel 4a (5G) will likely be supported for at least a bit
longer than the Pixel 4a. We strongly recommend against purchasing older
devices.</p>
<p>The Pixel 4a is a budget device meeting the same security standards as the more
expensive flagship devices. You can read more on the differences between the hardware
elsewhere. Unlike the Pixel 3a, the Pixel 4a has a proper SSD which provides a much
better experience with the GrapheneOS exec-based spawning security feature.</p>
<p>The Pixel 4 and Pixel 4 XL have comparable security but won't be supported
as long. On the Pixel 4 and Pixel 4 XL, support for fingerprint unlock as a
secondary unlock mechanism was replaced with IR-based 3D facial scanning.
GrapheneOS plans to extend secondary unlock support with the option of
2-factor authentication using a secondary PIN or passphrase required for
fingerprint / face unlock. The Pixel 4a, Pixel 4a (5G) and Pixel 5 moved back
to using a fingerprint scanner instead of face unlock.</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>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>
</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 end-of-life, no longer receive full security
updates and are supported only via extended support releases of GrapheneOS
separate from the official GrapheneOS releases:</p>
<ul>
<li>Pixel 2 XL (taimen)</li>
<li>Pixel 2 (walleye)</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 following devices are no longer supported at all:</p>
<ul>
<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 source-level support for the
following development boards 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>
</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 access the clipboard. Apps without focus
cannot access the clipboard. This is a stricter restriction than preventing apps in
the background from accessing it, since an app in the foreground or a foreground
service cannot access 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>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>
</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 4) 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 configured
locale, time zone, network country code, whether the dark theme is enabled and
other similar global settings. 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 <code>ANDROID_ID</code> 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 <code>ANDROID_ID</code>,
but that makes little difference since apps within the same profile can communicate
with each other with mutual consent. It's comparable to <code>ANDROID_ID</code> 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 <code>ANDROID_ID</code> which remains the same for the
lifetime of the profile, but apps can tie it the previous ID since they can detect
that it changed via their own ID in their app data.</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 <code>ANDROID_ID</code> 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>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>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. Make good use of authenticated
encryption and airplane mode to avoid needing to depend on an insecure network.</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>
</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>GrapheneOS makes connections to the outside world to test connectivity, detect
captive portals and download updates. No data varying per user / installation / device
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 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>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. 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.</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 Settings ➔ System ➔ Date
& time ➔ Use network-provided time. 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 when available.</p>
</li>
<li>
<p>On devices with a Qualcomm baseband (which provides GPS), when location
functionality is enabled and 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 which are currently (as of
September 2020) hosted via Amazon Web Services. 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>
<p>We plan to offer the option to download these files from the GrapheneOS
servers, but we'll retain the option to use the standard servers to blend in
with other devices.</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>By default, the GrapheneOS connectivity check server 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>You can change the connectivity check URLs via the Settings ➔ Network &
internet ➔ Advanced ➔ Internet connectivity check setting. At the moment, it
can be toggled between the GrapheneOS server and the standard Google servers
used by billions of other Android devices. This can be used to blend in with
other Android devices, both with and without Play services. Changing this to
the Standard (Google) mode will use the same URLs used by AOSP and the stock
OS along with the vast majority of other devices:</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>
</li>
<li>
<p>DNS connectivity and functionality tests</p>
</li>
<li>
<p>DNS resolution for other connections</p>
</li>
</ul>
<p>Vanadium does not make connections not requested by the app as part of providing
the WebView implementation in the OS. If you choose to use it as your browser, it
performs similar connections as the ones performed by the OS above. It does not send
any identifying information to servers, etc. but rather fetches some static assets
like dictionaries when triggered by usage of the app. We're working on eliminating
everything unnecessary and making our servers the default for handling anything that
cannot simply be shipped with Vanadium for one reason or another such as requiring
quicker updates.</p>
</article>
<article id="privacy-policy">
<h3><a href="#privacy-policy">What is the privacy policy for GrapheneOS services?</a></h3>
<p>GrapheneOS services follow the <a href="https://www.eff.org/dnt-policy">EFF's
privacy-friendly Do Not Track (DNT) policy</a> for all users of our publicly available
services, not just those opting out of tracking via Do Not Track. Our policy is the
same with "DNT User" redefined as "user" to cover any user. This serves as a standard
privacy policy across all of our public services:</p>
<ul>
<li>attestation.app</li>
<li>grapheneos.network</li>
<li>grapheneos.org</li>
<li>releases.grapheneos.org</li>
<li>time.grapheneos.org</li>
</ul>
<p>Our implementation of the policy primarily consists of making sure our servers only
retain logs for 10 days. In practice, we follow much stricter privacy guidelines than
than the rules laid out in the EFF policy. However, we don't want to define our own
complex, ad-hoc privacy policy rather than reusing a sensible one with serious thought
put into it by experts.</p>
<p>Our mail server (mail.grapheneos.org) isn't offered as a public service and doesn't
have a privacy policy since it's only used internally by GrapheneOS developers.</p>
</article>
<article id="default-dns">
<h3><a href="#default-dns">Which DNS servers are used by default?</a></h3>
<p>The OS uses the network-provided DNS servers by default. Typically, dynamic
IP configuration is used to auto-configure the client on the network. IPv4 DNS
servers are obtained via DHCP and IPv6 DNS servers are obtained via RDNSS. For
a static IP configuration, the DNS servers are manually configured as part of
the static configuration.</p>
<p>A VPN provides a network layered on top of the underlying networks and the
OS uses the VPN-provided DNS servers for everything beyond resolving the IP
address of the VPN and performing network connectivity checks on each of the
underlying networks in addition to the VPN itself.</p>
<p>Using the network-provided DNS servers is the best way to blend in with
other users. Network and web sites can fingerprint and track users based on a
non-default DNS configuration. Our recommendation for general purpose usage is
to use the network-provided DNS servers.</p>
<p>In some broken or unusual network environments, the network could fail to
provide DNS servers as part of dynamic IP configuration. The OS has high
availability fallback DNS servers to handle this case. A network can fail to
provide DNS servers in order to fingerprint clients based on what they use as
the fallback so it's important for it to be consistent across each install.
GrapheneOS replaces Google Public DNS with
<a href="https://developers.cloudflare.com/1.1.1.1/what-is-1.1.1.1/">Cloudflare
DNS</a> for the fallback DNS servers due to the superior privacy policy and
widespread usage including as the fallback DNS servers in other Android-based
operating systems. We're considering hosting our own servers and offering a
toggle for using the standard (Google) servers to blend in with other devices
similarly to how we handle the internet connectivity checks.</p>
</article>
<article id="custom-dns">
<h3><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, since it's just the network-provided DNS.</p>
<p>Apps and web sites can detect the configured DNS servers by generating random
subdomains resolved by querying their authoritative DNS server. This can be used as
part of fingerprinting users. If you're using a VPN, you should consider using the
standard DNS service provided by the VPN service to avoid standing out from other
users.</p>
</article>
<article id="private-dns-ip">
<h3><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>
</article>
<article id="private-dns-other">
<h3><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>
</article>
<article id="private-dns-visited">
<h3><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>
</article>
<article id="vpn-support">
<h3><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>
</article>
<article id="network-monitoring">
<h3><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>
</article>
<article id="firewall">
<h3><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 have 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>
</article>
<article id="ad-blocking">
<h3><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>
<p>Apps and web sites can detect that ad-blocking is being used and can determine
what's being blocked. This can be used as part of fingerprinting users. Using a widely
used service like AdGuard with a standard block list is much less of an issue than a
custom set of subscriptions / rules, but it still stands out compared to the default
of not doing it.</p>
</article>
<article id="ad-blocking-apps">
<h3><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>
</article>
<article id="baseband-isolation">
<h3><a href="#baseband-isolation">Is the baseband isolated?</a></h3>
<p>Yes, the baseband is isolated on all of the officially supported devices. Memory
access is partitioned by the IOMMU and limited to internal memory and memory shared
by the driver implementations. The baseband on the officially supported devices with a
Qualcomm SoC implements Wi-Fi and Bluetooth as internal sandboxed processes rather
than having a separate baseband for those like earlier devices.</p>
<p>Earlier generation devices we used to support prior to Pixels had Wi-Fi + Bluetooth
implemented on a separate SoC. This was not properly contained by the stock OS and we
put substantial work into addressing that problem. However, that work has been
obsoleted now that Wi-Fi and Bluetooth are provided by the SoC on the officially
supported devices.</p>
<p>A component being on a separate chip is orthogonal to whether it's isolated. In
order to be isolated, the drivers need to treat it as untrusted. If it has DMA access
that needs to be contained via IOMMU and the driver needs to treat the shared memory
as untrusted, as it would data received another way. There's a lot of attack surface
between the baseband and the kernel/userspace software stack connected to it. OS
security is very relevant to containing hardware components including the radios and
the vast majority of the attack surface is in software. The OS relies upon the
hardware and firmware to be able to contain components but ends up being primarily
responsible for it due to control over the configuration of shared memory and the
complexity of the interface and the OS side implementation.</p>
<p>The mobile Atheros Wi-Fi driver/firmware is primarily a SoftMAC implementation with
the vast majority of the complexity in the driver rather than the firmware. The fully
functional driver is massive and the firmware is quite small. Unfortunately, since the
Linux kernel is monolithic and has no internal security boundaries, the attack surface
is problematic and a HardMAC implementation with most complexity in the isolated
firmware could be better than the status quo. An isolated driver would be ideal.</p>
</article>
</section>
<section id="day-to-day-use">
<h2><a href="#day-to-day-use">Day to day use</a></h2>
<article id="updates">
<h3><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>
</article>
<article id="updates-sideloading">
<h3><a href="#updates-sideloading">How do I update without connecting the device to the internet?</a> </h3>
<p>Updates can be <a href="/usage#updates-sideloading">sideloaded via
recovery</a>.</p>
</article>
<article id="notifications">
<h3><a href="#notifications">Do notifications work properly on GrapheneOS?</a></h3>
<p>Yes, notifications work properly on GrapheneOS. Portable apps avoiding a
hard dependency on Google Play services for their functionality have fully
working notifications on GrapheneOS. Apps that are not fully portable across
Android implementations often lack support for background notifications due to
only bothering to implement support for it via Google Play services.</p>
<p>Most apps that able to run without Google Play services will have working
notifications when they're in the foreground. Unfortunately, many apps don't
implement a service to continue receiving events from their server in the
background. On the stock OS, they rely on receiving events through Google
servers via Firebase Cloud Messaging (FCM) in the background and sometimes
even in the foreground, although it doesn't have good reliability/latency.</p>
<p>Polling is the traditional pull-based approach of checking for new events
at an interval. This is badly suited to mobile devices for anything more than
very infrequent checks. Apps using infrequent polling are supposed to use the
JobScheduler service. A minority of apps may only know how to use Firebase
WorkManager or the legacy Firebase JobDispatcher. Most apps know how to use
JobScheduler rather than depending on Google Play services for the Firebase
services. Typical examples of apps using this approach are a feed reader for
RSS/Atom feeds or an email client providing notifications of new emails for a
server without IMAP IDLE push support.</p>
<p>Push messaging is the modern push-based model of receiving events from the
server as they occur by keeping open a connection to it. Push messaging still
uses occasional polling to keep the connection from being killed by a network
using a stateful firewall or some form of NAT. IPv4 mobile networks use large
scale NAT (CGNAT) to work around IPv4 addresses running out. The occasional
polling will also detect a silently dropped connection. An efficient push
implementation will figure out that it's on a reliable network and throttle
the polling to be very infrequent.</p>
<p>In order to properly implement either push messaging or frequent polling
themselves, an app needs to run a foreground service. This is displayed as a
persistent notification. It will normally be marked as a silent notification
with the lowest possible priority, so it will be collapsed as the bottom and
won't show up as an icon in the status bar or on the lockscreen. A battery
optimization exception is also needed for the app to bypass device idle states
and run while the device is idle. If you can tolerate delays while the device
is idle, then the battery optimization exception isn't mandatory.</p>
<p>FairEmail and Signal are examples of apps using the proper approach of a
foreground service combined with an optional battery optimization exception.
Signal doesn't have an optimized implementation throttling the polling used to
keep the connection alive, but it does work well. Signal always uses their own
push implementation in the foreground, but switches to FCM in the background
when it's available. FairEmail uses the IMAP IDLE push feature provided by
email servers. Most email servers don't provide FCM-based push in the first
place, and the only way for an email app to provide push via FCM would be to
give the user's credentials to their own server to act as a middleman.</p>
</article>
<article id="file-transfer">
<h3><a href="#file-transfer">How do I transfer files to another device?</a></h3>
<p>Files can be transferred to another device using an external drive, USB
file transfer via MTP / PTP or an app-based mechanism.</p>
<p>To use an external drive, plug it into the phone and use the system file
manager to copy files to and from it. The only difference on GrapheneOS is USB
peripherals such as USB flash drives will be ignored unless they're plugged in
at boot or when the device is unlocked. You can configure this in Settings ➔
Security.</p>
<p>Transferring files to an attached computer is done with MTP / PTP. After
plugging in the phone to the computer, there will be a notification showing
the current USB mode with charging as the default. Pressing the notification
acts as a shortcut to Settings ➔ Connected devices ➔ USB. You can enable file
transfer (MTP) or PTP with this menu. It will provide read/write access to the
entire profile home directory, i.e. the top-level directory named after the
device in the system file manager. Due to needing to trust the computer with
coarse-grained access, we recommend transferring files with a flash drive or
an app with end-to-end encryption such sending the files to yourself via an
end-to-end encrypted messaging app like Element (Matrix).</p>
</article>
</section>
<article id="google-services">
<h2><a href="#google-services">Will GrapheneOS include support for Google services?</a></h2>
<p>GrapheneOS will never include either Google Play services or another
implementation of Google services like microG. Those are not included in the
Android Open Source Project and are not required for baseline Android
compatibility. Apps designed to run on Android rather than only Android with
bundled Google apps and services already work on GrapheneOS, so a huge number of
both open and closed source apps are already available for it.</p>
<p>AOSP APIs not tied to Google but that are typically provided via Play services
will continue to be implemented using open source providers like the Seedvault
backup app. Text-to-speech, speech-to-text, geocoding, accessibility services,
etc. are examples of other open Android APIs where we need to develop/bundle an
implementation based on existing open source projects. GrapheneOS is not going to
be implementing these via a Google service compatibility layer because these APIs
are in no way inherently tied to Google services.</p>
<p>We're developing a minimal Play services compatibility layer as a regular app
without any special privileges. The app will provide a stub implementation of the
entire Play services API pretending the servers are down and the functionality is
unavailable. It will always be disabled by default since apps will detect Play
services is available and will try to use it rather than alternatives. As an
example, Signal would try to use a non-functional FCM implementation rather than
their own server push implementation. The intention is that users will only enable
this in profiles dedicated to running apps with an unnecessary hard dependency on
Play services. We'll likely prevent enabling it in the owner profile to help users
avoid those kinds of pitfalls.</p>
<p>Our Play services app won't have any special privileges or whitelisting in the
OS like Play services or microG. There will be no support for bypassing arbitrary
signature checks like the microG signature spoofing patch since it substantially
compromises the OS security model and breaks other security features like verified
boot. Instead, our app will be signed with a GrapheneOS Play services key and the
only OS support for the app will be presenting the GrapheneOS Play services key as
the Google Play services key.</p>
<p>Ideally, Google themselves would support installing the official Play services
as a regular Android app, rather than taking the monopolistic approach of forcing
it to be bundled into the OS in a deeply integrated way with special privileged
permissions and capabilities unavailable to other service providers competing with
them. Even though we would never include it in GrapheneOS, it would be great if
users did have the option to install Play services as a regular app in specific
profiles. It's unfortunate that the approach taken to it is so deeply integrated
and anti-competitive. GrapheneOS users can still choose to use Google services if
they choose, but largely only via a browser. A few of their apps like Google Maps
do work with reduced functionality without Play services but most won't.</p>
</article>
<article id="features">
<h2><a href="#features">What features does GrapheneOS implement?</a></h2>
<p>See the <a href="/features">features page</a>.</p>
</article>
<article id="anti-theft">
<h2><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>
</article>
<article id="bundled-apps">
<h2><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/web#verifying-installation">installation guide documentation on
this</a>).</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>
<p>In some cases, licensing is also an issue. GrapheneOS is permissively licensed and
is usable for building devices with an immutable root of trust. GPLv3 is deliberately
incompatible with these kinds of locked down devices, unlike GPLv2 code such as the
Linux kernel. This means GrapheneOS can't include GPLv3 code without forbidding use
cases we want to support. GPLv3 is no problem for our own usage, but we don't want to
forbid using GrapheneOS as a replacement for the Android Open Source Project in locked
down devices.</p>
</article>
<article id="roadmap">
<h2><a href="#roadmap">What is the roadmap for GrapheneOS?</a></h2>
<p>To get an idea of the near term roadmap, check out the
<a href="/contact#reporting-issues">issue trackers</a>. The vast majority of the
issues filed in the trackers are planned enhancements, with care taken to make sure
all of the issues open in the tracker are concrete and actionable.</p>
<p>In the long term, GrapheneOS aims to move beyond a hardened fork of the Android
Open Source Project. Achieving the goals requires moving away from relying on the Linux
kernel as the core of the OS and foundation of the security model. It needs to move
towards a microkernel-based model with a Linux compatibility layer, with many stepping
stones leading towards that goal including adopting virtualization-based
isolation.</p>
<p>The initial phase for the long-term roadmap of moving away from the current
foundation will be to deploy and integrate a hypervisor like Xen to leverage it for
reinforcing existing security boundaries. Linux would be running inside the virtual
machines at this point, inside and outside of the sandboxes being reinforced. In the
longer term, Linux inside the sandboxes can be replaced with a compatibility layer
like gVisor, which would need to be ported to arm64 and given a new backend alongside
the existing KVM backend. Over the longer term, i.e. many years from now, Linux can
fade away completely and so can the usage of virtualization. The anticipation is that
many other projects are going to be interested in this kind of migration, so it's not
going to be solely a GrapheneOS project, as demonstrated by the current existence of
the gVisor project and various other projects working on virtualization deployments
for mobile. Having a hypervisor with verified boot still intact will also provide a
way to achieve some of the goals based on extensions to Trusted Execution Environment
(TEE) functionality even without having GrapheneOS hardware.</p>
<p>Hardware and firmware security are core parts of the project, but it's currently
limited to research and submitting suggestions and bug reports upstream. In the long
term, the project will need to move into the hardware space.</p>
</article>
<article id="install">
<h2><a href="#install">How do I install GrapheneOS?</a></h2>
<p>GrapheneOS has two officially supported installation methods. You can either
use the <a href="/install/web">WebUSB-based installer</a> recommended for most
users or the <a href="/install/cli">command-line installation guide</a> aimed at
more technical users.</p>
<p>We strongly recommend using one of the official installation methods. Third
party installation guides tend to be out-of-date and often contain misguided
advice and errors. If you have trouble with the installation process, ask for help
from the <a href="/contact#community">#grapheneos Matrix / IRC channel</a>.</p>
<p>The command-line approach offers a way to install GrapheneOS without trusting
our server infrastructure. This requires being on an OS with proper fastboot and
signify packages along with understanding the process enough to avoid blindly
trusting the instructions from our site. For most users, the web-based
installation approach is no less secure and avoids needing any software beyond a
browser with WebUSB support.</p>
</article>
<article id="build">
<h2><a href="#build">How do I build GrapheneOS?</a></h2>
<p>Follow the <a href="/build">official GrapheneOS building guide</a>. Third party
build guides tend to be out-of-date and often contain misguided advice and errors.
If you have trouble with the build process, ask for help from the
<a href="/contact#community">#grapheneos Matrix / IRC channel</a>.</p>
</article>
<article id="donate">
<h2><a href="#donate">How can I donate to GrapheneOS?</a></h2>
<p>The <a href="/donate">donate page</a> provides multiple options for donating to
support the GrapheneOS project. GrapheneOS is entirely funded by donations.</p>
</article>
<article id="upstream">
<h2><a href="#upstream">Does GrapheneOS make upstream contributions?</a></h2>
<p>GrapheneOS has made substantial contributions to the privacy and security of
the Android Open Source Project, along with contributions to the Linux kernel,
LLVM, OpenBSD and other projects. Much of our past work is no longer part of the
downstream GrapheneOS project because we've successfully landed many patches
upstream. We've had even more success with making suggestions and participating in
design discussions to steer things in the direction we want. Many upstream changes
in AOSP such as removing app access to low-level process, network, timing and
profiling information originated in the GrapheneOS project. The needs of the
upstream projects are often different from ours, so they'll often reimplement the
features in a more flexible way. We've almost always been able to move to using
the upstream features and even when we still need our own implementation it helps
to have the concepts/restrictions considered by the upstream project and apps
needing to be compatible with it. Getting features upstream often leads to an
improved user experience and app compatibility.</p>
</article>
<article id="founding">
<h2><a href="#founding">When was the GrapheneOS project founded?</a></h2>
<p>GrapheneOS was founded as an open source project in 2014. It has been through
multiple renames and wasn't initially known as GrapheneOS. See the
<a href="/history/">history page</a> for more details.</p>
</article>
<article id="copperheados">
<h2><a href="#copperheados">How is CopperheadOS related to GrapheneOS?</a></h2>
<p>GrapheneOS was previously known as CopperheadOS. There's a new closed source
product using our legacy CopperheadOS branding and code that's not associated with
the original project. See <a href="/history/copperheados">our page on the legacy
CopperheadOS branding</a> for more details.</p>
</article>
<article id="company">
<h2><a href="#company">Will GrapheneOS create a company?</a></h2>
<p>No, GrapheneOS will remain a non-profit open source project / organization. It
will remain an independent organization not strongly associated with any specific
company. We partner with a variety of companies and other organizations, and we're
interested in more partnerships in the future. Keeping it as an non-profit avoids
the conflicts of interest created by a profit-based model. It allows us to focus
on improving privacy/security without struggling to build a viable business model
that's not in conflict with the success of the open source project.</p>
</article>
<article id="copyright-and-licensing">
<h2><a href="#copyright-and-licensing">Who owns the GrapheneOS code and how is it licensed?</a></h2>
<p>The copyright for GrapheneOS code is entirely owned by the GrapheneOS developers
and is made available under OSI-approved Open Source licenses. The upstream licensing
is inherited for the modifications to those projects and MIT licensing is used for our
own standalone projects. GrapheneOS has never had any copyright assignment and the
developers have always owned their own contributions.</p>
<p>The tiny portion of the code written by people under contract with the former
sponsor has not been included in the project since it was ported from Android Oreo to
Pie in 2018. This code became obsolete and was no longer useful. The vast majority of
the code from the previous era was owned by Daniel Micay, with very few exceptions. It
was never written under any contracts or employment agreements, was never assigned to
any company or organization and was the continuation of the original independent open
source project. The code was originally published under the same permissive open
source licenses that are used by GrapheneOS today. Only a small portion of this
historical code is actually still in use today. Most has become obsolete or has been
replaced by rewrites taking better approaches than in the past.</p>
<p>There was an era from September 2016 until the project split from the former
sponsor in 2018 where non-commercial usage licensing was used for the official
builds and from January 2017 onwards for revisions to the existing permissively
licensed code. This was an attempt to prop up the sponsor that was supposed to be
supporting the open source project. This did not impact ownership of the code and
Daniel Micay has relicensed the portions of the code that are used by GrapheneOS.
GrapheneOS does not contain any code based on code under non-commercial usage
licensing. Great care was taken to avoid pulling in anything that was not solely
owned by Daniel Micay, which was the case for nearly everything in the
project.</p>
</article>
<article id="trademark">
<h2><a href="#trademark">What about the GrapheneOS name and logo?</a></h2>
<p>The GrapheneOS name and logo are trademarks of the GrapheneOS project. These
marks are in the process of being formally registered in Canada and the US. In the
meantime, they're protected as common law trademarks.</p>
<p>Derivatives of GrapheneOS that are being published/redistributed should replace
the GrapheneOS branding with their own. It needs to be clear to users that it's a
distinct OS based on GrapheneOS. Forks of GrapheneOS are not GrapheneOS itself and
should not be presented that way.</p>
<p>Only unofficial builds of the official GrapheneOS sources should be referred to
as unofficial builds. An unofficial build is a build of the official GrapheneOS
sources with the update server URL changed to another server. A project making
modifications beyond that isn't simply an unofficial build and should be presented
as a distinct OS based on GrapheneOS.</p>
</article>
</main>
<footer>
<a href="/"><img src="/mask-icon.svg" 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>
<li><a href="https://www.linkedin.com/company/grapheneos/">LinkedIn</a></li>
</ul>
</footer>
</body>
</html>
|
