[Android Software/Hacking General [Developers Only]] FFU5y:
Sorry I haven't responded for a while - I have just moved house, and for some reason there have been a bunch of problems with getting a net connection (which will not be resolved for at least 4-5 more days). I've been burning through my data cap on my phone at a prodigious rate so I'm afraid there will probably not be a lot of development (or comment) for at least another week when the connection gets sorted.

On to business:

I think it is important to differentiate two concepts which are easily confused: the 'default' behaviour - i.e. the behaviour for an app which has no settings; and the 'error' behaviour - i.e. the behaviour when there is a failure in the OpenPDroid service, or the connection to it.

Right now, the 'default' behaviour is to 'allow': the impact of that is that a newly installed application has full access until the settings are changed/saved, and there is currently no way to change this. This is, in my opinion, a very bad thing. I want to resolve this by making it possible to create/save a 'default' profile which will be used when there are no specific settings. Perhaps even separate profiles for system and non-system apps (although since you can't actually install system apps as such, this seems less important).

The 'error' behaviour is what we have mostly been talking about. Historically, and indeed in the current 'release' version of OpenPDroid the 'error' behaviour is (mostly) to allow access. That is, if the OpenPDroid service is on fire, or the connection to it has gone down the gurgler, then the request will be allowed.

Much of my recent development of OpenPDroid has been changing this behaviour to 'deny on error' - that is, if the connection to the service is baked, or something else goes wrong in checking the settings, then the access will be denied.

Reasonably enough, not everyone things that is the right behaviour (e.g. tonyp) whereas others think it is absolutely the right behaviour 'Lanchon'.

Some arguments for each side:

For 'allow on error': if the privacy service is dead, it is still important to be able to make emergency calls (i.e. to 112, but also just to family etc). In case of major events, this is a safety issue.

For 'deny on error': data leakage is the worst outcome, and should be avoided above all else. If OpenPDroid is designed to 'allow on error' then this will encourage attacks on the service to potentially 'allow' access to something. Indeed, even the option of having allow on error encourages this.

There has also been mention of the importance of OpenPDroid being undetectable. I'm going to be very clear here: OpenPDroid is going to be detectable, unless someone makes a major effort to avoid that being the case. Avoiding detection involves a shopping list of changes throughout Android, including but not limited to:

The code supporting reflection inside Android (e.g. the 'getClass' function would need to be modified to ignore the PDroid classes)

The code relating to detecting permissions would have to change (otherwise the relevant Android permissions declared by the management apps would be detectable)

The code for retrieving installed apps would need to change (so that the management apps could not be detected)

The code for retrieving system services would have to be changed (it would have to pretend that the service did not exist, but only if the process from which the call was being made was not a management app, or the connection was coming from within a class which needed to check settings.

Code related to looking on the file system would need to change, so that the privacy.db file and others would not be detected.

There is almost certainly more that I haven't considered.

I'll be honest: I'm not going to make those changes. They are far-reaching, and I think the incremental advantage is well outweighed by the effort of development and maintenance. Mind you, if others are wanting/willing to do all that and maintain it that's another matter.

Anyway, this is what is I plan to implement, and probably in this order:

1. Deny on error: that is, if an error occurs connecting to the privacy service then the action will be to deny the access. In practice, this is mostly already implemented in the development code.

2. The option to have 'allow on error': so that if an error occurred trying to connect to the privacy service, then the action would be allowed

3. The ability to 'allow everything' when the service is working. This is not the same as a 'kill switch' because the privacy service (i.e. OpenPDroid service) is still involved. Having thought about a 'kill switch' which overrides even attempting access to the service: I am not planning to implement that at this stage because it will add to the overheads when things are running normally, and having 'allow on error' and a service-based way of 'allowing all' achieves the same thing.

4. I will likely include an override in the code (simply a constant) which can be set to force 'deny on error' so that installation of the OpenPDroid service can never be set to 'allow on error'. I will talk to mateor about this, but my feeling is that this version should probably not make it into auto patcher, but rather be for those who want to compile themselves.

5. The ability to define 'default' settings for apps which don't have settings of their own: this may be separate for system and non-system apps, I'm not sure yet since I haven't fully thought it through.

This is what I don't plan to implement, at this stage:

1. Having a list of phone numbers for which OpenPDroid settings are ignored: I don't believe this adds much incremental value over having the ability to set 'allow on error'; we're talking about what should be a pretty marginal situation in the first place. Furthermore, because the file containing the numbers would need to be accessible when the OpenPDroid service was dead, it would need to be readable by everyone and thus would be handing out a list of numbers.

2. Always allowing 112: I'm somewhat more open to discussion on this one

3. Build in PAC-style management application selection: I'l like to, but I don't think it is warranted yet. Yet.

4. Inheritance of permissions through a hierarchy: right now, there is no way to have a hierarchy - adding profiles will to some extent do that, and I am considering having 'profiles', but currently I'm planning to implement that in the management app rather than the service.

The reasons for this are:

1. The issue of directly attempting to DoS the OpenPDroid service is not really a big one - it will (I believe) bog down the whole phone, rather than the specific app and thus probably not lead to the service itself becoming unavailable while everything else runs fine.

2. If a DoS does manage to disable the OpenPdroid service, then those users who (prudently, I think) chose 'deny on error' are still protected from data leakage. I believe that the value of 'allow on error' is great enough to warrant inclusion, mainly because I plan to make 'deny on error' the default and so the likely return for a DoS on the OpenPDroid service would be very low. Furthermore, it is niche enough that I don't think it will actually occur. The key thing here is that I plan to have it possible to set 'Allow on error' can be chosen even if the privacy service is dead. This will require root access, and I'm still thinking through the security aspects of it (and there are indeed security aspects to it).

To answer some questions, and respond to some comments:

If you uninstall one management app before installing another, then it works fine. When the first management app is removed, then the permission is removed with it. As such, when the next management app is installed, it can define the permission with its own signature.

Note: if a nefarious app installed itself somehow in between these two, it could define the permission itself (potentially even as a 'normal' rather than 'signature' permission). This is a security risk.

If you do an update of the system, and the default action for apps without settings is to deny them, there is a risk that booting could fail as a result of an update. Basically, that is my reasoning behind potentially having distinct 'default' rules for system and non-system apps.

Default profiles would be handled through the service. If the service dies, the default profiles would die with it. The default profiles will probably be stored in the database, and so being able to update them using 'update.zip' type files

PAC, in terms of providing the functionality to choose which privacy settings managers are permitted (i.e. PDroid Manager or PDroid 2.0 App) would not need root access, because there would be specific code for it in the core. Examples of this code (although somewhat outdated) can be found in my github. As you can see there, the PAC app itself is tiny and not at all complex. The bulk of the complexity is added to the service (and it isn't actually a lot of complexity).

I would like to be able to display information to the user when the service dies and the fallback 'on error' action is being triggered. And I can. And will. It will just be a notification though.

Warnings on setting 'allow on error' make sense: however, this would be set through the management app so those warnings would basically be the responsibility of the management app. (Of course, since I am the main developer for PDroid Manager, I could have those warnings).

Using the device admin role is not necessarily a good approach, because there are legitimate reasons for other apps to use that role - e.g. phone locator apps. It doesn't provide sufficient discrimination - i.e. it is not just for PDroid management apps.

The reason I would prefer to use 'deny on error' rather than 'throw permission exception on error' is that in many cases throwing a permission exception will cause an app to crash, whereas it may be able to tolerate empty data without any major side effects. If there are major side effects, I wouldn't imagine them to be worse than a crash (although I could be wrong).

It is correct that it is essential the 'override' setting can be modified even when the service is in a state of failure. Currently, my plan would be to have that fall on the management app, although it could potentially be incorporated into the PAC app. The PAC app would then become 'global OpenPDroid settings': I'm not sure how to deal with that separation.

I think the functionality of hiding installed apps from each other falls outside the scope of OpenPDroid, but I am not certain it does. I'll think about it, and discuss it with CollegeDev (because if he wants to have it in PDroid 2.0 as well, then we can discuss implementation) and others and think about it.

I'm planning to have a compile-in force 'deny on error' policy, but I also think there is an adequate case for the 'normal' version to be able to be set to 'allow on error'.

Actually, on failure an intent can be sent to the management app, which can then notify the user of the failure.

This would be something implemented in the management app, once again through having some kind of 'profile' system. It is something I want to implement in PDroid Manager, but it is a matter of time availability.

That special contact is, I believe, treated as a normal contact for the purposes of security so all the normal rules about access to it apply.

I'll look into this soon: not having a net connection most of the time makes investigating anything pretty difficult, so it will probably not get addressed for at least a brief period.

Thanks for pointing out this problem. It You may want to check you are using the cm-10.1-openpdroid-devel branch for your /frameworks/opt/telephony because if not it will produce this problem.

Also, do the following:

rm -rf /android_sources/out/target/common/obj/JAVA_LIBRARIES/telephony-common_intermediates/.

rm -rf /android_sources/out/target/common/obj/JAVA_LIBRARIES/services_intermediates/.

rm -rf /android_sources/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/.

If problem persists, let me know because it may be a problem in the repository

Regarding inclusion of PDroid in CM, etc: as has been pointed out by others, PDroid will probably never be included in CM, although it may appear in some individual's unofficial builds.

Now that Blackberry have released their new device and their new OS, one of the key things to note is that they have persisted with providing users the option to disable certain permissions for certain apps. I would actually really like to see CM re-include the ability to disable permissions, but I can't imagine them doing it (again for the reasons discussed above). It is notable that in the Android documentation on permissions, you can define some permissions as 'optional' - however, the underlying functionality is simply not there at the moment, and all permissions are treated as 'required'. I am not surprised, though: allowing users to disable permissions makes life harder for developers because they need to accomodate that (or just crash - one or the other). Furthermore, Google relies on valid data in order to maintain the value of things like AdMob. If the data was invalid, then the advertising value would drop considerable.

Don't get me wrong: I think Google are being bastards on this, and I think optional permissions should be implemented and there should be pressure for developers to use them. The best way to apply that pressure would be to provide the option for users to disable any or all permissions, but to warn them if the ones they are disabling are not 'officially' intended to be disabled. That way, when people disable things and it doesn't cause crashes the can apply pressure for it to be optional, and if it does crash they can apply pressure as to why it is necessary.

Note: Wbedard and mateor already answered some of these, but I was writing as I went along I'm afraid :P