659 lines
43 KiB
HTML
659 lines
43 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en" prefix="og: http://ogp.me/ns#">
|
|
<head>
|
|
<meta charset="utf-8"/>
|
|
<title>FAQ | GrapheneOS</title>
|
|
<meta name="description" content="Frequently asked questions about GrapheneOS."/>
|
|
<meta name="theme-color" content="#212121"/>
|
|
<meta name="msapplication-TileColor" content="#ffffff"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"/>
|
|
<meta name="twitter:site" content="@GrapheneOS"/>
|
|
<meta name="twitter:creator" content="@GrapheneOS"/>
|
|
<meta property="og:title" content="GrapheneOS FAQ"/>
|
|
<meta property="og:description" content="Frequently asked questions about GrapheneOS."/>
|
|
<meta property="og:type" content="website"/>
|
|
<meta property="og:image" content="https://grapheneos.org/opengraph.png"/>
|
|
<meta property="og:image:width" content="512"/>
|
|
<meta property="og:image:height" content="512"/>
|
|
<meta property="og:image:alt" content="GrapheneOS logo"/>
|
|
<meta property="og:url" content="https://grapheneos.org/faq"/>
|
|
<meta property="og:site_name" content="GrapheneOS"/>
|
|
<link rel="icon" type="image/vnd.microsoft.icon" href="/favicon.ico"/>
|
|
<link rel="mask-icon" href="/mask-icon.svg" color="#1a1a1a"/>
|
|
<link rel="stylesheet" href="/grapheneos.css?17"/>
|
|
<link rel="manifest" href="/manifest.webmanifest"/>
|
|
<link rel="canonical" href="https://grapheneos.org/faq"/>
|
|
<script type="module" src="/redirect.js?6"></script>
|
|
</head>
|
|
<body>
|
|
<nav>
|
|
<ul>
|
|
<li><a href="/">GrapheneOS</a></li>
|
|
<li><a href="/install">Install</a></li>
|
|
<li><a href="/build">Build</a></li>
|
|
<li><a href="/usage">Usage</a></li>
|
|
<li class="active"><a href="/faq">FAQ</a></li>
|
|
<li><a href="/releases">Releases</a></li>
|
|
<li><a href="/source">Source</a></li>
|
|
<li><a href="/donate">Donate</a></li>
|
|
<li><a href="/contact">Contact</a></li>
|
|
</ul>
|
|
</nav>
|
|
<div id="content">
|
|
<h1 id="faq">
|
|
<a href="#faq">Frequently Asked Questions</a>
|
|
</h1>
|
|
|
|
<p>This page contains answers to frequently asked questions about GrapheneOS. It's not
|
|
an overview of the project or a list of interesting topics about GrapheneOS. Many of
|
|
the answers would be nearly the same or identical for the latest release of the
|
|
Android Open Source Project. The goal is to provide high quality answers to some of
|
|
the most common questions about the project, so the developers and other community
|
|
members can link to these and save lots of time while also providing higher quality
|
|
answers.</p>
|
|
|
|
<h2 id="table-of-contents">
|
|
<a href="#table-of-contents">Table of contents</a>
|
|
</h2>
|
|
<ul>
|
|
<li>
|
|
<a href="#device-support">Device support</a>
|
|
<ul>
|
|
<li><a href="#supported-devices">Which devices are supported?</a></li>
|
|
<li><a href="#recommended-devices">Which devices are recommended?</a></li>
|
|
<li><a href="#future-devices">Which devices will be supported in the future?</a></li>
|
|
<li><a href="#when-devices">When will more devices be supported?</a></li>
|
|
<li><a href="#legacy-devices">Why are older devices no longer supported?</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<a href="#security-and-privacy">Security and privacy</a>
|
|
<ul>
|
|
<li><a href="#hardware-identifiers">Can apps access hardware
|
|
identifiers?</a></li>
|
|
<li><a href="#cellular-tracking">What does GrapheneOS do about cellular
|
|
tracking and silent SMS?</a></li>
|
|
<li><a href="#default-connections">Which connections do the OS and
|
|
bundled apps make by default?</a></li>
|
|
<li><a href="#default-dns">Which DNS servers are used by default?</a></li>
|
|
<li><a href="#custom-dns">How do I use a custom DNS server?</a></li>
|
|
<li><a href="#private-dns-ip">Why does Private DNS not accept IP
|
|
addresses?</a></li>
|
|
<li><a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect
|
|
other connections?</a></li>
|
|
<li><a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide
|
|
which sites are visited, etc.?</a></li>
|
|
<li><a href="#vpn-support">What kind of VPN and Tor support is available?</a></li>
|
|
<li><a href="#network-monitoring">Can apps monitor network connections or
|
|
statistics?</a></li>
|
|
<li><a href="#firewall">Does GrapheneOS provide a firewall?</a></li>
|
|
<li><a href="#ad-blocking">How can I set up system-wide ad-blocking?</a></li>
|
|
<li><a href="#ad-blocking-apps">Are ad-blocking apps supported?</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<a href="#day-to-day-use">Day to day use</a>
|
|
<ul>
|
|
<li><a href="#updates">How do I keep the OS updated?</a></li>
|
|
<li><a href="#updates-sideloading">How do I update without giving the
|
|
device internet access?</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a></li>
|
|
<li><a href="#bundled-apps">Why aren't my favorite apps bundled with GrapheneOS?</a></li>
|
|
</ul>
|
|
|
|
<h2 id="device-support">
|
|
<a href="#device-support">Device support</a>
|
|
</h2>
|
|
|
|
<h3 id="supported-devices">
|
|
<a href="#supported-devices">Which devices are supported?</a>
|
|
</h3>
|
|
|
|
<p>GrapheneOS has official production support for the Pixel 2 (legacy), Pixel 2 XL
|
|
(legacy), Pixel 3, Pixel 3 XL, Pixel 3a and Pixel 3a XL. The release tags for these
|
|
devices have official builds and updates available. These devices meet the stringent
|
|
privacy and security standards and have substantial upstream and downstream hardening
|
|
specific to the devices.</p>
|
|
|
|
<p>Many other devices are supported by GrapheneOS at a source level, and it can be
|
|
built for them without modifications to the existing GrapheneOS source tree. Device
|
|
support repositories for the Android Open Source Project can simply be dropped into
|
|
the source tree, with at most minor modifications within them to support GrapheneOS.
|
|
In most cases, substantial work beyond that will be needed to bring the support up to
|
|
the same standards. For most devices, the hardware and firmware will prevent providing
|
|
a reasonably secure device, regardless of the work put into device support.</p>
|
|
|
|
<p>GrapheneOS also supports generic targets, but these aren't suitable for production
|
|
usage and are only intended for development and testing use. For mobile devices, the
|
|
generic targets simply run on top of the underlying device support code (firmware,
|
|
kernel, device trees, vendor code) rather than shipping it and keeping it updated. It
|
|
would be possible to ship generic system images with separate updates for the device
|
|
support code. However, it would be drastically more complicated to maintain and
|
|
support due to combinations of different versions and it would cause complications for
|
|
the hardening done by GrapheneOS. The motivation doesn't exist for GrapheneOS, since
|
|
full updates with deltas to minimize bandwidth can be shipped for every device and
|
|
GrapheneOS is the only party involved in providing the updates. For the same reason,
|
|
it has little use for the ability to provide out-of-band updates to system image
|
|
components including all the apps and many other components.</p>
|
|
|
|
<p>Some of the GrapheneOS sub-projects support other operating systems on a broader
|
|
range of devices. Device support for Auditor and AttestationServer is documented in
|
|
the <a href="https://attestation.app/about">overview of those projects</a>. The
|
|
<a href="https://github.com/GrapheneOS">hardened_malloc</a> project supports nearly
|
|
any Linux-based environment due to official support for musl, glibc and Bionic along
|
|
with easily added support for other environments. It can easily run on non-Linux-based
|
|
operating systems too, and supporting some like HardenedBSD is planned but depends on
|
|
contributors from those communities.</p>
|
|
|
|
<h3 id="recommended-devices">
|
|
<a href="#recommended-devices">Which devices are recommended?</a>
|
|
</h3>
|
|
|
|
<p>The recommended devices with the best hardware, firmware and software security
|
|
along with the longest future support time are the Pixel 3a, Pixel 3a XL, Pixel 3 and
|
|
Pixel 3 XL. The Pixel 3a and 3a XL are budget devices meeting the same security
|
|
standards as the more expensive flagship devices. Compared to the Pixel 3a and 3a XL,
|
|
the flagship Pixel 3 and Pixel 3 XL have wireless charging, dual front-facing speakers,
|
|
the Pixel Visual Core supporting HDR+ with compatible apps on GrapheneOS, IP68 dust
|
|
and water protection, a higher-end screen, slightly more durable glass and of course a
|
|
stronger CPU, GPU, cellular radio, etc. You should get one of the budget devices if
|
|
these things aren't compelling to you. The Pixel 3a and 3a XL do have one extra
|
|
feature: an analog headphone port as an alternative to wireless audio and digital
|
|
USB-C audio.</p>
|
|
|
|
<h3 id="future-devices">
|
|
<a href="#future-devices">Which devices will be supported in the future?</a>
|
|
</h3>
|
|
|
|
<p>Devices are carefully chosen based on their merits rather than the project aiming
|
|
to have broad device support. Broad device support is counter to the aims of the
|
|
project, and the project will eventually be engaging in hardware and firmware level
|
|
improvements rather than only offering suggestions and bug reports upstream for those
|
|
areas. Much of the work on the project involves changes that are specific to different
|
|
devices, and officially supported devices are the ones targeted by most of this
|
|
ongoing work.</p>
|
|
|
|
<p>Devices need to be meeting the standards of the project in order to be considered as
|
|
potential targets. In addition to support for installing other operating systems,
|
|
standard hardware-based security features like the hardware-backed keystores, verified
|
|
boot, attestation and various hardware-based exploit mitigations need to be available.
|
|
Devices also need to have decent integration of IOMMUs for isolating components such
|
|
as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image
|
|
processor, etc., because if the hardware / firmware support is missing or broken,
|
|
there's not much that the OS can do to provide an alternative. Devices with support for
|
|
alternative operating systems as an afterthought will not be considered. Devices need
|
|
to have proper ongoing support for their firmware and software specific to the hardware
|
|
like drivers in order to provide proper full security updates too. Devices that are
|
|
end-of-life and no longer receiving these updates will not be supported.</p>
|
|
|
|
<p>In order to support a device, the appropriate resources also need to be available
|
|
and dedicated towards it. Releases for each supported device need to be robust and
|
|
stable, with all standard functionality working properly and testing for each of the
|
|
releases.</p>
|
|
|
|
<p>Hardware, firmware and software specific to devices like drivers play a huge role
|
|
in the overall security of a device. The goal of the project is not to slightly
|
|
improve some aspects of insecure devices and supporting a broad set of devices would
|
|
be directly counter to the values of the project. A lot of the low-level work also
|
|
ends up being fairly tied to the hardware.</p>
|
|
|
|
<h3 id="when-devices">
|
|
<a href="#when-devices">When will more devices be supported?</a>
|
|
</h3>
|
|
|
|
<p>Broader device support can only happen after the community (companies,
|
|
organizations and individuals) steps up to make substantial, ongoing contributions to
|
|
making the existing device support sustainable. Once the existing device support is
|
|
more sustainable, early research and development work for other devices can begin.
|
|
Once a device is deemed to be a worthwhile target, the project needs maintainers to
|
|
develop and maintain support for it including addressing device-specific issues that
|
|
are uncovered, which will include issues uncovered in the device support code by
|
|
GrapheneOS hardening features.</p>
|
|
|
|
<p>It's not really a matter of time but rather a need for community support for the
|
|
project increasing. As an open source project, the way to get something to happen in
|
|
GrapheneOS is to contribute to it, and this is particularly true for device support
|
|
since it's very self-contained and can be delegated to separate teams for each
|
|
device. If you want to see more devices supported sooner, you should get to work on
|
|
identifying good devices with full support for alternative operating systems with
|
|
verified boot, etc. and then start working on integrating and testing support.</p>
|
|
|
|
<p>It should also be clear that the expectation is for people to buy a device to run
|
|
GrapheneOS, rather than GrapheneOS supporting their existing devices. This will only
|
|
become more true if GrapheneOS is successful enough to accomplish the goal of having
|
|
devices produced based on an SoC reference design with minor improvements for privacy
|
|
and security. Broad device support is the opposite of what the project wants to
|
|
achieve in the long term.</p>
|
|
|
|
<h3 id="legacy-devices">
|
|
<a href="#legacy-devices">Why are older devices no longer supported?</a>
|
|
</h3>
|
|
|
|
<p>GrapheneOS aims to provide reasonably private and secure devices. It cannot do that
|
|
once device support code like firmware, kernel and vendor code is no longer actively
|
|
maintained. Even if the community was prepared to take over maintainance of the open
|
|
source code and to replace the rest, firmware would present a major issue, and the
|
|
community has never been active or interested enough in in device support to consider
|
|
attempting this. Unlike many other platforms, GrapheneOS has a much higher minimum
|
|
standard than simply having devices fully functional, as they also need to provide the
|
|
expected level of security. It would start to become realistic to provide
|
|
substantially longer device support once GrapheneOS controls the hardware and firmware
|
|
via custom hardware manufactured for it. Until then, the lifetime of devices will
|
|
remain based on manufacturer support. It's also important to keep in mind that phone
|
|
vendors claiming to provide longer support often aren't actually doing it and some
|
|
never even ship firmware updates when the hardware is still supported by the
|
|
vendors...</p>
|
|
|
|
<p>GrapheneOS also has high standards for the privacy and security properties of the
|
|
hardware and firmware, and these standards are regularly advancing. The rapid pace of
|
|
improvement has been slowing down, but each hardware generation still brings major
|
|
improvements. Over time, the older hardware starts to become a substantial liability
|
|
and holds back the project. It becomes complex to simply make statements about the
|
|
security of the project when exceptions for old devices need to be listed out. The
|
|
project ends up wanting to drop devices for this reason but has always kept them going
|
|
until the end-of-life date to provide more time for people to migrate.</p>
|
|
|
|
<h2 id="security-and-privacy">
|
|
<a href="#security-and-privacy">Security and privacy</a>
|
|
</h2>
|
|
|
|
<h3 id="hardware-identifiers">
|
|
<a href="#hardware-identifiers">Can apps access hardware identifiers?</a>
|
|
</h3>
|
|
|
|
<p>As of Android 10, apps cannot obtain permission to access non-resettable hardware
|
|
identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial
|
|
numbers and subscriber IDs. Only privileged apps included in the base system with
|
|
<code>READ_PRIVILEGED_PHONE_STATE</code> whitelisted can access these hardware
|
|
identifiers. Apps targeting Android 10 will receive a <code>SecurityException</code>
|
|
and older apps will receive an empty value for compatibility.</p>
|
|
|
|
<p>Since these restrictions became standard, GrapheneOS only makes a small change to
|
|
remove a legacy form of access to the serial number by legacy apps, which was still
|
|
around for compatibility.</p>
|
|
|
|
<h3 id="cellular-tracking">
|
|
<a href="#cellular-tracking">What does GrapheneOS do about cellular tracking and
|
|
silent SMS?</a>
|
|
</h3>
|
|
|
|
<p>GrapheneOS always considers the network to be hostile and does not implement weak
|
|
or useless mitigations. Therefore, it does not have the assorted gimmicks seen elsewhere
|
|
providing privacy/security theatre to make users feel better about these issues. One
|
|
of the core tenets of GrapheneOS is being honest with users and avoiding scams/frills
|
|
based around marketing rather than real world privacy/security threat models.</p>
|
|
|
|
<p>Activating airplane mode will fully disable the cellular radio transmit and receive
|
|
capabilities, which will prevent your phone from being reached from the cellular
|
|
network and stop your carrier (and anyone impersonating them to you) from tracking the
|
|
device via the cellular radio. The baseband implements other functionality such as
|
|
Wi-Fi and GPS functionality, but each of these components is separately sandboxed on
|
|
the baseband and independent of each other. Enabling airplane mode disables the
|
|
cellular radio, but Wi-Fi can be re-enabled and used without activating the cellular
|
|
radio again. This allows using the device as a Wi-Fi only device.</p>
|
|
|
|
<p>Even if interception of the connection or some other man-in-the-middle attack along
|
|
the network is not currently occurring, the network is still untrustworthy and
|
|
information should not be sent unencrypted. Legacy calls and texts should be avoided
|
|
as they're not secure and trust the carrier / network along with having weak security
|
|
against other parties. Trying to detect some forms of interception rather than dealing
|
|
with the root of the problem (unencrypted communications / data transfer) would be
|
|
foolish and doomed to failure.</p>
|
|
|
|
<p>Receiving a silent SMS is not a good indicator of being targeted by your cell
|
|
carrier, police or government because <em>anyone on the cell network can send
|
|
them</em> including yourself. Cellular triangulation will happen regardless of whether
|
|
or not SMS texts are being sent or received by the phone. Even if an SMS did serve a
|
|
useful purpose for tracking, a silent SMS would be little different than receiving
|
|
unsolicited spam. In fact, sending spam would be stealthier since it wouldn't trigger
|
|
alerts for silent SMS but rather would be ignored with the rest of the spam. Regardless,
|
|
sending texts or other data is not required or particularly useful to track devices
|
|
connected to a network for an adversary with the appropriate access.</p>
|
|
|
|
<h3 id="default-connections">
|
|
<a href="#default-connections">What kind of connections do the OS and bundled apps
|
|
make by default?</a>
|
|
</h3>
|
|
|
|
<p>GrapheneOS makes connections to the outside world to test connectivity, detect
|
|
captive portals and download updates. No data varying per user / installation is sent
|
|
in these connections. There aren't analytics / telemetry in GrapheneOS.</p>
|
|
|
|
<p>The expected default connections by GrapheneOS (including all base system apps) are
|
|
the following:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The GrapheneOS Updater app fetches update metadata from
|
|
https://releases.grapheneos.org/DEVICE-CHANNEL approximately once every four hours
|
|
when connected to a permitted network for updates.</p>
|
|
<p>Once an update is available, it tries to download
|
|
https://releases.grapheneos.org/DEVICE-incremental-OLD_VERSION-NEW_VERSION.zip
|
|
for a delta update, and then falls back to
|
|
https://releases.grapheneos.org/DEVICE-ota_update-NEW_VERSION.zip.</p>
|
|
<p>No query / data is sent to the server, so the only information leaked to it
|
|
are the variables in these 3 URLs (device, channel, current version) which is
|
|
necessary to obtain the update.</p>
|
|
<p>Users can control which types of connections the Updater app will use, and
|
|
although it's strongly recommended to always leave it enabled it can be
|
|
disabled.</p>
|
|
</li>
|
|
<li>
|
|
<p>An HTTPS connection is made to https://time.grapheneos.org/ to update the
|
|
time from the date header field. This is a full replacement of Android's
|
|
standard network time update implementation, which uses the cellular network
|
|
when available with a fallback to SNTP when it's not available. This can be
|
|
disabled with the toggle at Settings ➔ System ➔ Date & time ➔ Use
|
|
network-provided time. The time zone is still obtained directly via the time
|
|
zone provided by the mobile network when available.</p>
|
|
</li>
|
|
<li>
|
|
<p>On devices with a Qualcomm baseband (which provides GPS), when location
|
|
functionality is being used,
|
|
<a href="https://en.wikipedia.org/wiki/GPS_signals#Almanac">GPS almanacs</a>
|
|
are downloaded from https://xtrapath1.izatcloud.net/xtra3grc.bin,
|
|
https://xtrapath2.izatcloud.net/xtra3grc.bin or
|
|
https://xtrapath3.izatcloud.net/xtra3grc.bin. GrapheneOS has modified all
|
|
references to these servers to use HTTPS rather than a mix of HTTP and HTTPS.
|
|
No query / data is sent to the server.</p>
|
|
</li>
|
|
<li>
|
|
<p>Connectivity checks designed to mimic a web browser user agent are performed
|
|
by using HTTP and HTTPS to fetch standard URLs generating an HTTP 204 status
|
|
code. This is used to detect when internet connectivity is lost on a network,
|
|
which triggers fallback to other available networks if possible. These checks
|
|
are designed to detect and handle captive portals which substitute the
|
|
expected empty 204 response with their own web page. These need use a very
|
|
common domain and URL in order to bypass whitelisting systems only permitting
|
|
access to common domains / URLs so a domain like grapheneos.org would likely
|
|
be inadequate. GrapheneOS leaves these set to the standard four URLs to blend
|
|
into the crowd of billions of other Android devices with and without Google
|
|
Mobile Services performing the same empty GET requests. For privacy reasons,
|
|
it isn't desirable to stand out from the crowd and changing these URLs or even
|
|
disabling the feature will likely reduce your privacy by giving your device a
|
|
more unique fingerprint. GrapheneOS aims to appear like any other common
|
|
mobile device on the network.</p>
|
|
<ul>
|
|
<li>HTTPS: https://www.google.com/generate_204</li>
|
|
<li>HTTP: http://connectivitycheck.gstatic.com/generate_204</li>
|
|
<li>HTTP fallback: http://www.google.com/gen_204</li>
|
|
<li>HTTP other fallback: http://play.googleapis.com/generate_204</li>
|
|
</ul>
|
|
<p>Standard AOSP user agent for the GET request:</p>
|
|
<p>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36</p>
|
|
<p>No query / data is sent to the servers and the response is unused beyond
|
|
checking the response code.</p>
|
|
<p>Similar connectivity checks are also performed by Vanadium.</p>
|
|
</li>
|
|
<li>
|
|
<p>DNS connectivity and functionality tests</p>
|
|
</li>
|
|
<li>
|
|
<p>DNS resolution for other connections</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3 id="default-dns">
|
|
<a href="#default-dns">Which DNS servers are used by default?</a>
|
|
</h3>
|
|
|
|
<p>By default, the OS uses the network-provided DNS servers, whether those come from
|
|
DHCP or static network configuration. If no DNS servers are provided, GrapheneOS uses
|
|
<a href="https://developers.cloudflare.com/1.1.1.1/what-is-1.1.1.1/">Cloudflare DNS</a>
|
|
as the fallback rather than Google Public DNS. In practice, the fallback is rarely
|
|
used and has little real world impact.</p>
|
|
|
|
<h3 id="custom-dns">
|
|
<a href="#custom-dns">How do I use a custom DNS server?</a>
|
|
</h3>
|
|
|
|
<p>It isn't possible to directly override the DNS servers provided by the network via
|
|
DHCP. Instead, use the Private DNS feature in Settings ➔ Network & internet ➔
|
|
Advanced ➔ Private DNS to set the hostname of a DNS-over-TLS server. It needs to have
|
|
a valid certificate such as a free certificate from Let's Encrypt. The OS will look up
|
|
the Private DNS hostname via the network provided DNS servers and will then force all
|
|
other DNS requests through the Private DNS server. Unlike an option to override the
|
|
network-provided DNS servers, this prevents the network from monitoring or tampering
|
|
with DNS requests/responses.</p>
|
|
|
|
<p>As an example, set the hostname to <code>one.one.one.one</code> for Cloudflare DNS.
|
|
There are various other mainstream DNS-over-TLS options available including Quad9,
|
|
Google and AdGuard.</p>
|
|
|
|
<p>Configuring a static IP address for a network requires entering DNS servers
|
|
manually, but you should still use the Private DNS feature with it, and you shouldn't
|
|
misuse the static IP address option just to override the DNS servers.</p>
|
|
|
|
<p>VPN service apps can also provide their own DNS implementation and/or servers,
|
|
including an alternate implementation of encrypted DNS. Private DNS takes precedence
|
|
over VPN-provided DNS and using Private DNS is still recommended with a VPN.</p>
|
|
|
|
<h3 id="private-dns-ip">
|
|
<a href="#private-dns-ip">Why does Private DNS not accept IP addresses?</a>
|
|
</h3>
|
|
|
|
<p>By default, in the automatic mode, the Private DNS feature provides opportunistic
|
|
encryption by using DNS-over-TLS when supported by the DNS server IP addresses
|
|
provided by the network (DHCP) or the static IP configuration. Opportunistic
|
|
encryption provides protection against a passive listener, not an active attacker,
|
|
since they can force falling back to unencrypted DNS by blocking DNS-over-TLS. In the
|
|
automatic mode, certificate validation is not enforced, as it would provide no
|
|
additional security and would reduce the availability of opportunistic encryption.</p>
|
|
|
|
<p>When Private DNS is explicitly enabled, it uses authenticated encryption without a
|
|
fallback. The authentication is performed based on the hostname of the server, so it
|
|
isn't possible to provide an IP address. The OS will look up the hostname of the Private
|
|
DNS server via unencrypted DNS and then force all other DNS lookups via DNS-over-TLS
|
|
with the identity of the server authenticated as part of providing authenticated
|
|
encryption.</p>
|
|
|
|
<h3 id="private-dns-other">
|
|
<a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect other connections?</a>
|
|
</h3>
|
|
|
|
<p>No, it only provides privacy for DNS resolution. Even authenticating DNS results
|
|
with DNSSEC does not protect other connections, unless the DNS records are part of the
|
|
system used to provide authenticated encryption, and DNS-over-TLS is not a substitute
|
|
for DNSSEC. If connections have authenticated encryption, they're secure even if DNS
|
|
resolution is hijacked by an attacker. If connections do not have authenticated
|
|
encryption, an attacker can listen in and tamper with them without hijacking DNS.
|
|
There are other ways to perform a MITM attack than DNS hijacking and internet routing
|
|
is fundamentally insecure. DNS-over-TLS may make a MITM harder for some attackers, but
|
|
don't count on it at all.</p>
|
|
|
|
<h3 id="private-dns-visited">
|
|
<a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide which sites are visited, etc.?</a>
|
|
</h3>
|
|
|
|
<p>Private DNS only encrypts DNS, and an adversary monitoring connections can still
|
|
see the IP address at the other end of those connections. Many domains resolve to
|
|
ambiguous IP addresses, so encrypted DNS is part of what's required to take away a lot
|
|
of the information leaked to adversaries. However, TLS currently leaks domains via
|
|
SNI, so encrypted DNS is not yet accomplishing much. It's a forward looking feature
|
|
that will become more useful in the future. Using it is recommended, but it's not an
|
|
alternative to using Tor or a VPN.</p>
|
|
|
|
<h3 id="vpn-support">
|
|
<a href="#vpn-support">What kind of VPN and Tor support is available?</a>
|
|
</h3>
|
|
|
|
<p>VPNs can be configured under Settings ➔ Network & Internet ➔ Advanced ➔ VPN.
|
|
Support for the following protocols is included: PPTP (insecure, obsolete), L2TP/IPSec
|
|
PSK, L2TP/IPSec RSA, IPSec Xauth PSK, IPSec Xauth RSA and IPSec Hybrid RSA. Apps can
|
|
also provide userspace VPN implementations and the following open source apps are
|
|
recommended: Orbot (Tor), WireGuard, OpenVPN for Android and the Private Internet
|
|
Access client (OpenVPN).</p>
|
|
|
|
<p>VPN configurations created with the built-in support can be set as the always-on
|
|
VPN in the configuration panel. This will keep the VPN running, reconnecting as
|
|
necessary and will force all connections through them. An app providing a VPN service
|
|
can also be set as the always-on VPN via the entry in the Settings page. For app-based
|
|
VPN implementations, there's also an additional "Block connections without VPN" toggle
|
|
which is needed to prevent leaks when the app's VPN service isn't running.</p>
|
|
|
|
<h3 id="network-monitoring">
|
|
<a href="#network-monitoring">Can apps monitor network connections or statistics?</a>
|
|
</h3>
|
|
|
|
<p>Apps cannot monitor network connections unless they're made into the active VPN
|
|
service by the user. Apps cannot normally access network stats and cannot directly
|
|
request access to them. However, app-based stats can be explicitly granted by users as
|
|
part of access to app usage stats in Settings ➔ Apps & notifications ➔ Special app
|
|
access ➔ Usage access.</p>
|
|
|
|
<p>This was previously part of the GrapheneOS privacy improvements, but became a
|
|
standard Android feature with Android 10.</p>
|
|
|
|
<h3 id="firewall">
|
|
<a href="#firewall">Does GrapheneOS provide a firewall?</a>
|
|
</h3>
|
|
|
|
<p>Yes, GrapheneOS inherits the deeply integrated firewall from the Android Open
|
|
Source Project, which is used to implement portions of the security model and various
|
|
other features. The GrapheneOS project historically made various improvements to the
|
|
firewall but over time most of these changes were been integrated upstream or became
|
|
irrelevant.</p>
|
|
|
|
<p>GrapheneOS adds a user-facing Network permission toggle providing a robust way to
|
|
deny both direct and indirect network access to applications. It builds upon the
|
|
standard non-user-facing INTERNET permission, so it's already fully adopted by the app
|
|
ecosystem. Revoking the permission denies indirect access via OS components and apps
|
|
enforcing the INTERNET permission, such as DownloadManager. Direct access is denied
|
|
by blocking low-level network socket access.</p>
|
|
|
|
<h3 id="ad-blocking">
|
|
<a href="#ad-blocking">How can I set up system-wide ad-blocking?</a>
|
|
</h3>
|
|
|
|
<p>The recommended approach to system-wide ad-blocking is setting up domain-based
|
|
ad-blocking as part of DNS resolution. You can do this by
|
|
<a href="#custom-dns">choosing a Private DNS (DNS-over-TLS) server</a> with support
|
|
for blocking ad domains. As an example, AdGuard DNS can be used by setting
|
|
<code>dns.adguard.com</code> as the Private DNS domain. In the future, GrapheneOS
|
|
plans on adding back <a
|
|
href="https://github.com/GrapheneOS/os_issue_tracker/issues/184">an efficient
|
|
user-defined blacklist for the local DNS resolver</a>. This feature used to be
|
|
included by the project many years ago, but it needs to be reimplemented, and it's a
|
|
low priority feature depending on contributors stepping up to work on it.</p>
|
|
|
|
<h3 id="ad-blocking-apps">
|
|
<a href="#ad-blocking-apps">Are ad-blocking apps supported?</a>
|
|
</h3>
|
|
|
|
<p>Content filtering apps are fully compatible with GrapheneOS, but they have serious
|
|
drawbacks and are not recommended. These apps use the VPN service feature to route
|
|
traffic through themselves to perform filtering.</p>
|
|
|
|
<p>The approach of intercepting traffic is inherently incompatible with encryption
|
|
from the client to the server. The AdGuard app works around encryption by supporting
|
|
optional
|
|
<a href="https://kb.adguard.com/en/general/https-filtering">HTTPS interception</a> by
|
|
having the user trust a local certificate authority, which is a security risk and
|
|
weakens HTTPS security even if their implementation is flawless (which they openly
|
|
acknowledge in their documentation, although it understates the risks). It also can't
|
|
intercept connections using certificate pinning, with the exception of browsers which
|
|
go out of the way to allow overriding pinning with locally added certificate
|
|
authorities. Many of these apps only provide domain-based filtering, unlike the deeper
|
|
filtering by AdGuard, but they're still impacted by encryption due to Private DNS
|
|
(DNS-over-TLS) and require disabling the feature. They could provide their own
|
|
DNS-over-TLS resolver to avoid losing the feature, but few of the developers care
|
|
enough to do that.</p>
|
|
|
|
<p>Using the VPN service to provide something other than a VPN also means that these
|
|
apps need to provide an actual VPN implementation or a way to forward to apps
|
|
providing one, and very few have bothered to implement this. NetGuard is an one
|
|
example implementing SOCKS5 forwarding, which can be used to forward to apps like
|
|
Orbot (Tor).</p>
|
|
|
|
<h2 id="day-to-day-use">
|
|
<a href="#day-to-day-use">Day to day use</a>
|
|
</h2>
|
|
|
|
<h3 id="updates">
|
|
<a href="#updates">How do I keep the OS updated?</a>
|
|
</h3>
|
|
|
|
<p>GrapheneOS has entirely automatic background updates. More details are available in
|
|
the <a href="/usage#updates">the usage guide's updates section</a>.</p>
|
|
|
|
<h3 id="updates-sideloading">
|
|
<a href="#updates-sideloading">How do I update without giving the device internet
|
|
access?</a>
|
|
</h3>
|
|
|
|
<p>Updates can be <a href="/usage#updates-sideloading">sideloaded via
|
|
recovery</a>.</p>
|
|
|
|
<h2 id="anti-theft">
|
|
<a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a>
|
|
</h2>
|
|
|
|
<p>No, since this is strictly a theft deterrence feature, not a security feature, and
|
|
the standard implementation depends on having the device tied to an account on an
|
|
online service. The only advantage would be encouraging thieves to return a stolen
|
|
device for a potential reward after realizing that it has no value beyond scrapping it
|
|
for parts.</p>
|
|
|
|
<p>Google's Factory Reset Protection ties devices to a Google account using a tiny,
|
|
special region of persistent state not wiped by a factory reset. It prevents a thief
|
|
from wiping the device to a fresh state for resale without being stuck at a screen for
|
|
authenticating with the Google account persisted on the device after wiping.</p>
|
|
|
|
<p>It would be possible to make an implementation not reliant upon an online service
|
|
where the user has the option to enable Factory Reset Protection and is given a seed
|
|
phrase required to use the device after wiping data from recovery. However, since this
|
|
has no security value and the ability to deter theft is questionable, implementing
|
|
this is an extremely low priority.</p>
|
|
|
|
<p>Providing the option to disable wiping from recovery would be simpler, but would be
|
|
incompatible with features designed to wipe data automatically in certain cases. This
|
|
will not be implemented by GrapheneOS since it isn't a good approach and it conflicts
|
|
with other planned features.</p>
|
|
|
|
<h2 id="bundled-apps">
|
|
<a href="#bundled-apps">Why aren't my favorite apps bundled with GrapheneOS?</a>
|
|
</h2>
|
|
|
|
<p>There are drawbacks to bundling apps into the OS and few advantages in most cases.
|
|
Rather than GrapheneOS bundling a bunch of apps, it makes far more sense for users to
|
|
install their preferred apps via F-Droid, Aurora Store or other sources. GrapheneOS is
|
|
also working on designing and implementing a first party app update system for a first
|
|
party repository with higher robustness and security than the existing options. Rather
|
|
than bundling apps, it could just offer recommendations as part of an initial setup
|
|
wizard. Users have unique needs and preferences and there has to be a very compelling
|
|
reason to bundle additional apps with the OS. For example, it's useful to have the
|
|
Auditor app available before connecting to the internet (see the
|
|
<a href="/install#verifying-installation">installation guide</a> documentation on
|
|
this).</p>
|
|
|
|
<p>Bundling additional apps with the OS can increase attack surface, unless users go
|
|
out of the way to disable apps they aren't using. Bundling an app into the base OS is
|
|
also painful to reverse, since removing the app without implementing a migration
|
|
mechanism will lose user data stored in the app. Some users are also going to take
|
|
issue with the choices made by the project or will want to make suggestions for
|
|
bundling more apps, and having this as a regular topic of discussion and debate is
|
|
unproductive and distracts from the real work of the project. Each bundled app also
|
|
increases the size of the base OS, and shipping the app updates as part of the OS
|
|
updates results in more overall bandwidth usage. It would be possible to ship only
|
|
out-of-band app updates to avoid wasted bandwidth for apps users have disabled, but
|
|
then the apps would be temporarily out-of-date and vulnerable to patched security
|
|
issues after a factory reset or the user re-enabling them. If the updates aren't going
|
|
to be shipped with the OS, it really makes no sense to bundle them.</p>
|
|
|
|
<p>GrapheneOS is focused on making meaningful improvements to privacy and security,
|
|
and bundling assorted apps into the OS is not only usually outside of that focus but
|
|
often counter to it.</p>
|
|
</div>
|
|
<footer>
|
|
<a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>
|
|
<ul id="social">
|
|
<li><a href="https://twitter.com/GrapheneOS">Twitter</a></li>
|
|
<li><a href="https://github.com/GrapheneOS">GitHub</a></li>
|
|
<li><a href="https://reddit.com/r/GrapheneOS">Reddit</a></li>
|
|
</ul>
|
|
</footer>
|
|
</body>
|
|
</html>
|