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
|
<!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"/>
</head>
<body>
<header>
<nav id="site-menu">
<ul>
<li><a href="/"><img src="{{path|/mask-icon.svg}}" alt=""/>GrapheneOS</a></li>
<li aria-current="page"><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><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="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></li>
<li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li>
<li><a href="#more-complete-patching">More complete patching</a></li>
<li><a href="#disabling-secondary-user-app-installation">Disabling secondary
user app installation</a></li>
<li><a href="#user-installed-apps-can-be-disabled">User installed apps
can be disabled</a></li>
<li><a href="#broad-carrier-support">Broad carrier support without invasive carrier access</a></li>
<li><a href="#private-screenshots">Private screenshots</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 12.1
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>
<ul>
<li>Enhanced <a href="https://source.android.com/security/verifiedboot">verified boot</a>
with better security properties and reduced attack surface</li>
<li>Enhanced hardware-based attestation with more precise version information</li>
<li>Eliminates remaining holes for apps to access hardware-based identifiers</li>
<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, etc.), when the screen is
locked (connecting new USB peripherals, camera access) and optionally after a
timeout (Bluetooth, Wi-Fi)</li>
<li>Option to disable native debugging (ptrace) to reduce local attack surface
(still enabled by default for compatibility)</li>
<li>Low-level improvements to the <a href="/faq#encryption">filesystem-based
full disk encryption</a> used on modern Android</li>
<li>Support creating up to 16 secondary user profiles (15 + guest) instead of
only 4 (3 + guest).</li>
<li>Support for logging out of user profiles without needing a device manager:
makes them inactive so that they can't continue running code while using
another profile and purges the disk encryption keys (which are per-profile)
from memory and hardware registers</li>
<li>Option to enable automatically rebooting the device when no profile has
been unlocked for the configured time period to put the device fully at rest
again.</li>
<li>Modern Microphone/Camera usage indicator UX is also used for Location.</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>Support for longer passwords by default (64 characters instead of 16)
without requiring a device manager</li>
<li>Stricter implementation of the optional fingerprint unlock feature permitting
only 5 attempts rather than 20 before permanent lockout (our recommendation is
still keeping sensitive data in user profiles without fingerprint unlock)</li>
<li>Support for using the fingerprint scanner only for authentication in apps
and unlocking hardware keystore keys by toggling off support for unlocking.</li>
<li>PIN scrambling option</li>
<li><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)</li>
<li><a href="/usage#wifi-privacy-associated">Per-connection MAC randomization
option (enabled by default)</a> as a more private option than the standard
persistent per-network random MAC.</li>
<li>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.</li>
<li>Improved IPv6 privacy addresses to prevent tracking across networks</li>
<li>Vanadium: hardened WebView and default browser — the WebView is what most
other apps use to handle web content, so you benefit from Vanadium in many apps
even if you choose another browser</li>
<li>Apps: first-party GrapheneOS app repository focused on security, which 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.</li>
<li>Hardware-based security verification and monitoring: the
<a href="https://github.com/GrapheneOS/Auditor/releases">Auditor app</a> app 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 provides verification of 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 page</a>
and <a href="https://attestation.app/tutorial">tutorial</a>.</li>
<li><a href="https://github.com/GrapheneOS/PdfViewer">PDF Viewer</a>: sandboxed,
hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection,
etc.</li>
<li><a href="/usage#grapheneos-camera-app">GrapheneOS Camera</a>: modern
camera app with a great user interface and a focus on privacy and
security.</li>
<li>Encrypted backups via integration of the
<a href="https://github.com/seedvault-app/seedvault">Seedvault app</a> with
support for local backups and any cloud storage provider with a storage provider
app</li>
<li><a href="/usage#exec-spawning">Secure application spawning system</a> avoiding
sharing address space layout and other secrets across applications</li>
<li>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.</li>
<li>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.</li>
<li>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. To avoid breaking
compatibility with Android apps, the added permission is enabled by
default.</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>Connectivity checks via a first party server with the option to revert to the
standard checks (to blend in) or to fully disable them</li>
<li>Attestation key provisioning via a first party server with the option to
revert to the standard server</li>
<li>GNSS almanac downloads (PSDS) via a first party server with the option to
revert to the standard server (not available for all GPS vendors yet)</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>Minor changes to 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</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 and poor choice in the future. Our approach will be recommending certain
apps during the initial setup, not hard-wiring them into the OS.</li>
<li>No Google apps and services. These can be used on GrapheneOS but only if
they avoid requiring invasive OS integration. Building privileged support for
Google services into the OS isn't something we're going to be doing, even if
that's partially open source like microG.</li>
</ul>
<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>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 and 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>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>Remote code execution vulnerabilities are the most serious and allow an
attacker to gain a foothold on 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 2 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 difficult 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>
<ul>
<li>Hardened app runtime</li>
<li>Stronger app sandbox</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 Whonix. 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>
</ul>
</li>
<li>Hardened compiler toolchain</li>
<li>
Hardened kernel
<ul>
<li>Support for dynamically loaded kernel modules is disabled and
the minimal set of modules for the device model are built into the
kernel to substantially improve the granularity of Control Flow
Integrity (CFI) and reduce attack surface.</li>
<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>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>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>
</ul>
</li>
<li>Prevention of dynamic native code execution in-memory or via the filesystem
for the base OS without going via the package manager, etc.</li>
<li>Filesystem access hardening</li>
</ul>
</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>The core functionality and APIs are almost entirely supported already since
GrapheneOS largely only has to coerce these apps into continuing to run without
being able to use any of the usual invasive OS integration. A compatibility layer
is also provided to support dynamically downloaded/loaded modules (dynamite
modules). The compatibility layer will be gradually expanded and improved in order
to get more of the Google Play functionality working.</p>
<p>GrapheneOS provides a dedicated compatibility layer for Play Store app
installation/updates/removal teaching it to use the standard unprivileged approach
available to sandboxed apps. It prompts the user to permit it as an app source and
then prompts for the initial app install/update or removal. It will use Android
12's support for unattended updates when possible which means it can do unattended
updates of modern (API 29+) apps where it was the installer for the currently
installed version already.</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="more-complete-patching">
<h3><a href="#more-complete-patching">More complete patching</a></h3>
<p>GrapheneOS includes fixes for many vulnerabilities not yet fixed in
Android. On modern devices with Generic Kernel Image (GKI) support, we the
update kernel to the latest stable GKI release many months before the stock OS
gets the update. This means we're shipping hundreds of fixes not included in
the stock OS including many security fixes. We also backport more fixes on top
of this for the kernel and for other components too.</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="disabling-secondary-user-app-install">
<h3><a href="#disabling-secondary-user-app-installation">Disabling secondary
user app installation</a></h3>
<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="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="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 carriersettings project and other 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="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 Settings ➔ About device ➔ Build number. This leaks the OS,
OS version and also usually the device family/model since builds are usually
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 in order 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 Settings ➔ Privacy since some users may find
it to be useful.</p>
</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 10 days</li>
<li>Services are hosted entirely via our own dedicated servers and virtual
machines from OVH 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 in to
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 experimental <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>Our web services use robust OCSP stapling with Must-Staple</li>
<li>No persistent cookies or similar client-side state for anything other than
login sessions, which are set up via SameSite=strict cookies 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>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>
<footer>
<a href="/"><img src="{{path|/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>
|
