@zyga-snapd is correct. Using ‘browser-support’ with ‘allow-sandbox: false’ with ‘daemon’ grants extra privileges to the snap. On a technical level, this is because the chromium content api wants to set the oom score for its threads and the security policy allows setting the oom score for processes running with the same uid. A snap specifying ‘daemon’ runs as root, and therefore a misbehaving or malicious snap would be able to affect the OOM scores of root running processes on the system, which could destabilize the system.
Specifying ‘browser-support’ with ‘allow-sandbox: true’ grants even more privileges to the snap including many capabilities that are required for the chromium content API’s use of user namespaces.
Note that ‘browser-support’ is a transitional interface but the real issue here IMO is not that browser-support should be specifiable with ‘daemon’, it is that people are using ‘daemon’ because there is no concept of a user session in Core or running session daemons, so people are using the only facility that exists: running a browser as root. The chromium content API’s sandboxing mechanism is designed to work when run as non-root. We should strive to have user session daemons and ultimately the concept of user sessions on Core with autostart non-root services (eg, consider kiosk mode where ideally we want the display server to start and the browser to start and connect to it as non-root).
In the meantime, some time ago I’ve added a facility in the review tools to override this check so it is technically possible to have a snap that uses browser-support with daemon while the technical details of properly supporting session services are worked out. Because this override grants the snap exceptional privilege, snaps in the public store must be vetted to allow the override. For a private store, you need only contact a member of the reviewers team to apply this override for you. (Eg, contact me (jdstrand) on IRC and I can add it).