[Android Software/Hacking General [Developers Only]] Lanchon:
the default deny strategy is an absolute must. thank you FFU5y, one by one you are obliterating every reason i once had to fork and patch my own pdroid, yay! :)

ideally my phone shouldn't fail. but when it does fail, it's expected and acceptable for it to deny me services. this actually happens to me all the time: my phone provides me complex and bleeding edge services, and thus they fail often; just a price to pay. it can deny me services, but it is absolutely unacceptable for it to fail in a way that leaks my private data. there is no negotiation on this point: in my view pdroid is fundamentally broken by design otherwise.

the privacy service will be a core vital part of my system. if it fails the system is unusable, simple fact. there is no escaping the reality of its importance by defaulting to allow. the phone can fail in a myriad of ways, some will be small annoyances, others will be catastrophic failures. the loss of the privacy service is a catastrophe, as are so many other vital things that can go wrong with our phones.

> Absolutely - emergency call should always, always, always be allowed. Always.

i disagree. in my phone, my privacy is way more important than emergency calls. true, if something that doesn't negatively affect my privacy *at all* can be done to increase the reliability of emergency calls, so be it. otherwise i couldn't care less. a million things can go wrong with my phone to deny me emergency calls: it can freeze (has happened may times), the baseband can freeze (has happened), it can loose vital parts of the UI (has happened), it can boot loop (has happened), it can run out of battery (has happened), it can be crushed and split in two in a car accident (has happened), etc etc. i may never witness a privacy service drop in my life, and yet i'd still be unable to make emergency calls many many times. unless privacy service drops is among the main culprits of emergency call service outages, "fixing" this will not increase emergency call service reliability in any realistic manner. but "fixing" it might destroy pdroid's security, and that is unacceptable.

furthermore: i should be able to deny or fake my location to the emergency service with pdroid if i so choose. this is my phone after all. the fact that a few countries i dont live in have regulations regarding how phones should operate when sold to the public there is not my concern. it wouldn't be even if i live in the states because i'm not selling phones. if a company wants to sell phones with pdroid in them in these countries (yeah right!), let them handle the burden of compliance. we could even help them out, but it's not our battle.

finally there's a question of return on investment: pdroid defends my privacy all the time, but i don't think i have ever made an emergency call in my life. and my privacy *is* important to me. take the already very low probability of needing to make an emergency call. now compound it with the very low probability of the privacy service outing in such a way as to prevent the call at a time when the call would otherwise be possible because, strangely enough, no other needed service is failing, only pdroid is. now multiply that astronomically low probability by the small number of pdroid users. result: there will never ever be a single person affected by this. and even if there ever is, there will probably be another phone nearby. it better be, because there is real chance that her or his phone is busted in this situation already. or maybe just out of juice.

now when the number of pdroid users reaches tens of millions, ok, we can start putting some thought into this because it might then make a difference, somewhere, some time. up until then, privacy is way more important. my advice: don't waste you limited resources on emergency calling; other things that require your attention are more important. sorry, that was too long a rant... :)

back on track. another fatal flaw in PDroid is default allow for new apps. this *has* to go. ideally apps should be frozen until configured. or PDroid should ask a la superuser. but asking might be a very risky affair and too difficult to get right. i've seen many corner cases and strange interactions in superuser, and that has years of development under its belt. (one example: the su prompt popping while the screen is off could freeze the running app forever without ever presenting the allow/deny UI when the screen is later turned on.) my take: a prompt shouldn't be part of the first release; it's a hard problem and it's not core functionality. default deny is enough.

btw, there is another way of handling this case and the privacy service outage case that might merit some thought: instead of allowing or denying, the API could throw an exception, security or other, in a similar way to what would happen if the corresponding permission was revoked. this would likely kill an app that runs before privacy configuration (which is a good thing and close to the ideal auto-freeze behavior), or at least avoid the app from caching incorrect API results.

NOTE: in discussions regarding what to do with unconfigured apps, the handling of preexisting apps (in particular system apps) during installation of pdroid has to be carefully considered.

> the structure I'm thinking would be:

> 1. Try to use privacy service. If the privacy service is not responding/available then

> 2. Use a preference defined in a file on the file system (or probably implemented that way: it makes it pretty reliable, and totally separate from the currently-running Privacy service). The file would be unwritable to anyone except the system, or root.

i oppose to the concept of letting the user choose what to do on a pdroid failure. it is to be expected that some people would set it to allow (i can't understand it but we've witnessed this here on the forum already... hey it's a phone, not an insulin pump! if it dies, is dies; i'll survive :) ). anyway, the fact that some people would presumably set it to allow would create an incentive for a DoS attach on pdroid's privacy service. to avoid this scenario there should be nothing to gain from such an attack: there should be no way to default to allow; such a setting defeats the purpose of pdroid anyway.

> 3. If the file is missing or corrupt, use the hard-coded response

> The question becomes: where does the kill-switch appear in that heirarchy.

in this context, a kill switch after the service would effectively become a default; no switch should be there. a kill switch before the service could work because it doesn't create incentive for an attack. (if implemented, such a switch might be 3-state for completeness and testing purposes: allow-all (kill), deny-all, pass-thru to service.) however, placed there it would impact performance, and i posit that it's not needed and thus its cost isn't justified because we already have the kill switch for free: it's that little restore.zip file that autopatcher creates.

NOTE: default to allow could be implemented transitionally while pdroid is unstable if desired, but should eventually be removed from the stable releases. similarly, a kill switch could be useful in the devel branch but should be disabled for common users; it'd be a debug build feature.

---------- Post added at 11:53 AM ---------- Previous post was at 11:30 AM ----------

> edit: Sorry, are you using PDroid 2.0 or the Syvat's original PDroid? If you're using Syvat's PDroid, then using PDroid Manager for backup and restore will not work, but let me know and I'll think on that.

yes, i'm using pdroid patches and Syvat's PDroid. where do PDroid and PDroid Manager apps store their privacy data? can the apps coexist? can their data coexist?

can i do this?:

1) start with pdroid patches and pdroid 1 app

2) install pdroid manager

3) manually configure pdroid manager's privacy db to mimic pdroid 1's db

4) reboot to recovery, rollback pdroid patches, apply openpdroid patches, reboot

5) uninstall pdroid 1 app

would that work? would it prevent privacy leaks?

> Note: if you're trixy with SQL, then you could dump all the data from the original PDroid database, and then convert it to 'insert' statements to put into OpenPDroid/PDroid 2.0.

in this case i would do a select into query to build the new table from the old.

> However, I should be able to integrate that transition into OpenPDroid.

do you think bloating openpdroid's the code like that is wise? there's another possibility: create a recovery installable zip that migrates the data. so if somebody coming from pdroid is flashing openpdroid for the first time, they can migrate the data by flashing this zip this one time in addition to the openpdroid patches. sounds better than bloating openpdroid to me.

> If you can send me your PDroid database, that would be great: I could then develop/test against it

what do you want? the schema? the complete dataset? i'd have to anonymize some settings; i've got many fake IDs in there.