Background: as a design decision, snaps integrate into the system fully (mount namespace notwithstanding) so that admins, users, etc may use ‘ps’, etc to see processes of snaps that are running on the system and be able to interact with them using traditional tooling, etc. As a result, snaps intentionally are not launched within a PID namespace. In addition to integrating more fully into the system, this means we can allow snaps to interact with each other by various means through snappy interfaces because everything is in the global PID namespace (eg, this is why the htop snap works well when the process-control interface is connected).
In terms of confinement today, it is considered a deficiency in the current sandboxing that snaps are able to view certain files in /proc that belong to pids outside of the snap since this constitutes a (minor) information leak (and we document in the security policy where those leaks are so we can come back and fix them in the future and so that auditors/users/etc understand that the current behavior is a known limitation of the confinement). The medium/long term goal is to fix the sandbox to limit the /proc file accesses to those that belong to the snap. With AppArmor, this will come when kernel variable support is implemented and that is being tracked in upstream AppArmor bug https://bugs.launchpad.net/apparmor/+bug/1546825.