docs: add more ADRs (#840)

Author: Proximyst

adrs/0004-chrome.md

@@ -0,0 +1,23 @@
+# ADR-0004: Chrome
+
+## Context and Problem Statement
+
+We need a way to render Grafana dashboards as websites to PDFs and PNGs.
+
+## Considered Options
+
+- Draw the dashboards ourselves using a graphics library.
+- Use Google Chrome (or Chromium, or equivalent Chrome DevTools Protocol browser) to render the dashboards.
+- Use Mozilla Firefox (or equivalent WebDriver Bi-Di Protocol browser) to render the dashboards.
+- Deprecate the feature.
+
+## Decision Outcome
+
+We're going for Chrome DevTools Protocol compliant browsers, primarily Chromium or Google Chrome:
+
+- We do not think it is a wise investment to re-implement all panels and rendering logic.
+- There are currently no good WebDriver Bi-Di clients around in Go.
+- We cannot deprecate the feature, as it is widely used, and we have customers depending on it. This includes ourselves.
+- Chromium is a stable browser with good headless support, and wide adoption.
+- Chromium regularly patches security vulnerabilities.
+- There are Chrome DevTools Protocol clients for Go that are mature.

adrs/0005-sandbox.md

@@ -0,0 +1,26 @@
+# ADR-0005: Sandbox
+
+## Context and Problem Statement
+
+We keep having security incidents due to Chromium's many security vulnerabilities.
+These are patched rapidly, but also so often that it still incurs a lot of work on us.
+
+We need a way to reduce the impact of vulnerabilities to a level where we can either not care, or not care _as much_.
+
+## Considered Options
+
+- Do nothing: keep patching Chromium as vulnerabilities are disclosed.
+- Use Chromium's built-in sandboxing features.
+- Implement our own "just enough" sandbox to run Chromium inside.
+
+## Decision Outcome
+
+We will build our own "just enough" sandbox, and if possible, also implement the Chromium sandbox inside there:
+
+- The current rate of incidents is too high to be sustainable.
+- Chromium's sandbox is strong, but there is still a lot of talk back and forth between the renderer and browser processes.
+  This means that it is not _that_ uncommon to have a sandbox escape.
+- We do not _need_ Chromium's full sandboxing, we only want to ensure that:
+  - Persistence is impossible as processes are killed after use, and the data is gone.
+  - Processes cannot access other customers' data.
+  - Processes should not, but can, be used for utilising our resources maliciously (e.g. cryptocurrency mining).

adrs/0006-crash-only.md

@@ -0,0 +1,23 @@
+# ADR-0006: Crash-Only
+
+## Context and Problem Statement
+
+We run our pods in Kubernetes, and they are pretty memory-intensive as some websites have _a lot_ of data to render.
+As such, it is not uncommon for our pods to either be `OOMKilled`, or to be killed by the scheduler.
+
+We need to decide on how to handle pods' expected life cycles.
+
+## Considered Options
+
+- Model after striving for clean shutdowns.
+- Try to limit crash causes.
+- Just let it crash; every pod is ephemeral, and the only way out is crashing.
+
+## Decision Outcome
+
+We're letting it crash:
+
+- We cannot limit crash causes perfectly. Some requests will cause crashes.
+- Clean shutdowns do not exist in our clusters; sometimes, pods must crash.
+- Crash-only software is a well-documented and proven way to run software,
+  e.g. [_Crash-Only Software_, George Candea & Armando Fox, Stanford University](https://dslab.epfl.ch/pubs/crashonly.pdf).