fix header levels for nested sections

This commit is contained in:
Daniel Micay 2020-02-19 17:58:05 -05:00
parent dcc5003ee5
commit e18706ee00

View File

@ -74,9 +74,9 @@
<a href="#device-support">Device support</a>
</h2>
<h2 id="supported-devices">
<h3 id="supported-devices">
<a href="#supported-devices">Which devices are supported?</a>
</h2>
</h3>
<p>GrapheneOS has official production support for the Pixel 2, Pixel 2 XL, Pixel 3,
Pixel 3 XL, Pixel 3a and Pixel 3a XL. The release tags for these devices have official
@ -114,9 +114,9 @@
operating systems too, and supporting some like HardenedBSD is planned but depends on
contributors from those communities.</p>
<h2 id="recommended-devices">
<h3 id="recommended-devices">
<a href="#recommended-devices">Which devices are recommended?</a>
</h2>
</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
@ -130,9 +130,9 @@
feature: an analog headphone port as an alternative to wireless audio and digital
USB-C audio.</p>
<h2 id="future-devices">
<h3 id="future-devices">
<a href="#future-devices">Which devices will be supported in the future?</a>
</h2>
</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
@ -166,9 +166,9 @@
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>
<h2 id="when-devices">
<h3 id="when-devices">
<a href="#when-devices">When will more devices be supported?</a>
</h2>
</h3>
<p>Broader device support can only happen after the community (companies,
organizations and individuals) steps up to make substantial, ongoing contributions to
@ -194,9 +194,9 @@
and security. Broad device support is the opposite of what the project wants to
achieve in the long term.</p>
<h2 id="legacy-devices">
<h3 id="legacy-devices">
<a href="#legacy-devices">Why are older devices no longer supported?</a>
</h2>
</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
@ -226,9 +226,9 @@
<a href="#security-and-privacy">Security and privacy</a>
</h2>
<h2 id="hardware-identifiers">
<h3 id="hardware-identifiers">
<a href="#hardware-identifiers">Can apps access hardware identifiers?</a>
</h2>
</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
@ -240,10 +240,10 @@
<p>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>
<h2 id="default-connections">
<h3 id="default-connections">
<a href="#default-connections">What kind of connections do the OS and bundled apps
make by default?</a>
</h2>
</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
@ -323,10 +323,10 @@
</li>
</ul>
<h2 id="cellular-tracking">
<h3 id="cellular-tracking">
<a href="#cellular-tracking">What does GrapheneOS do about cellular tracking and
silent SMS?</a>
</h2>
</h3>
<p>GrapheneOS always considers the network to be hostile and does not implement weak
or useless mitigations. Therefore, it does not have a assorted gimmicks seen elsewhere