[Android Software/Hacking General [Developers Only]] Lanchon:
>>Originally Posted by Lanchon

>>-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.

>A default policy for user apps of "deny until allowed" would be my preference, too and I agree with much of your reasoning.

ok! :) well if i managed to confuse you then i guess i must have confused almost everybody here lol, sorry for being so unclear!

there are two different concepts we are referring to with the same term "default" and i'll try to stop doing that.

it's been talked about what to do when an app not in the db (call it a new app) uses protected API. lets call this "default". i think the default-to-xxx strategy in this context was never taken too seriously as a mid- or long-term solution (though right now there is such a strategy in place). FFU said he wanted to implement a default db node for this that is totally user configurable. i think there should be separate default-sys and default-user nodes for reasons discussed earlier. (we could live without the two nodes by setting the only node to allow-all *before* a major OS upgrade and resetting it back to our liking afterwards, but it is risky because we can forget to do either of those operations, and implementing two nodes is really so very little work over implementing one that this thing sort of begs to be done.)

a related concept is what to do with an API request if the pdroid backend can't read the privacy settings at all for whatever reason. lets call this scenario "fail". FFU proposed fail-deny. some people want fail-selectable, which i consider the worst choice. i proposed fail-throws-permission-exception which i consider to be best: it (mostly) FC's apps and alerts the user something is seriously wrong with the platform instead of silently feeding apps inappropriate data (appropriate meaning what the user wanted) as fail-deny would. in an emergency situation fail-throws can be dealt with by enabling an override (even override-deny if desired, imitating the outcome of fail-deny) and i think it might take less time for a user to recognize the need to override pdroid to complete an emergency task if the FCs are visible. in essence, i think fail-deny is safe -and thus ok- but less useful than fail-throws. fail-deny might create harder-to-diagnose problems in the field. on the other hand, IMHO fail-selectable seems like an abomination.

