[Android Software/Hacking General [Developers Only]] FFU5y:
Sorry I've taken a while to respond all: just moved house, and so have no home internet connection for a couple of weeks, and I'd hit my tethering data cap.

I'll start with a quick update: I've pushed changes to the 'main' repositories (i.e. the -openpdroid, not the -openpdroid-devel) to fix the performance issues, and I will be working with mateorod to get these changes into auto-patcher.

If you are building from the repositories and hit problems, please PM me. Moving house has meant no build system and no net connection for a while, which has meant no full synching of repositories with CM10.1, etc.

There have also been some reasonably large changes in openpdroid-devel, which extends on the 'default deny' approach but with some optimisation. I still haven't done any work on a 'kill-switch' override, but that is high on the agenda.

When I talk about 'always, always, always' allowing emergency services calls, what I am talking about is basically including '112' detection: i.e. if something tries to call '112' then let it through (and maybe 000 and 911? I don't know what other countries use for emergency calls).

I don't really consider this a 'privacy leak', but I'm open to input. Possibly this could also be narrowed to only work for the com.android.phone app?

From my understanding of the way that emergency services locate mobile phone users, that is outside PDroid's (or anything's) control.

Unless some devices have a specific mod or app integrated which provides that information, and if anyone knows about this I'd love the info.

By and large, I agree that it is a marginal possibility - but that marginal possibility is an important one. I am certainly open to more discussion on this though. I guess a key question is 'what is a breach of privacy'? Is always allowing com.phone.android to call 112/911/000 a breach of privacy?

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

For a fresh install, the default will always have to be 'allow', otherwise the likelihood of the device not booting correctly is too high. I think it is fair to assume that the user trusts the apps installed in the ROM at time of install (given that in practice, the ROM developer can include any code they want, dodgy or otherwise).

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.

[/COLOR]> 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.

Not really, but what can be done is this: Because of the way PDroid Manager is designed, it is *really easy* for me to strip out permissions to make it match Syvat's PDroid (indeed, all that needs to be done is to remove the settings not supported by PDroid from the list of permissions in 'res/xml/pdroid_settings.xml' and possibly 'res/xml/permission_setting_map.xml'. That would basically remove the features not relevant to Syvat's PDroid. You could then use the modified PDroid Manager with Syvat's PDroid, you could use the 'backup' feature to back-up the settings, and then install OpenPDroid and the 'normal' PDroid Manager to restore the settings.

Don't worry about it. I've got the original patches and they should be enough.

That was implemented as 'PAC' - PDroid Appplication Chooser. The code is available from my Github, but it hasn't been updated to match the more recent versions of PDroid/OpenPDroid. If there is a demand, then bringing this up to date may be an option.

In brief, what PAC does is provide a list of applications which have requested the permission to edit PDroid settings to the user, and they can choose which ones to allow. It uses the APK signature, or the signing key as the identifier (in the code; in the PAC app itself it doesn't give the user a choice because I never finished developing it).

Yep, that's PAC. It uses what you listed as 'Option 2': it checks installed apps for the "android.privacy.WRITE_PRIVACY_SETTINGS" permission, and lists them if they include that permission.

The downside is that it requires the management apps to no longer use 'signature' protected permissions, so that multiple ones can be installed at the same time. That itself is not a problem, unless someone uses one of these apps which don't use 'signature' protected permissions on a version of PDroid/OpenPDroid which doesn't use PAC.

Yeah, including explicit app names or signatures is a terrible Idea, I agree.

All of the current PDroid apps/providers actually do this already. The basic issue is that you have to choose the approriate protection for the permissions. 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). Alternatively, you can have it 'signature', which means that the only apps which can have that permission are those that match the signature of the first app installed requiring that permission. The latter case (using 'signature' protection) is what we have now, and indeed it is what prevents PDroid 2.0 App and PDroid Manager functioning at the same time. This is basically the problem that PAC was designed to resolve.