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
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
|
<!DOCTYPE html>
<html lang="en" prefix="og: https://ogp.me/ns#">
<head>
<meta charset="utf-8"/>
<title>Features overview | GrapheneOS</title>
<meta name="description" content="Overview of GrapheneOS features differentiating it from the Android Open Source Project (AOSP)."/>
<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 features overview"/>
<meta property="og:description" content="Overview of GrapheneOS features differentiating it from the Android Open Source Project (AOSP)."/>
<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/features"/>
<link rel="canonical" href="https://grapheneos.org/features"/>
<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="features" %}
{% include "header.html" %}
{% endwith %}
<main id="features">
<h1><a href="#features">Features overview</a></h1>
<p>GrapheneOS is a private and secure mobile operating system with great functionality
and usability. It starts from the strong baseline of the
<a href="https://source.android.com/">Android Open Source Project (AOSP)</a> and
takes great care to avoid increasing attack surface or hurting the strong security
model. GrapheneOS makes substantial improvements to both privacy and security through
many carefully designed features built to function against real adversaries. The
project cares a lot about usability and app compatibility so those are taken into
account for all of our features.</p>
<p>GrapheneOS is focused on substance rather than branding and marketing. It doesn't
take the typical approach of piling on a bunch of insecure features depending on the
adversaries not knowing about them and regressing actual privacy/security. It's a very
technical project building privacy and security into the OS rather than including
assorted unhelpful frills or bundling subjective third party apps choices.</p>
<p>GrapheneOS is also hard at work on filling in gaps from not bundling Google apps
and services into the OS. We aren't against users using Google services but it doesn't
belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut
of simply bundling a very incomplete and poorly secured third party reimplementation
of Google services into the OS. That wouldn't ever be something users could rely upon.
It will also always be chasing a moving target while offering poorer security than the
real thing if the focus is on simply getting things working without great care for
doing it robustly and securely.</p>
<p>This page provides an overview of currently implemented features differentiating
GrapheneOS from AOSP. It doesn't document our many historical features that are no
longer included for one reason or another. Many of our features were implemented in
AOSP, Linux, <a href="https://llvm.org/">LLVM</a> and other projects GrapheneOS is
based on and those aren't listed here. In many cases, we've been involved in getting
those features implemented in core infrastructure projects.</p>
<nav id="table-of-contents">
<h2><a href="#table-of-contents">Table of contents</a></h2>
<ul>
<li>
<a href="#grapheneos">GrapheneOS</a>
<ul>
<li>
<a href="#exploit-protection">Defending against exploitation of
unknown vulnerabilities</a>
<ul>
<li><a href="#attack-surface-reduction">Attack surface
reduction</a>
<ul>
<li><a href="#usb-c-port-and-pogo-pins-control">USB-C port and pogo pins control</a></li>
</ul>
</li>
<li><a href="#exploit-mitigations">Exploit
mitigations</a></li>
<li><a href="#improved-sandboxing">Improved
sandboxing</a></li>
<li><a href="#anti-persistence">Anti-persistence /
detection</a></li>
</ul>
</li>
<li><a href="#more-complete-patching">More complete patching</a></li>
<li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li>
<li><a href="#android-auto">Android Auto</a></li>
<li><a href="#network-permission-toggle">Network permission toggle</a></li>
<li><a href="#sensors-permission-toggle">Sensors permission toggle</a></li>
<li><a href="#storage-scopes">Storage Scopes</a></li>
<li><a href="#contact-scopes">Contact Scopes</a></li>
<li><a href="#broad-carrier-support">Broad carrier support without invasive carrier access</a></li>
<li><a href="#lte-only-mode">LTE-only mode</a></li>
<li><a href="#wifi-privacy">Wi-Fi privacy</a></li>
<li><a href="#network-location">Network location</a></li>
<li><a href="#private-screenshots">Private screenshots</a></li>
<li><a href="#closed-device-identifier-leaks">Closed device identifier leaks</a></li>
<li><a href="#privacy-by-default">Privacy by default</a></li>
<li><a href="#pin-scrambling">PIN scrambling</a></li>
<li><a href="#two-factor-fingerprint-unlock">Two-factor fingerprint unlock</a></li>
<li><a href="#supports-longer-passwords">Supports longer
passwords</a></li>
<li><a href="#auto-reboot">Auto reboot</a></li>
<li><a href="#clearing-sensitive-data-from-memory">Clearing sensitive data from memory</a></li>
<li><a href="#duress">Duress PIN/Password</a></li>
<li><a href="#more-secure-fingerprint-unlock">More secure fingerprint
unlock</a></li>
<li>
<a href="#improved-user-profiles">Improved user profiles</a>
<ul>
<li><a href="#more-user-profiles">More user profiles</a></li>
<li><a href="#end-session">End session</a></li>
<li><a href="#disabling-app-installation">Disabling app installation</a></li>
<li><a href="#install-available-apps">Install available apps</a></li>
<li><a href="#notification-forwarding">Notification forwarding</a></li>
</ul>
</li>
<li><a href="#grapheneos-app-repository">GrapheneOS app
repository</a></li>
<li><a href="#vanadium">Vanadium: hardened WebView and default
browser</a></li>
<li><a href="#auditor">Auditor app and attestation service</a></li>
<li><a href="#grapheneos-camera">GrapheneOS Camera</a></li>
<li><a href="#grapheneos-pdf-viewer">GrapheneOS PDF Viewer</a></li>
<li><a href="#setup-wizard">GrapheneOS Setup Wizard</a></li>
<li><a href="#encrypted-backups">Encrypted backups</a></li>
<li><a href="#location-data-access-indicator">Location data access
indicator</a></li>
<li><a href="#user-installed-apps-can-be-disabled">User installed apps
can be disabled</a></li>
<li><a href="#improved-vpn-leak-blocking">Improved VPN leak blocking</a></li>
<li><a href="#log-viewer-and-crash-reporting">Log viewer and user-facing crash reporting</a></li>
<li><a href="#other-features">Other features</a></li>
</ul>
</li>
<li><a href="#services">Services</a></li>
<li><a href="#project">Project</a></li>
</ul>
</nav>
<section id="grapheneos">
<h2><a href="#grapheneos">GrapheneOS</a></h2>
<p>These are the features of GrapheneOS beyond what's provided by version 15 of
the Android Open Source Project. It only covers our improvements to AOSP and not
baseline features. This section doesn't list features like the standard app
sandbox, verified boot, exploit mitigations (ASLR, SSP, Shadow Call Stack, Control
Flow Integrity, etc.), permission system (foreground-only and one-time permission
grants, scoped file access control, etc.) and so on but rather only our
improvements to modern Android. We plan on providing a separate page listing the
improvements we've contributed to Android since those features aren't listed here
despite being a substantial portion of our overall historical work.</p>
<section id="exploit-protection">
<h3><a href="#exploit-protection">Defending against exploitation of unknown
vulnerabilities</a></h3>
<p>GrapheneOS is heavily focused on protecting users against attackers
exploiting unknown (0 day) vulnerabilities. Patching vulnerabilities doesn't
protect users before the vulnerability is known to the vendor and has a patch
developed and shipped.</p>
<p>Unknown (0 day) vulnerabilities are much more widely used than most realize
to exploit users not just in targeted attacks but in broad deployments.
Project Zero maintains
<a href="https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/view#gid=0">a
spreadsheet</a> tracking zero day exploitation detected in the wild. This is
only a peek into what's happening since it only documents cases where the
attackers were caught exploiting users, often because the attacks are not
targeted but rather deployed on public websites, etc.</p>
<p>The first line of defense is attack surface reduction. Removing unnecessary
code or exposed attack surface eliminates many vulnerabilities completely.
GrapheneOS avoids removing any useful functionality for end users, but we can
still disable lots of functionality by default and require that users opt-in
to using it to eliminate it for most of them. An example we landed upstream in
Android is disallowing using the kernel's profiling support by default, since
it was and still is a major source of Linux kernel vulnerabilities. Profiling
is now only exposed to apps for developers who enable developer tools, enable
the Android Debug Bridge (ADB) and then use profiling tools via ADB. It's also
only enabled until the next boot. This isn't listed below since it's one of
the features we got implemented in Android itself.</p>
<p>The next line of defense is preventing an attacker from exploiting a
vulnerability, either by making it impossible, unreliable or at least
meaningfully harder to develop. The vast majority of vulnerabilities are well
understood classes of bugs and exploitation can be prevented by avoiding the
bugs via languages/tooling or preventing exploitation with strong exploit
mitigations. In many cases, vulnerability classes can be completely wiped out
while in many others they can at least be made meaningfully harder to exploit.
Android does a lot of work in this area, and GrapheneOS has helped to advance
this in Android and the Linux kernel. It takes an enormous amount of resources
to develop fundamental fixes for these problems and there's often a high
performance, memory or compatibility cost to deploying them. Mainstream
operating systems usually don't prioritize security over other areas.
GrapheneOS is willing to go further, thus we offer toggles for users to choose
the compromises they prefer instead of forcing it on them. In the meantime,
weaker less complete exploit mitigations can still provide meaningful barriers
against attacks as long as they're developed with a clear threat model.
GrapheneOS is heavily invested in many areas of developing these protections:
developing/deploying memory safe languages/libraries, static/dynamic
analysis tooling and many kinds of mitigations.</p>
<p>The final line of defense is containment through sandboxing at various
levels: fine-grained sandboxes around a specific context like per site browser
renderers, sandboxes around a specific component like Android's media codec
sandbox and app/workspace sandboxes like the Android app sandbox used to
sandbox each app which is also the basis for user/work profiles. GrapheneOS
improves all of these sandboxes through fortifying the kernel and other base
OS components along with improving the sandboxing policies.</p>
<p>Preventing an attacker from persisting their control of a component or the
OS/firmware through verified boot and avoiding trust in persistent state
also helps to mitigate the damage after a compromise has occurred.</p>
<p>Remote code execution vulnerabilities are the most serious and allow an
attacker to gain a foothold on the device or even substantial control over it
remotely. Local code execution vulnerabilities allow breaking out of a sandbox
including the app sandbox or browser renderer sandbox after either
compromising an app/browser renderer remotely, compromising an app's supply
chain or getting the user to install a malicious app. Many other kinds of
vulnerabilities exist but most of what we're protecting against falls into
these two broad categories.</p>
<p>The vast majority of local and remote code execution vulnerabilities are
memory corruption bugs caused by memory unsafe languages or rare low-level
unsafe code in an otherwise memory safe language. Most of the remaining issues
are caused by dynamic code execution/loading features. Our main focus is on
preventing or raising the difficulty of exploiting memory corruption bugs
followed by restricting dynamic code execution both to make escalation from a
memory corruption bug harder and to directly mitigate bugs caused by dynamic
code loading/generation/execution such as a JIT compiler bug or a plugin
loading vulnerability.</p>
<section id="attack-surface-reduction">
<h4><a href="#attack-surface-reduction">Attack surface reduction</a></h4>
<ul>
<li>Greatly reduced remote, local and proximity-based attack surface by
stripping out unnecessary code, making more features optional and
disabling optional features by default (NFC, Bluetooth, UWB, etc.), when
the screen is locked (USB, USB-C, pogo pins, camera access) and optionally
after a timeout (Bluetooth, Wi-Fi).</li>
<li>Native debugging (ptrace) access is blocked for all bundled apps to
reduce local attack surface. ptrace access is allowed by default for user
installed apps for compatibility, with an option to block it by default. In
both cases, ptrace access can be blocked or allowed manually on a per-app
basis. When an app that is blocked from accessing ptrace tries to use it,
GrapheneOS shows a notification that links the per-app native debugging
settings screen.</li>
</ul>
<h5 id="usb-c-port-and-pogo-pins-control"><a href="#usb-c-port-and-pogo-pins-control">USB-C port and pogo pins control</a></h5>
<p>Our <b>USB-C port and pogo pins</b> setting protects against attacks
through USB-C or pogo pins while the OS is booted. For the majority of
devices without pogo pins, the setting is labelled <b>USB-C port</b>.</p>
<p>The feature has five modes:</p>
<ul>
<li>Off</li>
<li>Charging-only</li>
<li>Charging-only when locked</li>
<li>Charging-only when locked, except before first unlock</li>
<li>On</li>
</ul>
<p>The default is <b>Charging-only when locked</b>, which significantly
reduces attack surface when the device is locked. After locking, it blocks
any new USB connections immediately through either USB-C and pogo pins at
both the hardware level via configuring the USB controller and also at the
OS level in the kernel to provide a second layer of defense. It disables the
data lines at a hardware level as soon as the existing connections end which
happens right away if there were no USB connections. It also disables USB-C
alternate modes including DisplayPort at both the OS and hardware level.</p>
<p>Our implementation is far more secure than Android's standard USB HAL
toggle available to device admin apps. The standard feature only disables
high level USB handling in the OS. It doesn't block new USB connections or
disable the data lines at a hardware level. It also leaves the handling of
the USB-C and pogo pins protocols enabled in the OS, and it doesn't disable
the USB-C alternate modes. The standard feature is also either blocking or
not blocking USB at a high level, without the ability to block new
connections and disable USB only once the existing connections end. Other
operating systems trying to implement a similar feature via the standard
toggle end up continuing to allow new USB connections in the OS until all
connections end instead of the two-phase approach we use for our two
Charging-only when locked modes.</p>
<p>The highest security <b>Off</b> mode disables charging in addition to
data to remove the remaining attack surface from the USB controller and OS
supporting charging including the USB-PD protocol. There's no risk of the
device not being able to be charged since the overall feature doesn't apply
while the device is powered off, booted into the firmware-based fastboot
mode or the charging, recovery and fastbootd modes.</p>
</section>
<section id="exploit-mitigations">
<h4><a href="#exploit-mitigations">Exploit mitigations</a></h4>
<ul>
<li>Hardened app runtime</li>
<li><a href="/usage#exec-spawning">Secure application spawning
system</a> avoiding sharing address space layout and other secrets
across applications</li>
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
providing defenses against the most common classes of vulnerabilities (memory
corruption)</li>
<li>
Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
malloc (memory allocator)</a> leveraging modern hardware capabilities
to provide substantial defenses against the most common classes of
vulnerabilities (heap memory corruption) along with reducing the lifetime
of sensitive data in memory. The <a
href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
README</a> has extensive documentation on it. The hardened_malloc
project is portable to other Linux-based operating systems and is being
adopted by other security-focused operating systems like secureblue. Our
allocator also heavily influenced the design of the <a
href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
musl malloc implementation</a> which offers substantially better security than
musl's previous malloc while still having minimal memory usage and code size.
<ul>
<li>Fully out-of-line metadata with protection from corruption, ruling
out traditional allocator exploitation</li>
<li>Separate memory regions for metadata, large allocations and each
slab allocation size class with high entropy random bases and no
address space reuse between the different regions</li>
<li>Deterministic detection of any invalid free</li>
<li>Zero-on-free with detection of write-after-free via checking that
memory is still zeroed before handing it out again</li>
<li>Delayed reuse of address space and memory allocations through the
combination of deterministic and randomized quarantines to mitigate
use-after-free vulnerabilities</li>
<li>Fine-grained randomization</li>
<li>Aggressive consistency checks</li>
<li>Memory protected guard regions around allocations larger than 16k
with randomization of guard region sizes for 128k and above</li>
<li>Allocations smaller than 16k have guard regions around each of the
slabs containing allocations (for example, 16 byte allocations are in
4096 byte slabs with 4096 byte guard regions before and after)</li>
<li>Random canaries with a leading zero are added to these smaller
allocations to block C string overflows, absorb small overflows
and detect linear overflows or other heap corruption when the
canary value is checked (primarily on free)</li>
<li>Hardware memory tagging for slab allocations (128k and
below) providing probabilistic detection of all use-after-free
and inter-object overflows along with deterministic detection
of all small/linear overflows and use-after-free until it has
been reused once and gone through the quarantines twice</li>
</ul>
</li>
<li>On ARMv9, Branch Target Identification (BTI) and Pointer
Authentication Code (PAC) return address protection are enabled for
userspace OS code we build instead of only specific apps</li>
<li>Signed integer overflow is made well defined in C and C++ for code
where automatic overflow checking is disabled</li>
<li>
Hardened kernel
<ul>
<li>4-level page tables are enabled on arm64 to provide a much
larger address space (48-bit instead of 39-bit) with
significantly higher entropy Address Space Layout
Randomization (33-bit instead of 24-bit).</li>
<li>Basic hardware memory tagging is used in the main kernel
memory allocators (slab, page_alloc, non-executable vmalloc) to
provide probabilistic detection of all use-after-free and
inter-object overflows along with deterministic detection of
use-after-free until the memory is allocated again (we plan to
add deterministic detection of small/linear overflows like
hardened_malloc)</li>
<li>Random canaries with a leading zero are added to the
kernel heap (slub) to block C string overflows, absorb small
overflows and detect linear overflows or other heap corruption
when the canary value is checked (on free, copies to/from
userspace, etc.).</li>
<li>Memory is wiped (zeroed) as soon as it's released in both
the low-level kernel page allocator and higher level kernel
heap allocator (slub). This substantially reduces the lifetime
of sensitive data in memory, mitigates use-after-free
vulnerabilities and makes most uninitialized data usage
vulnerabilities harmless. Without our changes, memory that's
released retains data indefinitely until the memory is handed
out for other uses and gets partially or fully overwritten by
new data.</li>
<li>In early boot, all the memory not being used by the OS is
zeroed to get rid of any data leftover from a previous boot in
case zero-on-free didn't have the opportunity to clear it as
part of a clean reboot/shutdown. All the devices we support have
a reset attack protection feature we proposed zeroing memory for
firmware-based boot modes, but we need to finish it up by adding
it for the OS boot modes ourselves. Fully encrypted RAM with a
per-boot key cycled on reboots will eventually obsolete these
features for newer devices.</li>
<li>Kernel stack allocations are zeroed to make most
uninitialized data usage vulnerabilities harmless.</li>
<li>Assorted attack surface reduction through disabling
features or setting up infrastructure to dynamically
enable/disable them only as needed (perf, ptrace).</li>
<li>Assorted upstream hardening features are enabled,
including many which we played a part in developing and
landing upstream as part of our linux-hardened project (which
we intend to revive as a more active project again).</li>
<li>Forced kernel module signing with per-build RSA 4096 /
SHA256 keys and lockdown mode set to forced confidentiality
mode help to enforce a low-level boundary between the kernel
and userspace even if mistakes are made in SELinux policy or
there's a deep userspace compromise.</li>
<li>Additional consistency/integrity checks are enabled for
frequently targeted kernel data structures.</li>
<li>On ARMv9, Branch Target Identification (BTI) is enabled in
addition to Clang type-based Control Flow Integrity (CFI) to
cover functions excluded from type-based CFI</li>
<li>On ARMv9, ShadowCallStack (SCS) is enabled in addition to
Pointer Authentication Code (PAC) return address protection
instead of only enabling SCS when PAC is unavailable</li>
</ul>
</li>
<li>Android Runtime Just-In-Time (JIT) compilation/profiling is fully
disabled and replaced with full ahead-of-time (AOT) compilation. The
only JIT compilation in the base OS is the V8 JavaScript JIT which is
disabled by default for the Vanadium browser with per-site exception
support.</li>
<li>Dynamic code loading for both native code or Java/Kotlin classes is
blocked for nearly the entire base OS to prevent base OS processes. This
works alongside verified boot to prevent base OS processes from running
attacker controlled native code or Java/Kotlin code. The only exceptions
from the policy for the base OS are in-memory code loading for the media
DRM sandbox and the Vanadium JIT compiler being permitted. Vanadium has
JIT compilation disabled by default for every site and for apps using
the WebView with the exception of our PDF Viewer app. Vanadium disables
the JIT compiler by default with a per-site and per-app toggle for it
and per-process enforcement of blocking dynamic code loading implemented
with seccomp-bpf based on the per-site/per-app JIT compiler toggle.</li>
<li>Dynamic code loading for both native code or Java/Kotlin classes can
be disabled for user installed apps via 3 exploit protection toggles:
Dynamic code loading from memory, Dynamic code loading from storage and
WebView JIT. This can also be used to opt-out of the WebView JIT for our
PDF Viewer and dynamic code loading from memory for the Vanadium browser
to disable support for the per-site opt-in to JIT compilation. In order
to make the dynamic code loading toggles more usable, we show a user
facing notification when an app has dynamic code loading from memory or
storage blocked, including a file path being shown when it's blocked
from storage. This allows users to disable it for all their apps and
then enable them for the ones requiring it.</li>
<li>Filesystem access hardening</li>
</ul>
</section>
<section id="improved-sandboxing">
<h4><a href="#improved-sandboxing">Improved sandboxing</a></h4>
<p>GrapheneOS improves the app sandbox through hardening SELinux policy
and seccomp-bpf policy along with all the hardening to components like
kernel implementing the app sandbox and providing a path for the attacker
to escape it if they can exploit those components. We primarily focus on
the app sandbox, but we also improve the other sandboxes including making
direct improvements to the web browser renderer sandbox used for both the
default browser and WebView rendering engine provided by the OS and used
by a huge number of other apps from dedicated browsers to messaging
apps.</p>
</section>
<section id="anti-persistence">
<h4><a href="#anti-persistence">Anti-persistence / detection</a></h4>
<ul>
<li>Enhanced <a href="https://source.android.com/docs/security/features/verifiedboot">verified boot</a>
with better security properties and reduced attack surface</li>
<li>GrapheneOS finishes the incomplete implementation of verified boot
for out-of-band updates to packages (APKs) in the OS. We enforce this
by requiring fs-verity metadata signed with a trusted key for system
app updates both at install time and boot time. This provides
continuous verification where every read from an out-of-band APK
update is verified similarly to every read from a firmware, OS image
or APEX update being verified. The signing key and version are
enforced to prevent downgrades or other attacks such as replacing a
package with a variant of the same one from a different GrapheneOS
supported device. We disable the persistent package parsing cache to
prevent bypassing the metadata checks through this otherwise highly
persistent state, which only has a very small negative impact on boot
time from the data not being available from previous boots (typically
less than 1 second).</li>
<li>GrapheneOS closes a loophole where app-based system components
built as part of the OS can be downgraded to an older version due to
versionCode not being incremented when system components get updated
as part of changes to the OS. We enforce this both at package install
time and boot time.</li>
<li>Enhanced hardware-based attestation with more precise version information</li>
<li>Hardware-based security verification and monitoring via our
<a href="#auditor">Auditor app and attestation service</a></li>
<li>Compressed APEX module support is disabled as it's not useful for GrapheneOS,
uses extra unnecessary storage space and adds more verified boot attack surface.</li>
</ul>
</section>
</section>
<section id="more-complete-patching">
<h3><a href="#more-complete-patching">More complete patching</a></h3>
<p>GrapheneOS includes fixes for a large number of vulnerabilities not yet
fixed in Android.</p>
<p>We're able to quickly and safely ship the latest Linux kernel LTS point
releases on devices with GKI (Generic Kernel Image) support including the 6th
and 7th generation Pixel phones. At the time of writing on 2023-11-06,
GrapheneOS is using the latest Linux 5.10 GKI LTS release (5.10.199) for 6th
and 7th generation Pixel phones. The stock Pixel OS is on Linux 5.10.157 from
2022-12-02 with a small number of additional patches backported. This means
GrapheneOS provides hundreds of relevant kernel patches including many
security patches not yet included in the stock OS. It's possible for us to
stay several months ahead due to their approach of moving to new LTS releases
only in quarterly releases after a long freeze and testing process.</p>
<p>We often find new vulnerabilities ourselves and report them upstream. We've
reported dozens of vulnerabilities for both the generic Android codebase and
also for Pixels specifically. We also often find missed patches which were
supposed to be included but were missed, especially when there are device
specific components with partially shared but separate codebases for different
devices.</p>
<p>Our overall approach is to focus on systemic privacy and security
improvements but fixing individual vulnerabilities is still very
important.</p>
</section>
<section id="sandboxed-google-play">
<h3><a href="#sandboxed-google-play">Sandboxed Google Play</a></h3>
<p>GrapheneOS has a compatibility layer providing the option to install and use
the official releases of Google Play in the standard app sandbox. Google Play
receives absolutely no special access or privileges on GrapheneOS as opposed to
bypassing the app sandbox and receiving a massive amount of highly privileged
access. Instead, the compatibility layer teaches it how to work within the full
app sandbox. It also isn't used as a backend for the OS services as it would be
elsewhere since GrapheneOS doesn't use Google Play even when it's installed.</p>
<p>Since the Google Play apps are simply regular apps on GrapheneOS, you install
them within a specific user or work profile and they're only available within that
profile. Only apps within the same profile can use it, and they need to explicitly
choose to use it. It works the same way as any other app and has no special
capabilities. As with any other app, it can't access data of other apps and
requires explicit user consent to gain access to profile data or the standard
permissions. Apps within the same profile can communicate with mutual consent and
it's no different for sandboxed Google Play.</p>
<p>Sandboxed Google Play is close to being fully functional and provides near
complete compatibility with the app ecosystem depending on Google Play. Only a
small subset of privileged functionality which we haven't yet ported to
different approaches with our compatibility layer is unavailable. Some
functionality is inherently privileged and can't be provided as part of the
compatibility layer.</p>
<p>The vast majority of Play services functionality works perfectly including
dynamically downloaded/updated modules (dynamite modules) and functionality
provided by modular app components such as Google Play Games. By default,
location requests are rerouted to a reimplementation of the Play geolocation
service provided by GrapheneOS. You can disable rerouting and use the standard
Play services geolocation service instead if you want the Google network
location service and related features.</p>
<p>Our compatibility layer includes full support for the Play Store. Play
Store services are fully available including in-app purchases, Play Asset
Delivery, Play Feature Delivery and app/content license checks. It can
install, update and uninstall apps with the standard approach requiring that
the user authorizes it as an app source and consents to each action. It will
use the standard Android 12+ unattended update feature to do automatic updates
for apps where it was the last installer.</p>
<p>See the <a href="/usage#sandboxed-google-play-installation">usage guide
section on sandboxed Google Play</a> for instructions.</p>
</section>
<section id="android-auto">
<h3><a href="#android-auto">Android Auto</a></h3>
<p>GrapheneOS provides an option to install and use the official releases of
Android Auto.</p>
<p>Android Auto requires privileged access in order to work. GrapheneOS uses
an extension of the sandboxed Google Play compatibility layer to make Android
Auto work with a reduced level of privileges.</p>
<p>For more details, see the <a href="/usage#android-auto">usage guide section
on Android Auto</a>.</p>
</section>
<section id="network-permission-toggle">
<h3><a href="#network-permission-toggle">Network permission toggle</a></h3>
<p>GrapheneOS adds a Network permission toggle for disallowing both direct and
indirect access to any of the available networks. The device-local network
(localhost) is also guarded by this permission, which is important for
preventing apps from using it to communicate between profiles. Unlike a
firewall-based implementation, the Network permission toggle prevents apps
from using the network via APIs provided by the OS or other apps in the same
profile as long as they're marked appropriately.</p>
<p>The standard INTERNET permission used as the basis for the Network
permission toggle is enhanced with a second layer of enforcement and proper
support for granting/revoking it on a per-profile basis.</p>
<p>To avoid breaking compatibility with Android apps, the added permission
toggle is enabled by default. However, the OS app installation UI has been
extended to show the toggle as part of the installation confirmation page so
users can disable it when installing an app.</p>
<p>When the Network permission is disabled, GrapheneOS pretends the network is
down. It shows the network as down in various APIs, returns errors showing a
network connectivity issue rather than a revoked permission and avoids running
scheduled jobs depending on the network. This results in apps handling it as
if the network is down rather than crashing or showing errors from trying to
use the network and being unable to do it.</p>
</section>
<section id="sensors-permission-toggle">
<h3><a href="#sensors-permission-toggle">Sensors permission toggle</a></h3>
<p>Sensors permission toggle: disallow access to all other sensors not covered
by existing Android permissions (Camera, Microphone, Body Sensors, Activity
Recognition) including an accelerometer, gyroscope, compass, barometer,
thermometer and any other sensors present on a given device. When access is
disabled, apps receive zeroed data when they check for sensor values and don't
receive events. GrapheneOS creates an easy-to-disable notification when apps
try to access sensors blocked by the permission being denied. This makes the
feature more usable since users can tell if the app is trying to access this
functionality.</p>
<p>To avoid breaking compatibility with Android apps, the added permission is
enabled by default. When an app attempts to access sensors and receives zeroed
data due to being denied, GrapheneOS creates a notification that can be
easily disabled. The Sensors permission can be set to be disabled by default
for user installed apps in <b>Settings <span aria-label="and then">></span>
Security & privacy <span aria-label="and then">></span>
More security & privacy</b>.</p>
</section>
<section id="storage-scopes">
<h3><a href="#storage-scopes">Storage Scopes</a></h3>
<p>GrapheneOS provides Storage Scopes as a fully compatible alternative to the
standard Android storage permissions. Instead of granting storage permissions,
users can enable Storage Scopes to make the app assume that it has all storage
permissions that it asked for. On Android, an app that doesn't have any storage
permissions is still allowed to create files and directories, and is allowed to
access the files that it created. Users can optionally add files and directories
as storage scopes to permit the app to access files created by other apps.</p>
<p>For more details, see the <a href="/usage#storage-access">usage guide
section on storage access</a>.</p>
</section>
<section id="contact-scopes">
<h3><a href="#contact-scopes">Contact Scopes</a></h3>
<p>GrapheneOS provides Contact Scopes as an alternative to granting the
Contacts permission. By default, it acts as if the contacts list is empty and
users can grant different kinds of access to specific contacts or groups of
contacts.</p>
<p>For more details, see the <a href="/usage#contact-scopes">usage guide section
on Contact Scopes</a>.</p>
</section>
<section id="broad-carrier-support">
<h3><a href="#broad-carrier-support">Broad carrier support without invasive carrier access</a></h3>
<p>GrapheneOS has much broader carrier support than AOSP and mostly matches
the stock OS on Pixels without making the same sacrifices. We convert their
APN, carrier configuration, MMS and visual voicemail databases to the formats
used by AOSP with our CarrierConfig2 project and scripts. We strip out
anti-user configuration requiring provisioning for tethering, forbidding
disabling 2G, etc. We don't include the invasive carrier-specific apps and
support for Open Mobile Alliance Device Management (OMA DM) so we also strip
out configuration depending on those.</p>
<p>See our <a href="/usage#carrier-functionality">usage guide section on
carrier functionality</a> for more details.</p>
</section>
<section id="lte-only-mode">
<h3><a href="#lte-only-mode">LTE-only mode</a></h3>
<p><a href="/usage#lte-only-mode">LTE-only mode</a> to reduce cellular radio
attack surface by disabling enormous amounts of both legacy code (2G, 3G) and
bleeding edge code (5G).</p>
</section>
<section id="wifi-privacy">
<h3><a href="#wifi-privacy">Wi-Fi privacy</a></h3>
<p>GrapheneOS supports per-connection MAC randomization and enables it by
default. This is a more private approach than the standard persistent
per-network random MAC used by modern Android.</p>
<p>When the per-connection MAC randomization added by GrapheneOS is being
used, DHCP client state is flushed before reconnecting to a network to avoid
revealing that it's likely the same device as before.</p>
<p>GrapheneOS also applies fixes for serious flaws with the Linux kernel IPv6
privacy address implementation which allow using it as an identifier not just
for connections to the same network but also across different networks. We
don't need to apply these changes for the Pixel 6 and later since this was
fixed in the Linux kernel upstream, but hasn't been backported to earlier
kernel LTS branches so we still need to take care of it there.</p>
<p>See our <a href="/usage#wifi-privacy">usage guide section on Wi-Fi privacy
for more general information</a> rather than only our improvements to the
standard Wi-Fi privacy approach.</p>
</section>
<section id="network-location">
<h3><a href="#network-location">Network location</a></h3>
<p>GrapheneOS provides network-based location as an opt-in feature with our own
implementation. Similar to the services provided by Apple and Google, it offers
location detection based on nearby networks rather than solely relying on using
satellite-based location (GNSS) with technologies to accelerate it (A-GNSS). It
makes getting a location indoors and in cities with tall buildings much faster
or possible when it wouldn't have worked via GNSS. Certain apps also have the
expectation of network-based location being available and don't account for the
time needed to get a GNSS-based estimate or inability to get one everywhere so
this feature provides improved compatibility with apps.</p>
<p>Unlike Google's service and similar to Apple's service, our feature provides
local position estimation based on retrieving location data for nearby networks
from a service. It caches the information from the service in-memory for up to
15 minutes from when it was last used so it can function offline after getting
the initial data. It only needs to send a network identifier for each network it
wants to use for position estimation. Google's service does server-side position
estimation which requires repeatedly sending distance estimates for each network
to the service for each position estimate update. The approach we use doesn't
require providing any information to the service once the nearby networks are in
the cache or sending distance estimates. The service also provides it with extra
data covering a fairly large area from the initial position with a reasonable
density of networks so it can keep functioning if internet access is lost.</p>
<p>Our network-based location feature is currently entirely based on Wi-Fi
Access Points (APs). It will be extended with support for cell towers in the
near future to provide better support for rural locations like the Apple and
Google services. Apple and Google also use Bluetooth beacons but it's a very
niche feature only relevant to certain malls, stores, etc. which are usually
covered well enough by Wi-Fi support for decent position estimates.</p>
<p>Users can currently choose between using our proxy to Apple's service or
directly using Apple's service. We're in the process of building our own
database and service based on data from multiple sources including Apple's
service. Unlike the Apple and Google services, our service will provide support
for fully offline usage based on database downloads rather than requiring
sending network identifiers to the service to fetch data for them.</p>
<p>For details on how to use the network location feature, see the
<a href="/usage#network-location">usage section</a>.</p>
</section>
<section id="private-screenshots">
<h3><a href="#private-screenshots">Private screenshots</a></h3>
<p>GrapheneOS disables the inclusion of sensitive metadata in screenshots.</p>
<p>On Android, each screenshot includes an EXIF Software tag with detailed OS
build/version information (<code>android.os.Build.DISPLAY</code>). It's the
same value shown at <b>Settings <span aria-label="and then">></span>
About device <span aria-label="and then">></span> Build number</b>. This
leaks the OS, OS version and also usually the device family/model since builds are
specific to a family of devices. GrapheneOS completely disables this
tag.</p>
<p>On Android, each screenshot also includes EXIF tags with the local date,
time and timezone offset. GrapheneOS disables this by default to
avoid leaking the time and quasi-location information through metadata that
isn't visible to the user. The date and time are already included in the file
name of the screenshot which is fully visible to the user and can be easily
modified by them without a third-party tool. GrapheneOS includes a toggle for
turning this metadata back on in <b>Settings <span aria-label="and then">></span>
Security & privacy <span aria-label="and then">></span>
More security & privacy</b> since some users may find it to be useful.</p>
</section>
<section id="closed-device-identifier-leaks">
<h3><a href="#closed-device-identifier-leaks">Closed device identifier leaks</a></h3>
<p>GrapheneOS fixes several prominent device identifier leaks bypassing
Android's intention of apps not being able to uniquely identify a device. See
our FAQ sections on <a href="/faq#hardware-identifiers">hardware
identifiers</a> and <a href="/faq#non-hardware-identifiers">non-hardware
identifiers</a> for more general information.</p>
<p>Our <a href="/usage#exec-spawning">secure application spawning system</a>
primarily exists to significantly improve protection against exploitation.
However, it also improves privacy. On a device without our secure application
spawning system, the secrets used for probabilistic exploit mitigations such
as ASLR are usable as device identifiers persisting until reboot. This is an
easy way to identify the device from apps in different profiles. It's a minor
bonus of the feature and there are still plenty of side channels to identify
devices across apps, but it fixes most of the known direct identifier
leaks.</p>
<p>We also eliminate several holes in preventing apps from accessing hardware
identifiers including tightening up the restrictions for apps targeting legacy
Android platform versions.</p>
</section>
<section id="privacy-by-default">
<h3><a href="#privacy-by-default">Privacy by default</a></h3>
<p>GrapheneOS doesn't include or use Google apps and services by default and
avoids including any other apps/services not aligned with our privacy and
security focus. Google apps and services can be used on GrapheneOS as regular
sandboxed apps without any special access or privileges through our <a
href="#sandboxed-google-play">sandboxed Google Play</a> feature, but we don't
include those apps by default to give users an explicit choice on whether they
want to use those apps and which profiles they want to use it in.</p>
<p>We change the default settings to prefer privacy over small conveniences:
personalized keyboard suggestions based on gathering input history are
disabled by default, sensitive notifications are hidden on the lockscreen by
default and passwords are hidden during entry by default.</p>
<p>Some of our changes for <a href="#attack-surface-reduction">attack surface
reduction</a> can also improve privacy by default by not exposing unnecessary
radios, etc. by default and avoiding the impact of potential privacy bugs with
the hardware.</p>
<p>By default, we also use GrapheneOS servers for the following services
instead of Google servers:</p>
<ul>
<li>Connectivity checks</li>
<li>Attestation key provisioning</li>
<li>GNSS almanac downloads (PSDS) for Broadcom and Qualcomm (XTRA)</li>
<li>Secure User Plane Location (SUPL)</li>
<li>Network time</li>
<li>Vanadium (Chromium) component updates</li>
</ul>
<p>We provide a toggle to switch back to Google's servers for connectivity
checks, attestation key provisioning and GNSS almanac downloads along with
adding proper support for disabling network time connections. This combines
with other toggles to allow making a GrapheneOS device appear to be an AOSP
device. This is only particularly important for connectivity checks since the
other connections get routed through a VPN which is needed to blend in on a
local network in practice.</p>
<p>In addition to our SUPL privacy improvements, we override the SUPL server
to our proxy by default. We also add a toggle for users to switch to the
standard SUPL server for their carrier (usually supl.google.com) or disable it
entirely.</p>
<p>See our <a href="/faq#default-connections">default connections FAQ entry
for much more detailed information</a>.</p>
</section>
<section id="pin-scrambling">
<h3><a href="#pin-scrambling">PIN scrambling</a></h3>
<p>GrapheneOS adds a toggle for enabling PIN scrambling to raise the
difficulty of figuring out the PIN being entered by a user either due to
physical proximity or a side channel. PIN scrambling is applied to both the
lock screen and SIM PIN/PUK.</p>
</section>
<section id="two-factor-fingerprint-unlock">
<h3><a href="#two-factor-fingerprint-unlock">Two-factor fingerprint unlock</a></h3>
<p>GrapheneOS adds the option to require entering a 2nd factor PIN after
successfully authenticating with a fingerprint on the lockscreen in order to
complete unlocking the device. Since Android/iOS use biometric unlock as a
secondary unlock mechanism for convenience, this allows users to make use of a
strong passphrase as their primary unlock method with the convenience of a
fingerprint and short PIN for secondary unlock. Failure to enter the correct PIN
counts towards the standard attempt limit.</p>
</section>
<section id="supports-longer-passwords">
<h3><a href="#supports-longer-passwords">Supports longer passwords</a></h3>
<p>GrapheneOS supports setting longer passwords by default: 128 characters
instead of 16 characters. This avoids the need to use a device manager to
enable this functionality.</p>
<p>This feature allows users to make use of diceware passwords if they don't
want to depend on the security of the secure element which provides very
aggressive throttling and offers a high level of security even for a random 6
digit PIN.</p>
</section>
<section id="auto-reboot">
<h3><a href="#auto-reboot">Auto reboot</a></h3>
<p>GrapheneOS provides an auto-reboot feature which reboots locked devices after
a set period of time to put data at rest. A countdown timer is started each time
the device is locked, and the device will reboot if a successful unlock doesn't
occur before the timer reaches zero. Unlocking any profile cancels the timer,
not just the Owner profile.</p>
<p>The timer is set to 18 hours by default, but can be set to values between 10
minutes and 72 hours, or turned off.</p>
<p>This feature doesn't apply when the device is in "Before First Unlock" state,
meaning that it will not lead to the device continuously rebooting, as data is
already at rest.</p>
<p>The feature is implemented in the init process, preventing it from being
bypassed through system process crashes since an init crash causes a kernel
panic which leads to a reboot.</p>
</section>
<section id="clearing-sensitive-data-from-memory">
<h3><a href="#clearing-sensitive-data-from-memory">Clearing sensitive data from memory</a></h3>
<p>As documented in our section on <a href="#exploit-mitigations">our added
exploit mitigations</a>, GrapheneOS adds zeroing of freed memory to both the
standard userspace and kernel allocators. These features have the secondary
benefit of clearing sensitive data from memory as soon as possible in addition
to defending against exploits. Android implements regular compaction of frozen
cached apps and apps currently running in the background based on triggering a
full compacting garbage collection (GC) and then requesting that malloc frees as
much memory as it can back to the OS. This pairs well with zeroing features and
results in freed data getting cleared faster for Java/Kotlin and also the C, C++
and Rust libraries used by them where low-level allocators get held onto until
the high level objects are freed.</p>
<p>When the device is locked, we trigger full compacting garbage collection (GC)
for the SystemUI and system_server processes to release all of the memory that's
no longer used back to the OS. Due to GrapheneOS enabling kernel page allocator
zeroing, this results in all the no longer referenced data in objects being
cleared. We based our approach on Android's standard approach to running a full
compacting GC for these two processes after the device is unlocked to clear
remnants of the user's PIN/password and keys derived from it. This is a nice way
to clear some data immediately after locking prior to our
<a href="#auto-reboot">auto-reboot</a> feature kicking in to clear all of the OS
memory.</p>
<p>GrapheneOS modifies some of the ways the device can be rebooted to proceed
with the normal reboot process where memory gets freed and cleared by the kernel
page and slab allocator zeroing features enabled by GrapheneOS.</p>
</section>
<section id="duress">
<h3><a href="#duress">Duress PIN/Password</a></h3>
<p>GrapheneOS provides users with the ability to set a duress PIN/Password that
will irreversibly wipe the device (along with any installed eSIMs) once entered
anywhere where the device credentials are requested (on the lockscreen, along
with any such prompt in the OS).</p>
<p>The wipe does not require a reboot and cannot be interrupted. It can be set
up at <b>Settings <span aria-label="and then">></span> Security & privacy <span
aria-label="and then">></span> Device unlock <span
aria-label="and then">></span> Duress Password</b> in the owner profile. Both a
duress PIN and password will need to be set to account for different profiles
that may have different unlock methods.</p>
<p>Note that if the duress PIN/Password is the same as the actual unlock method,
the actual unlock method always takes precedence, and therefore no wipe will
occur.</p>
</section>
<section id="more-secure-fingerprint-unlock">
<h3><a href="#more-secure-fingerprint-unlock">More secure fingerprint unlock</a></h3>
<p>GrapheneOS improves the security of the fingerprint unlock feature by only
permitting 5 total attempts rather than implementing a 30 second delay between
every 5 failed attempts with a total of 20 attempts. This doesn't just reduce
the number of potential attempts but also makes it easy to disable fingerprint
unlock by intentionally failing to unlock 5 times with a different finger.</p>
<p>GrapheneOS also adds support for using the fingerprint scanner only for
authentication in apps and unlocking hardware keystore keys by toggling off
support for unlocking. This feature already existed for the standard Android
face unlock feature.</p>
</section>
<section id="improved-user-profiles">
<h3><a href="#improved-user-profiles">Improved user profiles</a></h3>
<p>Android's user profiles are isolated workspaces with their own instances of
apps, app data and profile data (contacts, media store, home directory, etc.).
Apps can't see the apps in other user profiles and can only communicate with
apps within the same user profile (with mutual consent with the other app).
Each user profile has their own encryption keys based on their lock method.
They're a great fit for GrapheneOS with a lot of room for improvement.</p>
<p>GrapheneOS provides improvements to user profile functionality and is
working on further improvements to make switching between them and monitoring
other profiles much more convenient.</p>
<section id="more-user-profiles">
<h4><a href="#more-user-profiles">More user profiles</a></h4>
<p>GrapheneOS raises the limit on the number of secondary user profiles to 32
(31 + guest) instead of only 4 (3 + guest) to make this feature much more
flexible.</p>
</section>
<section id="end-session">
<h4><a href="#end-session">End session</a></h4>
<p>GrapheneOS also enables support for logging out of user profiles without
needing a device manager controlling the device to use this feature. Logging
out makes profiles inactive so none of the apps installed in them can run. It
also purges the disk encryption keys from memory and hardware registers,
putting the user profile back at rest.</p>
</section>
<section id="disabling-app-installation">
<h4><a href="#disabling-app-installation">Disabling app installation</a></h4>
<p>GrapheneOS adds a toggle to the user management settings for disabling
secondary user app installation. You can install the apps you want to be
usable in a secondary user and then disable the ability to install more apps
as that user in the Owner profile. Android supports this as a standard device
management feature but doesn't make it available to a user who owns their own
device.</p>
</section>
<section id="install-available-apps">
<h4><a href="#install-available-apps">Improved install available apps</a></h4>
<p>GrapheneOS enables the standard install available apps feature that's
still not enabled in AOSP or the stock Pixel OS to allow the Owner user to
install packages that are available in other users. This allows installing
an app in a secondary user that's already installed in the Owner user
without needing to download it again. This helps a lot with using the
toggles added for disabling app installation by secondary users.</p>
</section>
<section id="notification-forwarding">
<h4><a href="#notification-forwarding">Notification forwarding</a></h4>
<p>GrapheneOS supports forwarding notifications from users running in the
background to the currently active user. Forwarding notifications to other
users is disabled by default and can be enabled within each user profile
where forwarding to the active profile is wanted. Notifications forwarded
from other profiles are displayed by default in a standard local
notification channel.</p>
</section>
</section>
<section id="grapheneos-app-repository">
<h3><a href="#grapheneos-app-repository">GrapheneOS app repository</a></h3>
<p>GrapheneOS includes our own security, minimalism and usability-focused app
repository client for using our first-party app repository. Our app repository
is currently used to distribute our own apps and a mirror of Google Play for
the sandboxed Google Play feature. In the future, it will be used to
distribute first-party GrapheneOS builds of externally developed open source
apps with hardening applied.</p>
</section>
<section id="vanadium">
<h3><a href="#vanadium">Vanadium: hardened WebView and default browser</a></h3>
<p>GrapheneOS includes our Vanadium browser as WebView implementation provided
by the OS and our default browser. Vanadium is a hardened variant of Chromium
providing enhanced privacy and security, similar to how GrapheneOS compares to
AOSP. The Vanadium browser currently doesn't add many features but there are a
lot of enhancements planned in the long term.</p>
<p>Some of the features added compared to standard mobile Chromium:</p>
<ul>
<li>Hardware memory tagging (MTE) enabled for the main allocator</li>
<li>Type-based Control Flow Integrity (CFI)</li>
<li>Strong stack protector</li>
<li>Automatic zero-initialized variables</li>
<li>Well-defined signed overflow</li>
<li>Strict site isolation and sandboxed iframes</li>
<li>JavaScript JIT disabled by default with per-site toggle via drop-down
permission menu</li>
<li>Dynamic code execution is blocked for processes without the JavaScript
JIT enabled as an extension to the seccomp-bpf sandbox</li>
<li>Native Android autofill implementation to avoid needing sandboxed Google
Play for autofill support</li>
<li>Native Android credential manager support for passkeys to avoid needing
sandboxed Google Play for passkey support</li>
<li>WebGPU disabled for attack surface reduction</li>
<li>WebRTC IP handling policy toggle to control peer-to-peer WebRTC mode</li>
<li>High performance content filtering engine using EasyList + EasyPrivacy
with per-site toggle via drop-down permission menu</li>
<li>More complete state partitioning without origin trial opt-out</li>
<li>Standard Android 16 user agent reduction is enabled early for the
WebView to replace the major OS version, device model and browser
minor/build/patch version with standard placeholder values</li>
<li>High entropy client hints are replaced with the standard placeholder
values used in Chromium's reduced user agent for both the browser and
WebView to close a loophole where Chromium is still sharing the major OS
version, device model and browser minor/build/patch version with any server
requesting it via client hints</li>
<li>Battery API always shows the battery as charging and at 100% capacity</li>
<li>Trivial subdomain hiding disabled</li>
<li>Consistent browser behavior across users without usage of feature flags
and seed-based trials</li>
<li>Nearly all remote services disabled by default or removed. Only connects
to GrapheneOS servers by default. There are only 2 default services:
component updates such as certificate authority and certificate revocation
updates and DNS-over-HTTPS connectivity checks when enabled</li>
<li>Web search and global search intents to replace the need for an OS
search app</li>
<li>Option to always open links from other apps, custom tabs, search intents
and share intents in Incognito mode</li>
<li>Option to reduce or disable sending cross-origin referrer information
sharing where a link was opened</li>
<li>Hybrid post-quantum cryptography enabled by default to match the
behavior of Chromium on desktop since the devices we support are more
than fast enough</li>
</ul>
<p>Better default settings, including non-user-facing flags:</p>
<ul>
<li>Reduce Accept-Language header by default (only available via
chrome://flags)</li>
<li>Third party cookies disabled by default</li>
<li>Payment support disabled by default</li>
<li>Website background sync disabled by default</li>
<li>Sensors access disabled by default</li>
<li>Protected media (DRM) disabled by default</li>
<li>Hyperlink auditing disabled by default</li>
<li>Do Not Track enabled by default mainly to avoid users differentiating
themselves from others by enabling it since it has no real value</li>
<li>WebRTC IP handling policy set to the most private value by default
instead of the least private value (turned into a user-facing option by
Vanadium)</li>
</ul>
<p>Configurable features such as JS JIT disabling and content filtering are
currently exclusive to the Vanadium browser. Vanadium WebView is currently
excluded from these changes until it has an app setting configuration menu
similar to the standard site setting configuration menu.</p>
<p>Extension support isn't planned due to being at odds with site isolation and
anti-fingerprinting. We plan to implement more features as part of the browser
with a focus on privacy and security improvements which can be active by default
rather than opt-in niche features. Improvements will generally be opt-out on a
per-site basis rather than opt-in to provide privacy and security by default and
to avoid users making themselves more identifiable by opting into privacy and
security features. Default-disabled JS JIT and default-enabled content filtering
are early examples of this approach we plan to expand upon.</p>
<p>We plan to add more site settings toggles related to attack surface reduction
such as site setting toggles for WebGL, WebGPU, WebRTC and other features which
are normally always enabled. This will help with both security and improving the
defenses against fingerprinting.</p>
<p>Anti-fingerprinting depends on having a large userbase with the same browser,
extensions, content filters and other web-facing configuration. Once Vanadium
has more features, it will be made available outside GrapheneOS to expand the
userbase. Our approach to attack surface reduction eliminates fingerprinting
methods in addition to attack surface for exploits and this will be a key part
of how we approach preventing fingerprinting by not having features like WebGL,
WebGPU and WebRTC exposed in the first place. Good defaults and avoiding having
users changing web-facing configuration is an important part of this. Content
filters will remain standard across users and updated together as part of the
Vanadium configuration app. We'll address the need for language-focused filters
by enabling them based on browser language configuration. Fingerprinting based
on hardware differences will become more relevant once Vanadium is available
outside of GrapheneOS which will always support a small set of highly secure
devices.</p>
<p>State partitioning still needs to be fully completed. The main remaining
hurdle is providing full cookie partitioning. Mainstream browsers with this
feature rely on heuristics bypassing cookie partitioning which can be easily
abused to bypass the feature. We tried deploying full cookie partitioning by
default but had to roll it back and will need to consider how to approach this
particularly with our goal of having most Vanadium users using nearly the same
configuration.</p>
<p>We plan to move to a better content engine with support for more advanced
filter rules and cosmetic filtering in the future. Expanding the standard
filters will depend on having support for the extensions used by uBlock Origin,
AdGuard and other filters.</p>
<p>Most browser data is currently excluded from OS backups, which will likely be
changed once GrapheneOS has a better backup service included. Export/import for
bookmarks and similar data export/import features are also planned. Sync beyond
OS backup service support which will eventually provide per-app backup and
restore including across devices and via sync services is not planned.</p>
<p>More information is available in the <a href="/usage#web-browsing">web
browsing section of our usage guide</a>.</p>
</section>
<section id="auditor">
<h3><a href="#auditor">Auditor app and attestation service</a></h3>
<p>Our <a href="https://github.com/GrapheneOS/Auditor/releases">Auditor
app</a> and <a href="https://attestation.app/">attestation service</a>
provide strong hardware-based verification of the authenticity and integrity
of the firmware/software on the device. A strong pairing-based approach is
used which also verifies the device's identity based on the
hardware-backed key generated for each pairing. Software-based checks are
layered on top with trust securely chained from the hardware. For more
details, see the <a href="https://attestation.app/about">About</a> and
<a href="https://attestation.app/tutorial">Tutorial</a> pages.</p>
</section>
<section id="grapheneos-camera">
<h3><a href="#grapheneos-camera">GrapheneOS Camera</a></h3>
<p><a href="/usage#grapheneos-camera-app">GrapheneOS Camera</a> is a modern
camera app with a great user interface and a focus on privacy and
security. More details are available in the <a href="/usage#camera">camera
section of our usage guide</a>.</p>
</section>
<section id="grapheneos-pdf-viewer">
<h3><a href="#grapheneos-pdf-viewer">GrapheneOS PDF Viewer</a></h3>
<p><a href="https://github.com/GrapheneOS/PdfViewer">GrapheneOS PDF Viewer</a>
is a sandboxed, hardened PDF viewer using HiDPI rendering with features like
pinch to zoom, text selection, viewing encrypted PDFs, etc.</p>
</section>
<section id="setup-wizard">
<h3><a href="#setup-wizard">Setup Wizard</a></h3>
<p>We have our own Setup Wizard for the initial setup of the device and for user
profiles. It's very similar to the Setup Wizard in the stock Pixel OS but has
more emphasis on security. It detects an unlocked bootloader at the start and
warns the user about it with a button for rebooting to fastboot mode in order to
lock the device. Skipping the warning requires waiting for a timer to prevent
quickly skipping through it and missing the important information. Our setup
wizard also disables OEM unlocking by default at the end of the process with a
toggle to opt-out of it being disabled, which is a small but useful reduction in
attack surface. We plan to include our improvements to lock method options in
our Setup Wizard including 2-factor fingerprint authentication along with
generating random diceware passphrases and PINs automatically.</p>
</section>
<section id="encrypted-backups">
<h3><a href="#encrypted-backups">Encrypted backups</a></h3>
<p>Encrypted backups via integration of the
<a href="https://github.com/GrapheneOS/platform_external_seedvault">Seedvault
app</a> with support for local backups and any cloud storage provider with a
storage provider app.</p>
<p>Seedvault was created by a GrapheneOS community member for inclusion in our
operating system. We plan on replacing it with a new implementation since the
project has been taken over by another group of people not sharing our goals
or approach. For now, this is the best available option, so we're including it
to give people encrypted backup support. We've made several security fixes to
work around upstream issues with the project.</p>
</section>
<section id="location-data-access-indicator">
<h3><a href="#location-data-access-indicator">Location data access indicator</a></h3>
<p>GrapheneOS enables the privacy indicator for location data access in
addition to the standard Android camera and microphone indicators. This shows
an indicator when an app the user has granted permission to access location
requests location data. We also resolve various UX issues with this feature as
it currently exists in AOSP to get it into a highly usable state.</p>
<p>Android 13 has the location privacy indicator as a developer option but it
doesn't work the same way as it does in GrapheneOS. GrapheneOS shows it for
all location data accesses through any APIs. Normally, the stock OS only shows
it for GNSS location requests, also known as high power location requests, and
doesn't normally show it for network location and other APIs gated by the
Location permission / global block toggle.</p>
<p>The indicator works the same way as the Camera and Microphone ones, showing
a bright green icon when location access occurs which then gets minimized to a
small bright green dot when the quick settings tray isn't currently opened.
Android 12 already includes Location with the other standard runtime
permissions in the privacy dashboard for viewing the history.</p>
</section>
<section id="user-installed-apps-can-be-disabled">
<h3><a href="#user-installed-apps-can-be-disabled">User installed apps can be disabled</a></h3>
<p>GrapheneOS adds support for disabling user installed apps instead of only
being able to disable system apps. This allows users to completely prevent one
of the apps they've installed from being able to run without being forced to
uninstall it and lose their app data. This is much stricter than the standard
force stop feature which only prevents an app from starting itself and the app
will start running again as soon as another app tries to open an activity or
service it provides.</p>
</section>
<section id="improved-vpn-leak-blocking">
<h3><a href="#improved-vpn-leak-blocking">Improved VPN leak blocking</a></h3>
<p>GrapheneOS greatly improves Android's protection against VPN leaks for both
the built-in VPN support and VPN apps with the standard "Block connections
without VPN" toggle enabled.</p>
<p>Android allows DNS queries from the system resolver to leak to the network
provided DNS servers when a VPN app goes down due to a race condition. It also
similarly allows connections to the VPN DNS servers to happen outside of the VPN
tunnel. Both of these are fully prevented by GrapheneOS through extending the
leak blocking to this part of the system resolver, fully preventing unicast DNS
leaks.</p>
<p>Android allows processes including apps to bypass the VPN entirely whether
it's up or down by sending multicast packets either directly or by causing the
kernel to send the packets on their behalf through the standard multicast group
management system calls. GrapheneOS extends Android's standard eBPF filtering
with full support for blocking all forms of multicast packet bypasses.</p>
<p>Android VPN configuration is split up for each profile which means work
profiles, Private Spaces and secondary users have their own VPN configuration
which is a fantastic privacy feature. Android has a standard restriction
preventing processes from using a network which the current profile isn't
allowed to access. However, this doesn't take multicast packets into account and
it's possible to send multicast packets via VPN tunnels belonging to a different
profile. GrapheneOS addresses this by extending the standard netfilter
configuration with a multicast firewall preventing sending packets through a VPN
tunnel which a process isn't supposed to be able to access.</p>
<p>Finding and resolving all forms of VPN leaks is one of our top priorities at
the moment and we don't currently consider this to be a complete feature due to
less severe additional issues we've discovered.</p>
</section>
<section id="log-viewer-and-crash-reporting">
<h3><a href="#log-viewer-and-crash-reporting">Log viewer and user-facing crash reporting</a></h3>
<p>GrapheneOS adds a user-facing log viewer to the Settings app for Android's
standard in-memory logging system. The feature acts as a substitute for
automated crash reporting which is not implemented by GrapheneOS for privacy
reasons. Instead, users are in control of what's captured and shared. Our log
viewer supports filtering the output based on log level, log buffers and text
search. Users can copy, share or save the currently shown logs to a file. A
description can be added to document why the logs were captured.</p>
<p>Overall system logs can be accessed at <b>Settings <span aria-label="and then">></span>
System <span aria-label="and then">></span> View logs</b>. Per-app logs can
be accessed at <b>Settings <span aria-label="and then">></span>
Apps <span aria-label="and then">></span> App name <span
aria-label="and then">></span> View logs</b>.</p>
<p>We implement user-facing crash reporting tied to our log viewer for OS and
app crashes, greatly improving upon the very limited user-facing crash reporting
available in Android. This helps users report crashes to the OS or app
developers without requiring invasive automated crash reporting where users
don't control the data that's sent to developers.</p>
<p>Our user-facing crash reporting has special support for memory corruption
caught by hardened_malloc and hardware memory tagging informing users that
memory corruption was detected. Users choose how to proceed and whether it makes
sense to enable our compatibility toggles for the app if they don't believe it
was an exploit but rather an app bug they need to work around. It's a careful
balance between not encouraging users to disable security features protecting
user installed apps from exploits and making it easy to work around app bugs. We
don't allow disabling these exploit protection features for the base OS
including base OS apps, but too many user installed apps have latent memory
corruption bugs and we need to provide the option to work around them.</p>
<p>Users can enable more system crash reporting via <b>Settings <span aria-label="and then">></span>
Security & privacy <span aria-label="and then">></span>
More security & privacy <span aria-label="and then">></span>
Notify about system process crashes</b>. We don't enable reporting all kernel or
system process crashes by default since we can't manage triaging and
investigating every single Android OS bug causing a crash. We're focused on the
memory corruption crashes caught by hardware memory tagging so those are always
reported. Fixing every Android bug ourselves is not something we can hope to
accomplish so we focus our resources on the ones found by our improvements which
also have a higher chance of being security bugs.</p>
</section>
<section id="other-features">
<h3><a href="#other-features">Other features</a></h3>
<p>This is an incomplete list of other GrapheneOS features.</p>
<ul>
<li>Per-profile encrypted file name padding increased from 16 bytes to 32
bytes to reduce the information leaked through file name lengths. See the
FAQ section on <a href="/faq#encryption">the filesystem-based full disk
encryption</a> used by modern Android and GrapheneOS for more information.</li>
<li>Improved user visibility into persistent firmware security through version
and configuration verification with reporting of inconsistencies and debug
features being enabled.</li>
<li>Authenticated encryption for network time updates via a first-party server to
prevent attackers from changing the time and enabling attacks based on bypassing
certificate / key expiry, etc.</li>
<li>Proper support for disabling network time updates rather than just not using
the results</li>
<li>Hardened local build / signing infrastructure</li>
<li><a href="/usage#updates">Seamless automatic OS update system</a> that just
works and stays out of the way in the background without disrupting device
usage, with full support for the standard automatic rollback if the first boot
of the updated OS fails</li>
<li>Require unlocking to access sensitive functionality via quick tiles</li>
<li><a href="/faq#bundled-apps">Minimal bundled apps and services</a>. Only
essential apps are integrated into the OS. We don't make partnerships with
apps and services to bundle them into the OS. An app may be the best choice
today but a poor choice in the future, and vice-versa. Our approach will be recommending certain
apps during the initial setup, not hard-wiring them into the OS.</li>
<li>Wireless alerts are completely optional since GrapheneOS adds a toggle for
the otherwise mandatory presidential alert type. This is particularly
useful in Canada where the government abuses the system and sends every
type of alert as a presidential alert to stop users from being able to opt
out of weather and amber alerts.</li>
<li>Removal of TrustCor root certificate authority as a trusted system CA.</li>
<li>Secure-by-default Android 12 PendingIntent security check (FLAG_IMMUTABLE)
instead of crash-by-default improving older app compatibility and security.</li>
<li>Fixed UART debugging enabled warning on official release builds.</li>
<li>Engineering / Prototype ("EVT", "PVT" or "DVT") device warning as these
devices typically have relaxed security controls for development, mainly
the secure boot state property <code>ro.boot.secure_boot</code> not set
to <code>PRODUCTION</code>.</li>
<li>Enable bootloader, radio, and boot partition version / fingerprint
checks.</li>
<li>Remove code automatically granting the location permission to system
browsers.</li>
<li>Apps that don't have any storage permission aren't allowed to read the
list of all user-created directories (this is allowed on Android). The list of
files is hidden from such apps on both Android and GrapheneOS.</li>
<li>Screenshot shutter sound is toggleable using the <b>Tap & click
sounds</b> option in <b>Settings <span aria-label="and then">></span>
Sound & vibration</b> while still following the standard method of
putting the device on vibration/silent mode to turn off the screenshot shutter
sound.</li>
<li>More precise system clock via lowering the system clock time update
threshold from 2000ms to 50ms and lowering the system clock drift warning
from 2000ms to 250ms. This can be helpful for time-based protocols such as
TOTP.</li>
<li>Call recording functionality within the Dialer app using modern Android
storage with recordings stored in Recordings/Call Recordings and no restrictions based
on region or special cases like playing a recording tone (users are still responsible
for complying with their local laws).</li>
<li>Change standard Android package installer behavior to preserving
packages being disabled after updating them instead of them being
re-enabled.</li>
<li>Enable the "Always-on VPN" and "Block connections without VPN" toggles
for VPNs by default.</li>
<li>Permission prompts and the Android Debug Bridge USB authorization prompt
have the allow action disabled by default with a 1 second delay before it
becomes active. This protects against accidental presses, especially since
an app can trick the user into doing it by having them push a button where
the system dialog will be displayed.</li>
</ul>
</section>
</section>
<section id="services">
<h2><a href="#services">Services</a></h2>
<p>Service infrastructure features:</p>
<ul>
<li>Strict privacy and security practices for our infrastructure</li>
<li>Unnecessary logging is avoided, and logs are automatically purged after 4
days (network services used by the OS) to 10 days</li>
<li>Services are hosted entirely via our own dedicated servers and virtual
machines from OVH (and BuyVM for mirrors) without involving any additional
parties for CDNs, SaaS platforms, mirrors or other services</li>
<li>Our services are built with open technology stacks to avoid being locked into
any particular hosting provider or vendor</li>
<li>Open documentation on our infrastructure including listing out all of our
services, guides on making similar setups, published configurations for each
of our web services, etc.</li>
<li>No proprietary services</li>
<li>Authenticated encryption for all of our services</li>
<li>Strong cipher configurations for all of our services (SSH, TLS, etc.) with
only modern AEAD ciphers providing forward secrecy</li>
<li>Our web sites do not include any third party content and entirely forbid
it via strict Content Security Policy rules</li>
<li>Our web sites disable referrer headers to maximize privacy</li>
<li>Our web sites fully enable cross origin isolation and disable embedding in
other content</li>
<li><a href="https://internet.nl/faqs/dnssec/">DNSSEC</a> implemented for all
of our domains to provide a root of trust for encryption and authentication
for domain/server configuration</li>
<li>DNS Certification Authority Authorization (CAA) records for all of our
domains permitting only Let's Encrypt to issue certificates with fully
integrated support for the <code>accounturi</code> and
<code>validationmethods</code> pinning our Let's Encrypt accounts as the only
ones allowed to issue certificates</li>
<li>DANE TLSA records for pinning keys for all our TLS services</li>
<li>Our mail server enforces DNSSEC/DANE to provide authenticated encryption
when sending mail including alert messages from the attestation service</li>
<li>SSHFP across all domains for pinning SSH keys</li>
<li>Static key pinning for our services in apps like Auditor</li>
<li>No persistent cookies or similar client-side state for anything other than
login sessions, which are set up securely using <code>SameSite=Strict</code>,
<code>Secure</code>, <code>HttpOnly</code>, and <code>Path=/</code> flags, prefixed with
<code>__Host</code> and have server-side session tracking with the ability to log out
of other sessions</li>
<li>scrypt-based password hashing (likely Argon2 when the available implementations
are more mature)</li>
</ul>
</section>
<section id="project">
<h2><a href="#project">Project</a></h2>
<p>Beyond the technical features of the OS:</p>
<ul>
<li>Collaborative, <a href="/source">open source project</a> with a
<a href="/contact#community">very active community</a> and contributors</li>
<li>You can make your own builds and make desired changes, so you aren't stuck with
the decisions made by the upstream project</li>
<li>Non-profit project avoiding conflicts of interest by keeping commercialization
at a distance. Companies support the project
<a href="/faq#company">rather than the project serving the needs of any
particular company</a></li>
<li><a href="/faq#privacy-policy">Strong privacy policies</a> across all our
software and services</li>
<li><a href="/history/">Proven track record</a> of the team standing up
against attempts to compromise the integrity of the project and placing it
above personal gain</li>
</ul>
</section>
</main>
{% include "footer.html" %}
</body>
</html>
|