>As I have stated before, I rather like the idea of PDroid using something like PAC to "manage" the inner workings of OPD, though I am not enough of a developer to understand the ramifications of doing so. I can imagine PAC (possibly as a root app, less of an issue since it's open source) providing the option to "allow everything" or "deny everything" in case of an emergency/testing/whatever. This would be regardless of the individual app settings in PDroid Manager...and certainly not affecting/resetting them!

the overrides, yes. separate sys and user overrides, with these options: disabled, deny all, allow all, fail (throw security exception). where these controls are is a UI issue. its ok for them to be in a PAC-style app since i can see no bells and whistles to add to this, so there's little incentive to have a custom tool to manage them. on the plus side, having them in PAC would decrease the complexity of the pdroid-manager interface and make the developers completely free to change its implementation (pdroid backend and PAC would be two sides of the same coin, almost a single version-matched, possibly signature-matched, monolithic piece of software).

be as it may, its very important to be able to reach the override UI if pdroid is failing. more specifically, this UI should be available even when both overrides are set to "fail". it's certainly awful, but to attain this it *might* be necessary for PAC -probably a system app- to have some privileges hardcoded in the backend. regardless of UI choices, guaranteed recoverability is a good technical reason for making PAC manage the overrides, specially if it is tricky to attain in the manager apps.

<<<WARNING>>> in this case PAC could maybe be recognized by the backend by its signature, whose public certificate would be embedded in the backend. this same solution was proposed for managers, entailing the inclusion of a (size-unbounded) list of public certificates in the backend, which is a lot worse than just doing it for PAC. it should be noted that embedding public certs in the backend makes the corresponding private keys single points of failure for our pdroid installations. an attacker would have incentive to obtain any of those keys and each makes its owner possibly the target of attacks. its difficult enough to adequately secure keys for organizations, let alone individuals. add to the mix that anybody who forks a manager can request its signature be added in the backend and we have a headache.

>Likewise, I think this is where you could set a default policy to "allow" or "deny." Obviously, arguments have been made against an "allow" policy, which I largely agree with, but this is where I imagine such functionality would be configured if both options were eventually provided for.

you are talking about the fail policy. IMHO, it should be hardcoded and not configurable via any UI. it should either be fail-throws or fail-deny.

>>Originally Posted by Lanchon

>>...a very important point (having much to do with PAC, permissions, manager apps, etc) is that pdoid must be undetectable, rootkit style if necessary.

>While I think I understand your point, this sounds like quite a bit of overkill, especially the rootkit part. Currently, I believe it would be quite trivial to detect PDroid since an app needs no permissions at all to detect the presence of the WRITE_PRIVACY_SETTINGS permission that a OPD management app would have registered.

i'm a total android noob, i don't know much about its app model though i've done some apps. if you can enumerate permissions then permissions are not a good implementation choice for this. for the 3rd time now i'll mention that i've seen free code that behaves somewhat like a PAC (looks for other self-identifying apps and, after user approval, grants them special system-wide rights). if i remember correctly, the apps didnt self-identify with a permission, i'd have to look into that.

>So, without some serious re-tooling, I think this is impractical in the short term.

agreed. as i said before, pdroid shouldn't be stealthy in the short term, but we should architect it in a way as to enable the possibility in the future.

>In the long term, I'd have to think about it but my gut is telling me that I wouldn't even want this (probably because of your usage of "rootkit"...).

i think we want it. i imagine android has an API to enumerate installed apps. at a minimum, the ability to hide some apps (or all) will be necessary for this, and this ability is much in line with pdroid's raison d'être. only because the protected subject matter is different (installed app list vs., say, your phone number) i used the word rootkit, but call it what you will, it's an ok feature to have and a welcomed addition.

sample use case: i have some apps i dont want to upgrade cause in these cases upgrading really means downgrading. i have market notifications for upgrades. google is a tyrant that sides with app developers. google wants me to upgrade the apps because they assume it might eventually lead to market purchases and their precious cut, so they don't let me disable the update notifications on particular apps i don't want to ever upgrade. it would be a great thing if i could lie to the market app and hide a few apps from it.

>>Originally Posted by Lanchon

>>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...

>I really do like the idea of "informed consent" to the user. Currently, a lot can be gleaned by a technical user looking at a "logcat." However, when a user decides to do something drastic, I really like the idea of a dialog that uses big fonts, big buttons with semi-randomized choices for "Yes" or "No" (cut down on a muscle memory response...) and gives them a bottom-line, worst-case summary like "all your data will be vulnerable" or "all access to your data will be blocked".

there would be no dialog i suspect. this is regarding fail policy: what to do when the backend cant read the settings. i understand right now the backend can't interact directly with the user in the context of a protected API call. what it can do is implement fail-deny or fail-throws policies. the second option mostly ends up with a FCing app, so the user knows the app (or system) isn't working. (and can choose to override if she suspects pdroid failure.) fail-deny would just cause apps to silently work on erroneous data.

>>Originally Posted by Lanchon

>>...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 idea of leveraging the "device admin" role is intriguing. I doubt it would block any realistic uptake of OPD since I'm guessing not many corporate phones using this Device Admin functionality would also be running OPD. I'll look into that feature and get a better understanding of how it works and what mechanisms it uses.

interesting, i didn't know corporate phones might restrict access to the device admin list. but in any case, to use pdroid u have to flash the phone, and in this scenario i suspect flashing would be unacceptable to the corporation anyway.

>>Originally Posted by Lanchon

>>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.

>In case I missed something, could on of you please clarify what the "use case" for having a "tree" of apps each contributing to a inherited set of permissions? I may have missed something there but I agree that it sounds horribly complicated for what it might be worth.

yes, the backend is simple but the UI is complex to implement, not to mention complex to understand by users. i agree, i wouldn't consider this for version 1, i said it myself. but here are some use cases anyway...

-i live where whatsapp is universally used. i refused to use it before pdroid -its a big privacy hole- but now im using it and i have to admit it does its job well. the problems with whatsapp are: 1) i don't want whatsapp,inc to have my info, such as my phone number, where i am, etc. and 2) i don't want to give somebody i just met my phone number just to be able to message them. its the internet age, i want to use a pseudonym as a handle, not my real phone number. my solution is to feed whatsapp a fake phone number (verified somehow), so i can give it away without too much thought. also i travel a lot and i switch to a local SIM card with data everywhere i go, and i want to keep my whatsapp id and be able to be messaged by any of my contacts and not have to go through verification procedures on every sim card change. so thanks pdroid for all this!! now it turns out there are other apps like whatsapp, some are endemic in other countries, some have VoIP, and they all share this phone-number-as-id nuisance. me, i have viber and tango on my phone. i could have a node with my fake number and other stuff configured and hang all these apps from it. instead i have to manually configure my fake number and other stuff for each.

-there are *a lot* of location-based gay dating apps out there. i use grindr and scruff, and have occasionally used a couple others on trips, as some places are dominated by otherwise unknown apps. ive never done this for myself, but ive done it on my phone for others: friends have wanted to see how these apps would look like if u were, say, in chicago before actually getting there. or even before deciding to go, picture their dirty minds! ;) it would be nice to have a single point where i could fake the location for these apps, instead of fiddling with the settings for each of them. also, i let these apps access my network location but not my gps: the gps kills my battery and i never use these apps under open skies anyway. but sometimes network location doesnt work correctly and i'd like to allow the gps. (eg: a stupid wifi access point filters "adult" sites, i use TOR to get thru, i log in and find myself in istambul or other strange place, issue solved if i allow the gps.) again, a single node to do this for all apps would be preferable.

in essence, every time u have a bunch of similar apps with similar privacy concerns that you use for similar activities, you have a candidate for a common node. also think facebook app and facebook messenger app, and the times you might want to allow location services for them. there are many examples.

>>Originally Posted by Lanchon

>>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.

...

>>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.

>I'll admit that I had to re-read this section several times before I (think I) understood what you were saying. On this last point though, I thought the database entries were created by the framework itself, not the manager app. For instance, if someone flashes a new OPD-enabled ROM but doesn't have the manager app installed yet, doesn't the framework apply the default profile (currently "allow") to new database entries as all the system apps get "discovered" during initial boot?

i imagined the backend only did db reads. this is only my imagination, reality can be different.

>On your other point though, I agree that the "sensible setting" you describe is what I would use, though I would be interested input from the broader community.

the point is that the two types of apps beg different default nodes in the db to handle OS upgrades better, but what u configure on those nodes is totally your choice.

pheww that was a lot! and i still got more to write :(

cheers!