[Android Software/Hacking General [Developers Only]] Lanchon:
thanks FFU5y, i really appreciate you taking the time to give detailed, thoughtful answers.

after reading everything, this is my humble take on the error handling situation:

-i don't want anything but default-to-deny. a selectable default creates pressure to DoS attack PDroid and default-to-allow is completely useless IMHO; no price should be payed for something completely useless.

-if anything, pdroid may have an override, not a default. if pdroid is busted, u disable it and make your precious calls, emergency or otherwise. again, no default allow. the override could be allow or deny. (denying everything could temporarily be useful while u operate on the settings database, say restoring it, or migrating it (my case!).) a kill switch, flashing restore.zip, is already there (for autopatcher releases at least) but many find it inappropriate. i fully understand that position, but everyone must understand that any overrides will hit performance. the idea of having overrides only on devel builds didnt get any traction here, so i accept both possibilities: having the override or not having it are both fine by me.

> I have mixed feelings about this. I can see your point - if an attack on the privacy service would sometimes work, the motivation is much greater than if it would never work. Keep in mind, though, that the file containing the 'fallback' action would have to be readable by everyone - i.e. attack code could actually check if it would work or not.

no, this cannot be. so i'd be DoS'd all the same regardless my setting, even if to encourage me to kill-switch pdroid, if a DoS attack is found feasible. but that doesnt enter into it. a very important point (having much to do with PAC, permissions, manager apps, etc) is that pdoid must be undetectable, rootkit style if necessary. otherwise (if pdroid ends up being massively successful, and i doubt it but i hope it does) some apps will attack it by disabling themselves if pdroid is detected in the system. we've seen this behavior in other platforms with debuggers and many tools that "threaten" the developer's intentions. so pdroid isnt, and shouldnt be, undetectable now, but we should make architectural decisions that in the future wont get in the way of making it undetectable. so the file, if it's a file, containing the fallback action must not be visible to anybody.

> Anyway, I think having an option to "default allow" is important, so long as it doesn't lead to data leakage when the "default deny" option is chosen. I think there probably needs to be a "kill switch" to entirely disable PDroid, in case all hell has broken loose, the PDroid service is working fine, but you don't have time to dig through specific settings to disable the block - e.g. need to make emergency call, and you have accidentally blocked phone calls from the phone app.

default-to-allow is horrible. besides what ive already said, it masks failures. people wouldn't even know something is up. give them the override but make them choose to flip it and thus make them consent and be informed of the situation. someone enabling default allow would shoot herself in the foot, ok, serves her right. but what about all the strange behavior, the irreproducible bug reports, the headaches this will bring to the pdroid team? she wouldn't be just shooting herself in the foot, pdroid itself might end up getting a bad rep for being unreliable.

in the end, it doesn't hurt me much if u implement selectable default, and i think it'll actually help everybody if u dont. but when i do software, im a bit of tyrant: after listening to everybody, i do what i think is best for the project even if many people don't like it. after all there's a reason why im taking those decisions and not them. so without trying to push u in any direction, i just wanna state the obvious fact that no matter what u do, some people won't like it. so in the end its not a question of catering to everybody's will, but to choose yourself and make pdroid as well as u can, in your view, and most than ever in a free project, that's your hobby and your child without strings. so what's best for the project? where should your limited time go? choose, play and enjoy :) these details are, after all, only the frosting of an amazingly tasty cake u r cooking.

> Finally, what do people think about having hard-coded functionality to always allow 112 calls from com.phone.android, irrespective of any settings at all? Basically, that would be the super-emergency-override-someone-picked-up-your-phone-from-your-bleeding-body-and-needs-to-call-you-an-ambulance override.

IMHO: horrible hack that i wouldn't want in my phone. horrible waste of your time to implement this. probably ends up being hacky dirty and brittle. if my phone ever can't dial i'll fix it somehow immediately, i wont go on for weeks in that situation and then go and have an emergency. and if i do and there's really no other phone around (what are the odds of all this??!) then id kill-switch pdroid.

> What about an option to make a list of phone numbers that user could add to from the kill switch app.

horrible code bloat. and if we can read such a configuration then we neednt, cause pdroid is working.

regarding the PAC affair:

> Basically, you can have it 'normal' in which case any app can request the permission (which is bad, unless additional security mechanisms such as PAC are used, because any old app can demand that permission and then modify security settings).

well if u want to have selectable managers, PAC is an option. another option is the existing free code i mentioned that works similarly to PAC (for a different purpose) that i can look for if someone's interested. but if u don't wanna maintain a PAC-style app, there might be workable alternative too. having the app just request a normal permission is a big no-no. but an app could request a normal permission and also request to be a device admin. the user has to manually promote the app with the pdoird-manage permission to admin status before the permission is honored. if u dont follow what i'm taking about (not everybody is aware of device admin apps) download and try the "screen off and lock" app.

> the new permission is already declared with signature protection. What this means is that whichever management app was installed first will have the permission, and any subsequent app will not (and so will not work). Note: this only applies if the signatures of the two apps are different.

thanks for explaining. just to clear up, what if i uninstall the fist app before installing the second? will the new signature be used for that permission from now on?

thank you!

