I'm not questioning the advantages that sandboxing seems to have, in general. What I am questioning is the ability of the development team that couldn't fix Gnome panel for several years to write a secure sandboxing solution, even when relying on cgroups & co..
Either way, I'd much rather run sane applications that patch and pray that neither the application, nor the jail, have any really disastrous bugs.
> This is a vague argumentum ad hominem against a third party. I don't see relevance to my arguments.
Your argument about permissions and sandboxing on Android is that they help privacy because you can feed fake or empty data to the application. I never managed to do that on my phone (but didn't try that hard, either) so I thought I'd see if there was any progress in that field. Xprivacy was the first result that showed up.
The way it does that, apparently, is by extending /system/bin/app_process to load a JAR file on startup, thus attaching itself to every process and replacing any method in any class. Yeah, no thanks. I can't wait to have the first catastrophic exploit in the Xposed framework making every single process vulnerable.
I tried a couple of other solutions a while ago, but most of them ended up crashing or freezing applications.
It is harder to breach two layers of security at the same time than one.
> I know that Xprivacy does that in a way that makes me seriously question its security ( if these guys are correct, at least: http://android.stackexchange.com/questions/59093/how-does-th.... ).
This is a vague argumentum ad hominem against a third party. I don't see relevance to my arguments.
> Not sure about PDroid and other solutions (my phone isn't supported by Cyanogen Mod). But it looks like a big pile of hacks over another big pile of hacks to me.
I don't see your point here in regards to this discussion.