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

use explicit sections in the usage guide

Browse Source
This commit is contained in:
Daniel Micay 2020-12-06 12:16:45 -05:00
parent 5bad5e1b03
commit e995c10a1a
1 changed files with 343 additions and 343 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
static/usage.html
View File

@ -76,14 +76,13 @@
</ul>
</nav>
<h2 id="auditor">
<a href="#auditor">Auditor</a>
</h2>
<section id="auditor">
<h2><a href="#auditor">Auditor</a></h2>
<p>See the <a href="https://attestation.app/tutorial">tutorial page on the site for the attestation sub-project</a>.</p>
</section>
<h2 id="updates">
<a href="#updates">Updates</a>
</h2>
<section id="updates">
<h2><a href="#updates">Updates</a></h2>
<p>The update system implements automatic background updates. It checks for updates
approximately once every four hours when there's network connectivity and then
@ -110,9 +109,8 @@
<p>Release changelogs are available <a href="/releases#changelog">in a section on the releases page</a>.</p>
<h3 id="updates-settings">
<a href="#updates-settings">Settings</a>
</h3>
<section id="updates-settings">
<h3><a href="#updates-settings">Settings</a></h3>
<p>The settings are available in the Settings app in System ➔ Advanced ➔ Update
settings.</p>
@ -140,10 +138,10 @@
device after an update once it has been idle for a long time. When this setting is
enabled, a device can take care of any number of updates completely automatically even
if it's left completely idle.</p>
</section>
<h3 id="updates-security">
<a href="#updates-security">Security</a>
</h3>
<section id="updates-security">
<h3><a href="#updates-security">Security</a></h3>
<p>The update server isn't a trusted party since updates are signed and verified along
with downgrade attacks being prevented. The update protocol doesn't send identifiable
@ -156,10 +154,10 @@
<p>Android updates can support serialno constraints to make them validate only on a
certain device but GrapheneOS rejects any update with a serialno constraint for both
over-the-air updates (Updater app) and sideloaded updates (recovery).</p>
</section>
<h3 id="updates-disabling">
<a href="#updates-disabling">Disabling</a>
</h3>
<section id="updates-disabling">
<h3><a href="#updates-disabling">Disabling</a></h3>
<p>It's highly recommended to leave automatic updates enabled and to configure the
permitted networks if the bandwidth usage is a problem on your mobile data connection.
@ -167,10 +165,10 @@
enabling Show system via the menu, selecting Seamless Update Client and disabling the
app. If you do this, you'll need to remember to enable it again to start receiving
updates.</p>
</section>
<h3 id="updates-sideloading">
<a href="#updates-sideloading">Sideloading</a>
</h3>
<section id="updates-sideloading">
<h3><a href="#updates-sideloading">Sideloading</a></h3>
<p>Updates can be downloaded via
<a href="https://grapheneos.org/releases">the releases page</a> and installed via recovery
@ -202,10 +200,11 @@
trust the attached computer and this can be considered a production feature. Trusting
a computer with ADB access within the OS is much different and exposes the device to a
huge amount of attack surface and control by the trusted computer.</strong></p>
</section>
</section>
<h2 id="web-browsing">
<a href="#web-browsing">Web browsing</a>
</h2>
<section id="web-browsing">
<h2><a href="#web-browsing">Web browsing</a></h2>
<p>GrapheneOS includes a Vanadium subproject providing privacy and security enhanced
releases of Chromium. Vanadium is both the user-facing browser included in the OS and
@ -302,10 +301,10 @@
still substantially weaker (especially on Linux, where it can hardly be considered a
sandbox at all) and lacks support for isolating sites from each other rather than only
containing content as a whole.</p>
</section>
<h2 id="camera">
<a href="#camera">Camera</a>
</h2>
<section id="camera">
<h2><a href="#camera">Camera</a></h2>
<p>The Camera app included in GrapheneOS is very basic and can't take full advantage
of the hardware. It doesn't offer much in the way of configuration. In the long term,
@ -335,10 +334,10 @@
match up the picture and it provides it with more data vs. a traditional HDR
implementation where it essentially doesn't work without a tripod and is not really at
all useful on a phone unless you actually have that for it.</p>
</section>
<h2 id="exec-spawning">
<a href="#exec-spawning">Exec spawning</a>
</h2>
<section id="exec-spawning">
<h2><a href="#exec-spawning">Exec spawning</a></h2>
<p>GrapheneOS creates fresh processes (via exec) when spawning applications instead of
using the traditional Zygote spawning model. This improves privacy and security at the
@ -365,10 +364,10 @@
with privileges reserved for OS components. The Zygote template is reused across user
profiles, so it also provides a temporary set of device identifiers across profiles
for each boot via the shared randomized values.</p>
</section>
<h2 id="bugs-uncovered-by-security-features">
<a href="#bugs-uncovered-by-security-features">Bugs uncovered by security features</a>
</h2>
<section id="bugs-uncovered-by-security-features">
<h2><a href="#bugs-uncovered-by-security-features">Bugs uncovered by security features</a></h2>
<p>GrapheneOS substantially expands the standard mitigations for memory corruption
vulnerabilities. Some of these features are designed to directly catch the memory
@ -401,10 +400,10 @@
relevant crash and filter out information you don't want to send. However, it will be
more difficult to debug if you provide less of the information. If the app doesn't
work with sensitive information, just send the whole tombstone.</p>
</section>
<h2 id="wifi-privacy">
<a href="#wifi-privacy">Wi-Fi privacy</a>
</h2>
<section id="wifi-privacy">
<h2><a href="#wifi-privacy">Wi-Fi privacy</a></h2>
<p>Wi-Fi on GrapheneOS is very privacy-friendly and is essentially anonymous as long
as apps do not leak uniquely identifying information to the network. GrapheneOS avoids
@ -412,9 +411,8 @@
documented (see the FAQ) and can be easily disabled or forced through a VPN
service.</p>
<h3 id="wifi-privacy-scanning">
<a href="#wifi-privacy-scanning">Scanning</a>
</h3>
<section id="wifi-privacy-scanning">
<h3><a href="#wifi-privacy-scanning">Scanning</a></h3>
<p>MAC randomization is always performed for Wi-Fi scanning. Pixel
phones have firmware support for scanning MAC randomization going
@ -437,10 +435,10 @@
planning but we need a robust, secure and private implementation via a local database.
The initial focus will likely be a cell phone tower database, so these features still
wouldn't be relevant.</p>
</section>
<h3 id="wifi-privacy-associated">
<a href="#wifi-privacy-associated">Associated with an Access Point (AP)</a>
</h3>
<section id="wifi-privacy-associated">
<h3><a href="#wifi-privacy-associated">Associated with an Access Point (AP)</a></h3>
<p>The DHCP client uses the anonymity profile rather than sending a hostname so it
doesn't compromise the privacy offered by MAC randomization.</p>
@ -461,10 +459,11 @@
devices have access to both. As of Android 11, Android only uses stable link-local
privacy addresses when MAC randomization is disabled, so we no longer need to disable
the feature.</p>
</section>
</section>
<h2 id="lte-only-mode">
<a href="#lte-only-mode">LTE-only mode</a>
</h2>
<section id="lte-only-mode">
<h2><a href="#lte-only-mode">LTE-only mode</a></h2>
<p>If you have a reliable LTE connection from your carrier, you can reduce attack
surface by disabling 2G / 3G connectivity in Settings ➔ Network &amp; Internet ➔ Mobile
@ -480,6 +479,7 @@
LTE does provide basic network authentication / encryption, but it's for the network
itself. The intention of the LTE-only feature is only hardening against remote
exploitation by disabling an enormous amount of legacy code.</p>
</section>
</main>
<footer>
<a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>