From ea5f51aa7dcd1c90cdfbf7993653e664f7bae081 Mon Sep 17 00:00:00 2001 From: Daniel Date: Fri, 17 Jul 2026 17:52:20 +0000 Subject: [PATCH] threads-profile: drop --no-sandbox, re-enable Chromium's own sandbox Verified live on prod (systemd-run with the same User=harbor, NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, ReadWritePaths=/var/lib/harbor as harbor-worker@.service) that Chromium's unprivileged-userns sandbox launches and navigates fine without --no-sandbox; kernel.unprivileged_userns_clone=1 on this host makes it unnecessary. Keeping the browser's own renderer/GPU sandbox gives real defense-in-depth against a malicious/compromised public Threads page, instead of relying on systemd's process-level ProtectSystem alone. Needs a normal release (build-release.sh + activate-release.sh) to reach prod; not hot-patched on the live host. Co-authored-by: Cursor --- apps/backend/scripts/threads-profile/scrape.mjs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/apps/backend/scripts/threads-profile/scrape.mjs b/apps/backend/scripts/threads-profile/scrape.mjs index 1d314d9..0c83d01 100644 --- a/apps/backend/scripts/threads-profile/scrape.mjs +++ b/apps/backend/scripts/threads-profile/scrape.mjs @@ -73,9 +73,13 @@ async function main() { } } + // No --no-sandbox: verified Chromium's own unprivileged-userns sandbox + // launches fine under the worker's systemd hardening (NoNewPrivileges=true + // + ProtectSystem=strict), so keep the renderer/GPU process sandboxed + // instead of trusting ProtectSystem alone against untrusted public pages. const browser = await chromium.launch({ headless: true, - args: ["--disable-blink-features=AutomationControlled", "--no-sandbox"], + args: ["--disable-blink-features=AutomationControlled"], }); try {