summaryrefslogtreecommitdiff
path: root/static
diff options
context:
space:
mode:
authorDaniel Micay <danielmicay@gmail.com>2020-03-09 20:24:46 -0400
committerDaniel Micay <danielmicay@gmail.com>2020-03-09 20:25:46 -0400
commitf1f2e6e508b5fcaefc7b4157f105597b6263f9c1 (patch)
tree71d4eef2fbb5b387c824fa325cb67575b96293bf /static
parent61e3ad9e228258bf75e4d9299c3df419594766e3 (diff)
add anti-theft to FAQ
Diffstat (limited to 'static')
-rw-r--r--static/faq.html27
1 files changed, 27 insertions, 0 deletions
diff --git a/static/faq.html b/static/faq.html
index 50d5d277..d153981a 100644
--- a/static/faq.html
+++ b/static/faq.html
@@ -96,6 +96,7 @@
<li><a href="#updates">How do I keep the OS updated?</a></li>
</ul>
</li>
+ <li><a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a></li>
</ul>
<h2 id="device-support">
@@ -580,6 +581,32 @@
<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 optional 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>
</div>
<footer>
<a href="/"><img src="https://grapheneos.org/logo.png" width="512" height="512" alt=""/>GrapheneOS</a>