---------- Post added at 04:24 AM ---------- Previous post was at 03:47 AM ----------

> This is also a priority for me, and I have some ideas for how to address it - the main one being a 'default' profile, which is used whenever there are no settings. This would be integrated into OpenPDroid (rather than the management app) because the management app has a delay after installation of the target app.

i've thought about this myself too, and ended up with a generalization. there's a case for making pdroid walk up a tree of apps and app groups to resolve inheritable permissions. part of it is the simplicity of the backend implementation. the performance can be handled by caching and keeping an incrementing version number for the permission database that forces a cache flush on version mismatch during permission querying. the downside is the enormous complexity added to the UI itself, and though it's a desirable feature, i don't think it carries its weight on the UI side, at least for version 1.

so back to your solution, a fixed, two level hierarchy with a default node for unconfigured apps. i don't think this is enough. imagine we go thru a major OS and gapps upgrade. there r new system apps. we have our default node in deny everything of course, a useful setting for installing new apps. now the new system apps get denied and maybe the phone doesn't boot. pretty bad. and the easy way out of it -the kill switch- discloses all our data to everybody, its a major disaster.

so assuming pdroid can find out whether an app is system or user (i suspect there is no problem) we can have two default nodes. a sensible setting for most users would be: sys: allow all, user: deny all.

the implementation need not be any slower than yours for normal cases. only when an app isnt found in the db (an abnormal case) pdroid would look up the app domain (sys/user) and then its default node. the manager would be expected to copy the corresponding default to a new db entry as soon as it sees the new app. so the default never acts as a inheritable set of permissions, only a template for new apps. this simplifies the abstraction presented to the user. i'd say in the UI, sys/user template is a better name than default.

---------- Post added at 04:45 AM ---------- Previous post was at 04:24 AM ----------

and since u said ud be implementing the override soon...

if the override is finally implemented, i think the same principle should apply to it. one should be able to override-allow only for sys apps in order to recover from inability to boot without giving full data access to user apps, which would be a disaster scenario. (btw: this is a real, possible, probable, disaster scenario that we should consider IMHO, not the unlikely inability to make emergency calls with a busted pdroid and unwillingness to override it! :) )

under the hood, the implementation doesnt have to be any slower. the would be a main some-overrides-enabled binary switch. if false control would fall to the database querying code. this would be the normal code path. if true, then pdroid would check whether the app is sys or user, then read one of the ternary switches sys-override or user-override. each of those would have one of 3 settings: disabled, deny-all, allow-all. if disabled control again would fall to the db code.

the UI would of course present only two drop-boxes, sys and user, and infer the right setting for some-overrides-enabled. any setting besides the normal disabled-disabled would incur performance penalty.

now implemented this way, i'd change my mind. before i said that the problem with a kill switch was performance cost payed always for a feature we already have for free on releases at least (we could flash restore.zip). but implemented this way we have a way out of fatal configuration changes that better protects our privacy. this is valuable and we didn't have it before, and i'm happily willing to the the performance price for it.

---------- Post added at 05:36 AM ---------- Previous post was at 04:45 AM ----------

just some small final thoughts...

-i think we should have recovery-flashable zips that configure the overrides. ideally six (pdoid-user-override-disable.zip, pdroid-user-override-deny.zip, etc.), and one would have to flash two of those to fully configure the overrides.

-so far the discussion has been default-to-deny or default-to-selectable on pdroid service failure. (the default-to-selectable now feels ever more weakened if sys/user templates and overrides are used, noting than even if defaults were also selectable per app class, the UI would feel terribly bloated now. in fact disregarding this sys/user thing, how should the UI for this look? how should it explain to the user that this is a setting for those cases when settings can't be read? awful!) i'd like to reiterate that maybe the right thing to do is not to default-deny, but throwing an exception in the exact same way as if an API was invoked without the app requesting the proper permissions. most apps naturally don't expect this and would force-close, as can be verified by revoking permissions on commonly used apps. this is a good thing, as it shows the user something is really wrong with the system. IMHO it's much better than silently denying data access, which is much more likely to cause unexpected app behavior, silent data loss, etc. if this is felt to be The Right Way, it would also have the benefit of ending our discussions around default-to-??? :) . for what's worth, i think it is.

-if at all possible, the manager apps should be engineered to be usable with both overrides in deny-all, at least to a point where the overrides can be changed. this would ensure that there's always a way out of misconfigurations without flashing (if the phone is already booted up or otherwise able to boot). if this is hard to do, then maybe the overrides shouldn't be selectable by the managers at all, but only by the PAC-style app. after all, there's no science to those drop-boxes, so there's not much a manager can add to the UI. and they can be though of as part of pdroid core settings, just like manager app selection is. given the need, pdroid backend and PAC can logically be one and the same thing and have a really intimate relationship, like signature checking and granting PAC the rights it needs to function even in override deny-all mode.

-if the default-to-exception strategy is finally chosen, then a fourth override value "throw-exception" should be added. this would allow testing what would happen if pdroid failed. in particular, PAC (or whatever manager) should be able to successfully change the override settings when they are both set to "throw-exception", proving that the overrides can be used to temporarily cure a system in which pdoid is failing (ie: throwing all the time).