feat: add informational FAQ items

content/FAQ.md

@@ -9,6 +9,9 @@ permalink: /faq
 
 ## [Table of contents](#table-of-contents)
 {: #table-of-contents}
+- [Why secureblue?](#secureblue)
+- [Why not upstream your changes?](#upstream)
+- [Is this an install script?](#script)
 - [Why is Flatpak included? Should I use Flatpak?](#flatpak)
 - [Should I use Electron apps? Why don't they work well with hardened_malloc?](#electron)
 - [My fans are really loud, is this normal?](#fans)
@@ -43,6 +46,22 @@ permalink: /faq
 - [Why doesn't DRM content (spotify, netflix etc.) work in Trivalent?](#trivalent-protected-content)
 - [How do I enable kernel modules?](#enable-kernel-modules)
 
+
+### [Why secureblue?](#secureblue)
+{: #secureblue}
+
+secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, avoiding the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages ([Trivalent](https://github.com/secureblue/Trivalent), [hardened_malloc](https://github.com/GrapheneOS/hardened_malloc), etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies.
+
+### [Why not upstream your changes?](#upstream)
+{: #upstream}
+
+When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take AppImage support as an example. AppImages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since AppImages are widely used, Fedora can’t remove support for them. secureblue is willing make these kinds of changes by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases.
+
+### [Is this an install script?](#script)
+{: #script}
+
+No. When you run our installer, you are *fully replacing* the system. secureblue is not an install script, nor an addon to a Fedora installation, nor a distro in the traditional sense. It is a set of [bootable container](https://github.com/containers/bootc) images shipped via GitHub's container registry. These images are rebuilt daily and pushed to GitHub's container registry. These images are then then pulled in by `rpm-ostree`, which stages updates as a pending deployment for the next boot. To view information about your current local deployments and remotes, run `rpm-ostree status`.
+
 ### [Why is Flatpak included? Should I use Flatpak?](#flatpak)
 {: #flatpak}
 
@@ -279,4 +298,4 @@ DRM-protected content is available in trivalent, however it is disabled by defau
 ### [How do I enable kernel modules?](#enable-kernel-modules)
 {: #enable-kernel-modules}
 
-Some functionality requires you to enable extra kernel modules that are disabled by default in secureblue. Modules can be enabled by running `ujust override-enable-module`. For instance, mounting SMB shares requires the `cifs` and `netfs` kernel modules. To load them, simply run `ujust override-enable-module cifs` and `ujust override-enable-module netfs` then reboot.
+Some functionality requires you to enable extra kernel modules that are disabled by default in secureblue. Modules can be enabled by running `ujust override-enable-module`. For instance, mounting SMB shares requires the `cifs` and `netfs` kernel modules. To load them, simply run `ujust override-enable-module cifs` and `ujust override-enable-module netfs` then reboot.

content/INDEX.md

@@ -6,7 +6,7 @@ permalink: /
 
 ## [About](#about)
 
-secureblue is a security-focused desktop and server Linux operating system, developed as an open-source project. It is shipped as a set of [OCI](https://en.wikipedia.org/wiki/Open_Container_Initiative) bootable container images, which are generated with [BlueBuild](https://blue-build.org/), using [Fedora Atomic Desktop](https://fedoraproject.org/atomic-desktops/)'s [base images](https://pagure.io/workstation-ostree-config) as a starting point. Fedora is one of the few Linux distributions that ships with SELinux and associated tooling built-in and enabled by default. This makes it advantageous as a starting point for building a secure desktop system. However, the security posture of desktop Linux is broadly and significantly lacking. The goal of secureblue is to build a maximally secure Linux operating system by proactively increasing defenses against the exploitation of both known and unknown vulnerabilities, while avoiding sacrificing usability for most use cases where possible. For more details, see the [features list](/features).
+secureblue is a security-focused desktop and server Linux operating system, developed as an open-source project. It is shipped as a set of [OCI](https://en.wikipedia.org/wiki/Open_Container_Initiative) bootable container images, which are generated with [BlueBuild](https://blue-build.org/), using [Fedora Atomic Desktop](https://fedoraproject.org/atomic-desktops/)'s [base images](https://pagure.io/workstation-ostree-config) as a starting point. Fedora is one of the few Linux distributions that ships with SELinux and associated tooling built-in and enabled by default. This makes it advantageous as a starting point for building a secure desktop system. However, the security architecture of desktop Linux is broadly and significantly lacking. The goal of secureblue is to build a maximally secure Linux operating system by proactively increasing defenses against the exploitation of both known and unknown vulnerabilities, while avoiding sacrificing usability for most use cases where possible. For more details, see the [features list](/features).
 
 ## [Who is secureblue for?](#who-is-secureblue-for)
 

content/INSTALL.md

@@ -52,7 +52,7 @@ Before rebasing and during the installation, the following checks are recommende
 ## [Terms of use](#terms)
 {: #terms}
 
-secureblue includes a combination of software packages, each under its own licensing terms. The license of secureblue is the Apache License 2.0. The license of secureblue does not supersede the licenses of code and content contained in secureblue. By downloading secureblue you agree to the license terms of its use.
+secureblue includes a combination of software packages, each under its own licensing terms. The license of secureblue is the Apache License 2.0. The license of secureblue does not supersede the licenses of upstream code and content contained in secureblue images. By downloading secureblue you agree to the license terms of its use.
 
 ```
 Copyright 2024-2025 The secureblue authors