fix(gui): run the CAPTCHA page in its own process (B195)

On secureblue, WebKit cannot start the sandbox for the verification page:
bubblewrap is kept from the journal socket, xdg-dbus-proxy fails, and
WebKit ends its process with g_error. The webview lived in pdfs-app, so
the whole app crashed after the sign-in (#29).

- gui: `pdfs-app --human-verification` shows the page in its own window,
  reads the URL on stdin and prints the token on stdout; its logs go to
  stderr
- gui: a child that dies or fails without a token ends the sign-in with a
  message that the page could not be opened, instead of "cancelled"
- i18n: translate the new message in every catalog
- docs: B195 in the bug ledger, the cause and a one-time workaround in
  TROUBLESHOOTING.md, the child process in ARCHITECTURE.md, changelog

docs/ARCHITECTURE.md

@@ -542,7 +542,7 @@ sequenceDiagram
     actor User
     participant UI as pdfs-app
     participant Auth as pdfs-core auth
-    participant Web as WebKitGTK dialog
+    participant Web as pdfs-app --human-verification
     participant API as Proton API
 
     User->>UI: email and password
@@ -550,9 +550,9 @@ sequenceDiagram
     Auth->>API: SRP handshake
     API-->>Auth: 9001, challenge URL
     Auth-->>UI: HumanVerificationRequired
-    UI->>Web: load challenge
+    UI->>Web: challenge URL (stdin)
     User->>Web: solve it
-    Web-->>UI: token (postMessage)
+    Web-->>UI: token (stdout)
     UI->>Auth: login_verified(token)
     Auth->>API: new SRP handshake with the token
     API-->>Auth: session
@@ -561,6 +561,9 @@ sequenceDiagram
 - The challenge used up the first SRP handshake, so the retry starts a new one with the token
   attached.
 - The page may post the token as an object or as a JSON string; both are accepted.
+- The page runs in a WebKitGTK view inside a child `pdfs-app`. WebKit aborts its process when its
+  sandbox cannot start, as on hardened systems such as secureblue (B195). In the child, that ends
+  the verification, and the app says why, instead of closing the app.
 - The CLI has no web view. It fails with a message to sign in once with `pdfs-app`; the stored
   session then works for the CLI and the service.
 

docs/BUGS.md

@@ -47,7 +47,7 @@ original wording.
    it in the index in the same change.
 
 ```markdown
-### B195 — What the user sees, in one line
+### B196 — What the user sees, in one line
 
 **Status:** Open
 **Found:** 2026-10-06, how it was found
@@ -100,6 +100,7 @@ a live account since.
 
 | Entry | Title |
 |---|---|
+| [B195](#b195--the-app-crashes-when-proton-asks-for-a-captcha-on-secureblue) | The app crashes when Proton asks for a CAPTCHA on secureblue |
 | [B193](#b193--deleting-a-file-whose-create-failed-can-trash-a-file-of-the-users-on-drive) | Deleting a file whose create failed can trash a file of the user's on Drive |
 | [B191](#b191--a-file-deleted-after-its-create-failed-and-was-written-again-can-stay-on-drive) | A file deleted after its create failed and was written again can stay on Drive |
 | [B190](#b190--a-file-saved-just-before-the-daemon-stops-can-keep-its-old-content-on-drive) | A file saved just before the daemon stops can keep its old content on Drive |
@@ -297,6 +298,36 @@ a live account since.
 
 Newest first.
 
+### B195 — The app crashes when Proton asks for a CAPTCHA on secureblue
+
+**Status:** Fixed (unverified). Nobody has run the fix on secureblue yet.
+**Found:** 2026-10-07, [#29](https://github.com/narrrl/proton-drive-linux/issues/29). On
+secureblue 44 (a hardened Fedora Atomic), `pdfs-app` aborted a few seconds after the sign-in, with
+`bwrap: Can't get type of source /run/systemd/journal/socket: Permission denied` and
+`Failed to fully launch dbus-proxy`.
+**Where:** `crates/pdfs-gui/src/app/pages/verify.rs`, `crates/pdfs-gui/src/app/pages/login.rs`
+
+**Repro:** Sign in on secureblue from a network Proton asks a CAPTCHA for, such as a VPN.
+
+**Cause.** The CAPTCHA page runs in a WebKitGTK view (B8). Before it loads anything, WebKit starts
+its sandbox: bubblewrap, with the journal socket bound in, and `xdg-dbus-proxy`. secureblue keeps
+bubblewrap from the socket, the proxy does not start, and WebKit ends its process with `g_error`.
+The view was in the app's own process, so the whole app went down, and nothing in our code can
+catch that.
+
+**Fix.** The view runs in a child, `pdfs-app --human-verification`, that reads the URL on stdin
+and prints the token on stdout. A child that exits without a token after a crash or a non-zero
+status ends the sign-in with a message that says the page could not be opened. TROUBLESHOOTING.md
+gives the cause and a one-time workaround. The sandbox is not switched off by the app: users choose
+a hardened system for that isolation.
+
+**Test:** unit tests `a_window_that_died_fails`, `a_window_closed_without_a_token_cancels`,
+`a_token_counts_even_if_the_window_died_after_it` and `the_token_is_found_among_other_output`.
+On 2026-10-08 the child ran under real WebKit on Arch against a local page that posts a completion,
+and handed back its token.
+
+---
+
 ### B194 — On a fresh install the tray exits and the Takeout page cannot remember its archives
 
 **Status:** Fixed.

docs/CHANGELOG.md

@@ -12,6 +12,11 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
 ## [Unreleased]
 
 ### Fixed
+- **The app crashed when Proton asked for a CAPTCHA on hardened systems.** On secureblue, WebKit
+  cannot start the sandbox for the verification page and ends its process, which took the app
+  down with it. The page now opens in a separate window process: if that process fails, the
+  sign-in stops with a message that says why, and TROUBLESHOOTING.md has a workaround.
+  ([#29](https://github.com/narrrl/proton-drive-linux/issues/29))
 - **On a fresh install the tray icon did not start.** The tray and the app now create their state
   directory themselves instead of waiting for the service to do it. This also lets the Takeout
   page remember staged archives before the first mount.

docs/TROUBLESHOOTING.md

@@ -72,6 +72,20 @@ pdfs status
 unfamiliar network. The CLI cannot show it. Sign in with `pdfs-app`, which displays the challenge;
 the stored session then works for the CLI too.
 
+**"The verification page couldn't be opened"** — WebKit, which shows the CAPTCHA page, could not
+start its sandbox. Hardened systems such as secureblue keep its bubblewrap from the journal socket,
+and the log then shows `bwrap: Can't get type of source /run/systemd/journal/socket: Permission
+denied` and `Failed to fully launch dbus-proxy`. Check that `bwrap` and `xdg-dbus-proxy` are
+installed. If they are, sign in once with the sandbox switched off for this one run:
+
+```bash
+WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 pdfs-app
+```
+
+Quit the app first, so this starts a new instance. The page then runs without WebKit's isolation,
+so use this only for the sign-in. The stored session keeps working without it. Signing in from
+your usual network, without a VPN, often avoids the CAPTCHA in the first place.
+
 **Sign-in works but is forgotten after a restart** — no Secret Service provider is running, or its
 keyring is locked. Install and unlock GNOME Keyring, KWallet or KeePassXC (with Secret Service
 enabled). `pdfs diagnose` shows `keyring session` as failing in that case.