From 4544a90b6ee25be552a7bf82fd6d5c18e6bbd05e Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Sat, 11 Dec 2021 18:25:28 +0100
Subject: Edit FAQ

---
 docs/FAQ.md | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

(limited to 'docs/FAQ.md')

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 7869ee61..52b2d8dc 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -33,6 +33,19 @@ If you find an interesting or important question missing, submit it via
   Report](https://www.fuzzbench.com/reports/2020-08-03/index.html).
 </p></details>
 
+<details>
+  <summary id="is-afl-a-whitebox-graybox-or-blackbox-fuzzer">Is AFL++ a whitebox, graybox, or blackbox fuzzer?</summary><p>
+
+  The definition of the terms whitebox, graybox, and blackbox fuzzing varies
+  from one source to another. For example, "graybox fuzzing" could mean
+  binary-only or source code fuzzing, or something completely different.
+  Therefore, we try to avoid them.
+
+  [The Fuzzing Book](https://www.fuzzingbook.org/html/GreyboxFuzzer.html#AFL:-An-Effective-Greybox-Fuzzer)
+  describes the original AFL to be a graybox fuzzer. In that sense, AFL++ is
+  also a graybox fuzzer.
+</p></details>
+
 <details>
   <summary id="where-can-i-find-tutorials">Where can I find tutorials?</summary><p>
 
@@ -126,6 +139,16 @@ If you find an interesting or important question missing, submit it via
 
 ## Performance
 
+<details>
+  <summary id="what-makes-a-good-performance">What makes a good performance?</summary><p>
+
+  Good performance generally means "making the fuzzing results better". This can
+  be influenced by various factors, for example, speed (finding lots of paths
+  quickly) or thoroughness (working with decreased speed, but finding better
+  mutations).
+
+</p></details>
+
 <details>
   <summary id="how-can-i-improve-the-fuzzing-speed">How can I improve the fuzzing speed?</summary><p>
 
@@ -146,8 +169,8 @@ If you find an interesting or important question missing, submit it via
   the edge coverage result will be different across runs. Those edges that
   change are then flagged "unstable".
 
-  The more "unstable" edges, the more difficult for AFL++ to identify valid new
-  paths.
+  The more "unstable" edges there are, the harder it is for AFL++ to identify
+  valid new paths.
 
   A value above 90% is usually fine and a value above 80% is also still ok, and
   even a value above 20% can still result in successful finds of bugs. However,
-- 
cgit 1.4.1


From 4ce1ec3219a891f9d41b59155c51ae5c089f4113 Mon Sep 17 00:00:00 2001
From: llzmb <46303940+llzmb@users.noreply.github.com>
Date: Sat, 11 Dec 2021 18:27:38 +0100
Subject: Remove blank line

---
 docs/FAQ.md | 1 -
 1 file changed, 1 deletion(-)

(limited to 'docs/FAQ.md')

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 52b2d8dc..f1cffe00 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -146,7 +146,6 @@ If you find an interesting or important question missing, submit it via
   be influenced by various factors, for example, speed (finding lots of paths
   quickly) or thoroughness (working with decreased speed, but finding better
   mutations).
-
 </p></details>
 
 <details>
-- 
cgit 1.4.1