> 2) Sandboxes are limiting, but matter. It is way more difficult to freeze > to death or misuse iPhone than Android. That probably goes against > Mer/Sailfish philosophy though.
IMHO: Sandboxing is something that helps for security and QA, and if it's done structurely, it might even help developing and have apps communicate with other apps, because it might even enforce an API for each app. Sandboxing should not interfere with efficiency though... The way i see it, if each app is closed down from the outside, but it has a list of "services" for other apps (think DBUS, or whatnot), and it can use other apps services, and even export a list of permissions for their services (so that the user can inspect or even not give permission for one of the permissions), this could help security alot. of course, some generic "services" and permissions could be supplied from core apps or even system itself... a list of permissions and API stuff for services of each app, will also alow other people to see what kind of communication is possible with other apps, without even looking at their code or even documentation... it might even help in this way to create ideas that are original. plus, it will help security and find misbehaving apps... running as their own user in a separate cgroup is a first step, imho (policykit could give extra access where needed), but this general security would help for example with rpm's being emailed to sailfishos devices... if those apps are installed, at least they will be kept separate from the system... _______________________________________________ SailfishOS.org Devel mailing list
