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

add initial legacy devices section

Browse Source
This commit is contained in:
Daniel Micay 2020-02-19 14:55:49 -05:00
parent eaa01c67ae
commit 64837579a3
5 changed files with 36 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
static/faq.html
View File

@ -54,6 +54,7 @@
<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>
@ -191,6 +192,34 @@
and security. Broad device support is the opposite of what the project wants to
achieve in the long term.</p>
<h2 id="legacy-devices">
<a href="#legacy-devices">Why are older devices no longer supported?</a>
</h2>
<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>

2
static/index.html
View File

@ -114,6 +114,6 @@
<li><a href="https://reddit.com/r/GrapheneOS">Reddit</a></li>
</ul>
</footer>
<script src="/redirect.js?2"></script>
<script src="/redirect.js?3"></script>
</body>
</html>

4
static/redirect.js
View File

@ -13,6 +13,10 @@
const redirects = new Map([
["/#device-support", "/faq#device-support"],
["/usage#default-connections", "/faq#default-connections"],
["/releases#marlin-stable", "/faq#legacy-devices"],
["/releases#sailfish-stable", "/faq#legacy-devices"],
["/releases#marlin-beta", "/faq#legacy-devices"],
["/releases#sailfish-beta", "/faq#legacy-devices"],
]);
function handle_hash() {

1
static/releases.html
View File

@ -1010,5 +1010,6 @@
</ul>
</footer>
<script src="/releases.js?11"></script>
<script src="/redirect.js?3"></script>
</body>
</html>

2
static/usage.html
View File

@ -335,6 +335,6 @@
<li><a href="https://reddit.com/r/GrapheneOS">Reddit</a></li>
</ul>
</footer>
<script src="/redirect.js?2"></script>
<script src="/redirect.js?3"></script>
</body>
</html>