``` name: iris-browser description: Iris, a hardened browser built on Chromium for security and privacy. No accounts, no telemetry, JIT off for websites, encrypted DNS, built-in ad and tracker blocking. snapcraft: iris/packaging/snap/snapcraft.yaml at main · jegly/iris · GitHub upstream: GitHub - jegly/iris: A security-focused browser hardened at compile time: JIT-less JavaScript, WebRTC/WebGPU/WebAssembly off, fingerprinting APIs removed, CFI + stack hardening, encrypted DNS, built-in ad blocking. · GitHub upstream-relation: maintainer (I am the author of Iris; the snap is built from my own release .deb) plugs: browser-sandbox: interface: browser-support attributes: allow-sandbox: true request-type: manual-connection reasoning: lets users who want it turn on Chromium’s renderer sandbox inside the snap (see below). Not asking for auto-connection. slots: mpris: attributes: name: chromium request-type: auto-connection reasoning: media keys and desktop media controls. Chromium registers org.mpris.MediaPlayer2.chromium.instance, so the slot name is “chromium”, as in the chromium snap. Happy to change it if you prefer. ```
**To answer the usual question first:** no, Iris doesn’t lose functionality without the Chromium sandbox. I read the growser thread and I’m not asking for auto-connection, and I’ve dropped the setuid chrome-sandbox: as shown there, it isn’t needed in the snap once allow-sandbox is available.
**How the snap behaves:**
- By default the interface is not connected and Iris runs under strict confinement with `–no-sandbox`, as you recommend for Chromium-based snaps. Nothing extra is granted.
- A user who runs `snap connect iris-browser:browser-sandbox` gets Chromium’s renderer sandbox inside the snap as well. The launcher checks `snapctl is-connected browser-sandbox` and only drops `–no-sandbox` when it’s connected.
**Why I’d like to offer it:** snap confinement protects the system from the browser, and that stays in place either way. What it can’t do is separate a compromised renderer from the rest of the browser inside the snap: the user’s cookies, saved sessions and the files the snap can reach. For a privacy-focused browser, that boundary is the reason some users pick it, so I’d like to let them choose it, with the default staying exactly as you advise.
Canonical’s chromium snap declares the same plug (`browser-support` with `allow-sandbox: true`).
Revision 2 can be dropped; the next revision will match this request (no setuid file, launcher fallback as described). Happy to upload it for inspection first.
Thanks for your time.
