thread-master/apps/backend/scripts/threads-profile
王性驊 ea5f51aa7d 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 <cursoragent@cursor.com>
2026-07-17 17:52:20 +00:00
..
package-lock.json fix frontend 2026-07-13 01:15:30 +00:00
package.json fix frontend 2026-07-13 01:15:30 +00:00
scrape.mjs threads-profile: drop --no-sandbox, re-enable Chromium's own sandbox 2026-07-17 17:52:20 +00:00