security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

use explicit sections for all FAQ entries

Browse Source
This commit is contained in:
Daniel Micay 2020-12-06 11:33:17 -05:00
parent edc9cd4cce
commit 2dc47aecf2
1 changed files with 675 additions and 678 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
static/faq.html
View File

@ -113,9 +113,8 @@
<section id="device-support">
<h2><a href="#device-support">Device support</a></h2>
<h3 id="supported-devices">
<a href="#supported-devices">Which devices are supported?</a>
</h3>
<section id="supported-devices">
<h3><a href="#supported-devices">Which devices are supported?</a></h3>
<p>GrapheneOS has official production support for the Pixel 3, Pixel 3 XL, Pixel 3a,
Pixel 3a XL, Pixel 4, Pixel 4 XL and Pixel 4a. The release tags for these devices have
@ -156,10 +155,10 @@
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>
</section>
<h3 id="recommended-devices">
<a href="#recommended-devices">Which devices are recommended?</a>
</h3>
<section id="recommended-devices">
<h3><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 4, Pixel 4 XL and Pixel
@ -175,10 +174,10 @@
expensive flagship devices. You can read more on the differences between the hardware
elsewhere. Unlike the Pixel 3a, the Pixel 4a has a proper SSD which provides a much
better experience with the GrapheneOS exec-based spawning security feature.</p>
</section>
<h3 id="future-devices">
<a href="#future-devices">Which devices will be supported in the future?</a>
</h3>
<section id="future-devices">
<h3><a href="#future-devices">Which devices will be supported in the future?</a></h3>
<p>Devices are carefully chosen based on their merits rather than the project aiming
to have broad device support. Broad device support is counter to the aims of the
@ -211,10 +210,10 @@
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>
</section>
<h3 id="when-devices">
<a href="#when-devices">When will more devices be supported?</a>
</h3>
<section id="when-devices">
<h3><a href="#when-devices">When will more devices be supported?</a></h3>
<p>Broader device support can only happen after the community (companies,
organizations and individuals) steps up to make substantial, ongoing contributions to
@ -239,10 +238,10 @@
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>
</section>
<h3 id="legacy-devices">
<a href="#legacy-devices">Why are older devices no longer supported?</a>
</h3>
<section id="legacy-devices">
<h3><a href="#legacy-devices">Why are older devices no longer supported?</a></h3>
<p>GrapheneOS aims to provide reasonably private and secure devices. It cannot do that
once device support code like firmware, kernel and vendor code is no longer actively
@ -268,14 +267,13 @@
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>
</section>
</section>
<section id="security-and-privacy">
<h2><a href="#security-and-privacy">Security and privacy</a></h2>
<h3 id="clipboard">
<a href="#clipboard">Can apps spy on the clipboard in the background or inject
content into it?</a>
</h3>
<section id="clipboard">
<h3><a href="#clipboard">Can apps spy on the clipboard in the background or inject content into it?</a></h3>
<p>As of Android 10, only the configured default input method editor (your keyboard of
choice) and the currently focused app can access the clipboard. Apps without focus
@ -288,10 +286,10 @@
slightly less strict implementation of this feature. It provided a toggle for users to
whitelist clipboard managers, which is no longer needed now that keyboards are
expected to provide it.</p>
</section>
<h3 id="hardware-identifiers">
<a href="#hardware-identifiers">Can apps access hardware identifiers?</a>
</h3>
<section id="hardware-identifiers">
<h3><a href="#hardware-identifiers">Can apps access hardware identifiers?</a></h3>
<p>As of Android 10, apps cannot obtain permission to access non-resettable hardware
identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial
@ -311,10 +309,10 @@
with limited functionality and hardware acceleration. Hiding the CPU/SoC model would
require not even using basic hardware virtualization support and these things could
probably still be detected via performance measurements.</p>
</section>
<h3 id="non-hardware-identifiers">
<a href="#non-hardware-identifiers">What about non-hardware identifiers?</a>
</h3>
<section id="non-hardware-identifiers">
<h3><a href="#non-hardware-identifiers">What about non-hardware identifiers?</a></h3>
<p>In addition to not having a way to identify the hardware, apps cannot directly
identify the installation of the OS on the hardware. Apps only have a small portion of
@ -375,11 +373,10 @@
However, profiles are the only way to provide a strong assurance of separate
identities since the application model of the OS is designed to support communication
between apps within the same profile, but never between them.</p>
</section>
<h3 id="cellular-tracking">
<a href="#cellular-tracking">What does GrapheneOS do about cellular tracking,
interception and silent SMS?</a>
</h3>
<section id="cellular-tracking">
<h3><a href="#cellular-tracking">What does GrapheneOS do about cellular tracking, interception and silent SMS?</a></h3>
<p>GrapheneOS always considers networks to be hostile and avoids placing trust in
them. It leaves out various carrier apps included in the stock OS granting carriers
@ -437,17 +434,16 @@
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>
</section>
<h3 id="wifi-privacy">
<a href="#wifi-privacy">How private is Wi-Fi?</a>
</h3>
<section id="wifi-privacy">
<h3><a href="#wifi-privacy">How private is Wi-Fi?</a></h3>
<p>See the <a href="/usage#wifi-privacy">usage guide section on Wi-Fi privacy</a>.</p>
</section>
<h3 id="default-connections">
<a href="#default-connections">What kind of connections do the OS and bundled apps
make by default?</a>
</h3>
<section id="default-connections">
<h3><a href="#default-connections">What kind of connections do the OS and bundled apps make by default?</a></h3>
<p>GrapheneOS makes connections to the outside world to test connectivity, detect
captive portals and download updates. No data varying per user / installation / device
@ -572,10 +568,10 @@
everything unnecessary and making our servers the default for handling anything that
cannot simply be shipped with Vanadium for one reason or another such as requiring
quicker updates.</p>
</section>
<h3 id="privacy-policy">
<a href="#privacy-policy">What is the privacy policy for GrapheneOS services?</a>
</h3>
<section id="privacy-policy">
<h3><a href="#privacy-policy">What is the privacy policy for GrapheneOS services?</a></h3>
<p>GrapheneOS services follow the <a href="https://www.eff.org/dnt-policy">EFF's
privacy-friendly Do Not Track (DNT) policy</a> for all users of our publicly available
@ -599,20 +595,20 @@
<p>Our mail server (mail.grapheneos.org) isn't offered as a public service and doesn't
have a privacy policy since it's only used internally by GrapheneOS developers.</p>
</section>
<h3 id="default-dns">
<a href="#default-dns">Which DNS servers are used by default?</a>
</h3>
<section id="default-dns">
<h3><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. VPNs provide their own DNS servers. 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>
</section>
<h3 id="custom-dns">
<a href="#custom-dns">How do I use a custom DNS server?</a>
</h3>
<section id="custom-dns">
<h3><a href="#custom-dns">How do I use a custom DNS server?</a></h3>
<p>It isn't possible to directly override the DNS servers provided by the network via
DHCP. Instead, use the Private DNS feature in Settings ➔ Network &amp; internet ➔
@ -640,10 +636,10 @@
part of fingerprinting users. If you're using a VPN, you should consider using the
standard DNS service provided by the VPN service to avoid standing out from other
users.</p>
</section>
<h3 id="private-dns-ip">
<a href="#private-dns-ip">Why does Private DNS not accept IP addresses?</a>
</h3>
<section id="private-dns-ip">
<h3><a href="#private-dns-ip">Why does Private DNS not accept IP addresses?</a></h3>
<p>By default, in the automatic mode, the Private DNS feature provides opportunistic
encryption by using DNS-over-TLS when supported by the DNS server IP addresses
@ -659,10 +655,10 @@
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>
</section>
<h3 id="private-dns-other">
<a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect other connections?</a>
</h3>
<section id="private-dns-other">
<h3><a href="#private-dns-other">Does DNS-over-TLS (Private DNS) protect other connections?</a></h3>
<p>No, it only provides privacy for DNS resolution. Even authenticating DNS results
with DNSSEC does not protect other connections, unless the DNS records are part of the
@ -673,10 +669,10 @@
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>
</section>
<h3 id="private-dns-visited">
<a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide which sites are visited, etc.?</a>
</h3>
<section id="private-dns-visited">
<h3><a href="#private-dns-visited">Does DNS-over-TLS (Private DNS) hide which sites are visited, etc.?</a></h3>
<p>Private DNS only encrypts DNS, and an adversary monitoring connections can still
see the IP address at the other end of those connections. Many domains resolve to
@ -685,10 +681,10 @@
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>
</section>
<h3 id="vpn-support">
<a href="#vpn-support">What kind of VPN and Tor support is available?</a>
</h3>
<section id="vpn-support">
<h3><a href="#vpn-support">What kind of VPN and Tor support is available?</a></h3>
<p>VPNs can be configured under Settings ➔ Network &amp; Internet ➔ Advanced ➔ VPN.
Support for the following protocols is included: PPTP (insecure, obsolete), L2TP/IPSec
@ -703,10 +699,10 @@
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>
</section>
<h3 id="network-monitoring">
<a href="#network-monitoring">Can apps monitor network connections or statistics?</a>
</h3>
<section id="network-monitoring">
<h3><a href="#network-monitoring">Can apps monitor network connections or statistics?</a></h3>
<p>Apps cannot monitor network connections unless they're made into the active VPN
service by the user. Apps cannot normally access network stats and cannot directly
@ -716,10 +712,10 @@
<p>This was previously part of the GrapheneOS privacy improvements, but became a
standard Android feature with Android 10.</p>
</section>
<h3 id="firewall">
<a href="#firewall">Does GrapheneOS provide a firewall?</a>
</h3>
<section id="firewall">
<h3><a href="#firewall">Does GrapheneOS provide a firewall?</a></h3>
<p>Yes, GrapheneOS inherits the deeply integrated firewall from the Android Open
Source Project, which is used to implement portions of the security model and various
@ -733,10 +729,10 @@
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>
</section>
<h3 id="ad-blocking">
<a href="#ad-blocking">How can I set up system-wide ad-blocking?</a>
</h3>
<section id="ad-blocking">
<h3><a href="#ad-blocking">How can I set up system-wide ad-blocking?</a></h3>
<p>The recommended approach to system-wide ad-blocking is setting up domain-based
ad-blocking as part of DNS resolution. You can do this by
@ -754,10 +750,10 @@
used service like AdGuard with a standard block list is much less of an issue than a
custom set of subscriptions / rules, but it still stands out compared to the default
of not doing it.</p>
</section>
<h3 id="ad-blocking-apps">
<a href="#ad-blocking-apps">Are ad-blocking apps supported?</a>
</h3>
<section id="ad-blocking-apps">
<h3><a href="#ad-blocking-apps">Are ad-blocking apps supported?</a></h3>
<p>Content filtering apps are fully compatible with GrapheneOS, but they have serious
drawbacks and are not recommended. These apps use the VPN service feature to route
@ -783,10 +779,10 @@
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>
</section>
<h3 id="baseband-isolation">
<a href="#baseband-isolation">Is the baseband isolated?</a>
</h3>
<section id="baseband-isolation">
<h3><a href="#baseband-isolation">Is the baseband isolated?</a></h3>
<p>Yes, the baseband is isolated on all of the officially supported devices. Memory
access is partitioned by the IOMMU and limited to internal memory and memory shared
@ -818,6 +814,7 @@
is problematic and a HardMAC implementation with most complexity in the isolated
firmware could be better than the status quo. An isolated driver would be ideal.</p>
</section>
</section>
<section id="day-to-day-use">
<h2><a href="#day-to-day-use">Day to day use</a></h2>