yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] nsmart:
My thoughts about the default deny strategy:

I understand both views (FFU5y and tonyp) and I think you have to decide between security and usabilty. For me, pdroid is a security solution and it's main task is to restrict access to personal data. If I deny rights for some apps, I would expect pdroid to exactly do this in every situation, except for the case I intentionally turn it off. If pdroid fails to restrict access to personal data, thus allowing such data to be accessible to 'untrusted' apps (maybe even without notifiying me about this), then how can you feel safe about your personal data?

I admit there might be situations like tonyp described, where you would prefer a usable phone over the security of your data. This individually depends on the situation you are in and on the security demand for the personal data on you phone. If it gets to the point where pdroid destabilizes my device or my phone starts some weird behaviour I would remove some personal/privacy data from my phone and then turn off pdroid to have a fully functional phone again. But I would not want pdroid to take this decision for me and leak my data to restricted apps. It does not feel right if there are situations where pdroid needs to pass personal data to restricted apps in order for the phone to work properly.
[Android Software/Hacking General [Developers Only]] CollegeDev:
Just quick note, because of limited time: I totally agree to this.

Giving the user the choice to default deny or not is also bad.

I've solved this problem few weeks ago, with an central implementation that fixes the failures inside the framework. What does it mean?

FUUy5 described it in this way:

In nearly all cases the problem is that the service is unavailable (I've tested a lot of things in my testing environment up to this issues) and this causes that the applications get access to all stuff you previously denied. With the implementation now this problem is fixed and with some additional code 99,999% it will work. You can call it a minor security bugfix if you want. I will inform FUUy5 about this and he can copy paste my code if he want to. I will hopefully ready with all kind of stuff in round about 1-1.5 weeks and put all this to github.

You want to discuss implementation?

https://github.com/OpenPDroid/platform_frameworks_base/issues/3

Another big problem:

Since I've changed a lot of internal phone classes you're also not able to take emergency calls anymore! So in my Opinion it is not a good idea to handle it like this way it is now in OpenPDroid
[Android Software/Hacking General [Developers Only]] wbedard:
This is some really great discussion about what the fundamental role/policy of PDroid should be and it highlights that different people have different needs and expectations. Ideally, PDroid could grow in flexibility to accomodate all/most people.

In one case, we're talking about how PDroid should act in the case of a "failure" within the architecture and it sounds like both FFU5y and CollegeDev have some great ideas/implementations about how to prevent those failures in a "robust" way. I think that is the correct approach but, if something does go wrong, a user should be able to easily disable PDroid from the management app. I don't believe that any version of the PDroid patches or management apps currently support this but I think it is a great goal to work toward.

In another case though, which I haven't seen discussed, we have the idea of a default "policy" for newly installed apps (there's some flexibility as to what apps this would actually apply to...). The process of installing an Android app and configuring it with PDroid leaves lots of opportunities for an app (esp a malicious piece of "malware"...) to obtain and export your data before it can be blocked by PDroid. Today, we would say that PDroid's default "policy" is to allow access to data until the user specifically restricts that access. Some people may want a more secure policy where all newly installed apps would be denied access to data until the user specifically allows that access. That, too, is not supported by any version of PDroid at the moment.

Since all of these ideas will likely require a substantial amount of effort to implement, I encourage everyone in the PDroid community to continue to discuss this and voice their ideas/concerns so that the developers can form a sound roadmap for PDroid that addresses those needs.

R/

wbedard
[Android Software/Hacking General [Developers Only]] wbedard:
FFU5y,

As always, thanks for the great insights! As I read your post, a thought that occurred to me was the possibility of building a "heartbeat" or "monitor" service into the framework that would be responsible for 1) providing feedback to the user via the management app of the current "health" of the main privacy service and 2) acting according to user preference (i.e. "kill switch", open everything up, shut everything down, etc...some options might not be feasible) if the service goes "sour". It also occurs to me that such a secondary service could play into your designs for a "unit test framework" and/or "diagnostic" capability for PDroid. What are your thoughts on such an approach?

R/

wbedard
[Android Software/Hacking General [Developers Only]] tonyp:
An attack vector.. well I don't see PDroid at risk for quite some time. At least until it will reach a critical userbase.

Consider that most people aren't like "us" here - they use the Stock ROM and that's it.

Why implement workarounds for the couple people using PDroid (who are only making some data private which everyone else who isn't using PDroid does leak already).

It's way more efficient to target the common users or big bugs like the recent exynos (damn wtf Samsung?!) one.

I'm not saying we shouldn't rule out every kind of possibility - I'm just saying it doesn't need to be a priority.

Performance limiting factors (like with the current release) should be targeted first IMO.

I do like the idea of asking the user what to do.

A simple popup with Yes/No could even be hardcoded. It is really rare, but if it occurs the user gets informed, e.g. "PDroid currently isn't able to access it's settings. Do you want to grant data access to this app?". The launch activity gets paused until the user makes it's choice.

If I'm in a hurry while this error occures I can quickly make my decision and fix the culprit of the issues (PDroid not able to get the settings) later on.

Oh and this is important: If what CollageDev wrote up there is true, that you can run into trouble with making emergency calls, this needs to get addressed.

This is a core feature, you need to do emergency calls under every possible situation. You don't even need to unlock your phone to do that on android (or even type in your PIN).

So at least for critical stuff like this the default setting needs to be at "default-allow".
[Android Software/Hacking General [Developers Only]] htrakr:
Would that affect the battery life? (not sure if it will or how much).

My understanding (I could be totally wrong) was pdroid like droidwall doesn't need to run all the time and doesn't affect the battery that much.
[Android Software/Hacking General [Developers Only]] FFU5y:
Thanks for the input and suggestions: it is good to hear other people's ideas, so I don't go off on a wild path to nowhere =)

I'm not sure adding a second service would be a good way to go, simply because it seems like a lot of overhead for monitoring PDroid.

The approach I would probably take is to send a special notification if connection to the PDroid service failed: that way, it is 'on-demand' rather than 'always-active'.

I'll discuss the default-allow/default-deny option implementation later, once I've had more time to think about it =)

Yeah, I tend to agree. Basically, 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.

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 (it could be at the very top, but then that file would need to be checked each and every time, unless the kill-switch also took out the privacy service itself so that the connection to the privacy service would always fail if the kill-switch was triggered).

This would be ideal, and indeed I would like to actually have that as a PDroid option in general (i.e. 'prompt me'). However, from a technical perspective I'm not sure if this can work: I'll have to look at the code for the SuperUser app (since that is probably the best related). The main possible issue I see is that if the function call which is triggering the 'check' is running on the UI thread, I'm not sure if I can jab in in the middle of it to display the prompt. I'm not sure I can't, but I don't have the information/knowledege at this stage to be sure I can.

Absolutely - emergency call should always, always, always be allowed. Always. Right now, I don't believe there is any code specifically handling this, and it does need to be added.
[Android Software/Hacking General [Developers Only]] pulser_g2:
I believe LBE uses a method to prompt the user, but I think it hooks in further back up the chain within android, rather than at the point in the UI thread, but I may be wrong.

You would need to freeze the app though while waiting.
[Android Software/Hacking General [Developers Only]] FFU5y:
Thanks, you make a good point: if it is running on the UI thread, and there is a valid context, then it may well be possible to present a UI.

If it is not running on the UI thread, then the thread can be blocked to wait for a UI thread to respond.

Even with LBE, though, it needs to be interrupting normal flow of execution in order to do what it does, so it has to be injecting somewhere. Something for me to think on.
[Android Software/Hacking General [Developers Only]] wbedard:
Wow...your post has so much "awesome" in it, I can't even begin! Thanks for taking the time to contribute...it's greatly appreciated.

R/

wbedard
[Android Software/Hacking General [Developers Only]] pulser_g2:
You can add your own permissions into android from what I've seen. That might be a better solution than hooking onto the back of others.
[Android Software/Hacking General [Developers Only]] mateorod:
We could always just hardcode in signature verification and start with PDroid2.0 and PDroid Manager. If anyone wants to push out a competing or extending management app, they can just send us a pull request and be added. Or, if we have been crushed under the Android wheel of fate, then they can fork the core and add themselves manually.

That way users will know that only trusted (by us...but you gotta start somewhere) apps will be able to sort and change permissions.

One of the benefits of being Open source, adding in signature verification no longer has to lock anyone out. We could place instructions on how to get around it right inn the code. As long as users get the patches and the app from a trusted source, they are protected.

That is a secure and long-term solution to that problem as far as I can tell.
[Android Software/Hacking General [Developers Only]] g.armour:
AOKP just released mr1 build 2, will this still work with it?
[Android Software/Hacking General [Developers Only]] Lanchon:
this is a very bad idea IMHO. backend and frontends strive to be independent, and we tacitly picture a world in which we can match publish, patched roms with the management app we want (or apps, as no frontend will do everything we need all the time, we can have specialized tools). this does away with independence, and rather than being a solution to the problem it seems like an ugly hack.

its not that simple. applying customized patches is a big PITA compared to running autopatcher; it requires building your own rom, not just an app. not everybody can do that. and don't forget we are talking about users here, not developers! the frontend devels can't and wont maintain large sets of roms or smali patches for them, so the job lands on the user who wants to use the frontend. the effort of making the smali patches is so large -u know about that- that we should make an effort and make sure it works for everybody. being open source is not enough in this case, it's better if we actually help people develop and choose. if we don't, there will never be a ecosystem of pdroid manager tools.

actually no, users won't know that only "trusted" apps will be able to manage pdroid, and in that way it's not secure. how do i know which apps in my phone carry your signature? it's surely secure *for you*, but there's no way for me to know which apps manage pdroid.
[Android Software/Hacking General [Developers Only]] mateorod:
I am am thinking not so much of a signature for mis ce

As a signature for the specific management apps I mentioned. I don't exactly understand what you mean here, although there is certainly concievable holes in this plan. But this doesn't do away with anyone's ability to create their own management app. The idea is that we allow anyone who requests it to be added to the signature moist. If we have fallen of the earth, they can fork the core and add themselves. If they wasn't auto-patcher support, they can fork that code as well, I have it available on an even more permissive license than PDroid.

Everything someone needs to provide an exact replica of our distribution channels and project is there for the taking. So there is no loss of independence or choice.

Maybe there are other concerns, but I don't think this is one of them. Right now, all about app needs to do to manage PDroid permissions is to decide too do it. Adding this verification requires an app to declare to anyone installing the patches that they have the ability to do so.
[Android Software/Hacking General [Developers Only]] pulser_g2:
Rather than add signature verification, why not declare a new permission, and only applications using that permission can control the interface. That separates your front-end from the core.

I've seen apps which create new permissions for others to use, such as a third year party package being authorised to show up in this app... Unless you request that permission on installation, and get it, you can't access the protected resource.

Imo you should always aim to use the core android method if possible, as it is likely better tested and proven than any new method you can write.
[Android Software/Hacking General [Developers Only]] CollegeDev:
It is just realized with signature protected custom permission. So at this stage it is unnecessary to write a manager application. What we can do is parsing permissions of all applications and search for the app which was installed first. (will include that to the next release :)) This is your current manager. Having multiple managers installed makes no sense so this kind of protection is a good one I think. Or are there any other ideas?
[Android Software/Hacking General [Developers Only]] sakura_candy:
Ummm, no search by name?
[Android Software/Hacking General [Developers Only]] Yhez:
My phone become very slow after installing the patch for open pdroid, is this supposed to be?:mad:
[Android Software/Hacking General [Developers Only]] wbedard:
Please read the "Known Issues" section of the Original Post (OP) and the links to the relevant posts within this thread. It is a known issue and a fix has already been coded up and tested. It will be available in the next release, which is already being built to support distribution through autopatcher. If you are following OpenPdroid on GitHub and can build your ROM from source, you can pull the fix down yourself today!

R/

wbedard
[Android Software/Hacking General [Developers Only]] SecUpwN:
AW: [MOD][4.1.2 or 4.2.1][GPL] OpenPDroid [v1.0, 2013-01-14]

An app for android downloading all necessary files and creating the necessary patch as well as flashing it afterwards - is such thing in the works? :)
[Android Software/Hacking General [Developers Only]] wbedard:
You should probably PM mateorod about this. He has been working for ~1 year toward this goal and it is certainly on his radar screen. If you are interested in reading the background yourself (it is more than a few posts...), search for the [edit]"Botbrew"[/edit] thread (http://xdaforums.com/showthread.php?t=1446541 and http://xdaforums.com/showthread.php?t=1508481). It covers the background of what you want to accomplish and where we are today.

R/

wbedard
[Android Software/Hacking General [Developers Only]] g.armour:
Broken MMS

Flashed this onto AOKP mr1 build 2, broke my MMS. I can still send and receive texts, but no pics. I even used the restore.zip and still broke. Any way to fix this?
[Android Software/Hacking General [Developers Only]] mateorod:
You can either install the Mms.apk from your rom, or simply flash your rom again (no wiping necessary). The mms is an known issue (look at the posts right above yours) but is fixed and will be released with the next build patches and the auto-patcher.
[Android Software/Hacking General [Developers Only]] g.armour:
Thanks for the quick reply, basically at this time, until next release, there is no way to have both openpdroid and MMS?

I'll deal with no MMS I guess. ;)
[Android Software/Hacking General [Developers Only]] mateorod:
Well, you can install your ROM's MMS.apk over the openpdroid update.zip and then you will have openpdroid, but without MMs protection. I am pushing through the build process for the next release now though, although that takes a bunch of time to finish up.
[Android Software/Hacking General [Developers Only]] g.armour:
I tried installing it over the top, still don't work. I'll just wait.
[Android Software/Hacking General [Developers Only]] SecUpwN:
AW: [MOD][4.1.2 or 4.2.1][GPL] OpenPDroid [v1.0, 2013-01-14]

Wiped cache + dalvik-cache before?
[Android Software/Hacking General [Developers Only]] g.armour:
Yeah, still no good. I keep getting message that it currently can't send. It will be sent when the service is available. I flashed my ROM again just to be sure it wasn't it. It worked fine till I reapplied patch. So I booted back into recovery, wiped cache, and dalvik, flashed mms apk.zip that I have and rebooted, still no good.

Edit- So even though I didn't have to, I wiped, did a clean install of ROM, reinstalled patch and noticed something else, my text to speech is also broken.
[Android Software/Hacking General [Developers Only]] FFU5y:
So just to check:

Having problems sending MMS, and text-to-speech is broken?

(Thanks for letting me know - I just want to check those are the problems so I can test them in some detail)
[Android Software/Hacking General [Developers Only]] FFU5y:
I think what CollegeDev means is that 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. If the signatures are the same, then both apps can have the permission.

CollegeDev: I'm not quite sure what you mean by the 'What we can do is parsing permissions of all applications and search for the app which was installed first. (will include that to the next release'. If PDroid 2 App / PDroid Manager continue to declare the permission with 'signature' protection, only one of them can have it. I don't necessarily think there is an advantage to changing the permission declaration to 'normal' and then checking which was installed first by date, because the outcome is so similar: i.e. you can still only have one management app at a time. In that case, I would think staying with 'signature' protection would be a better option because the OS takes care of it.

Not yet, no.

PDroid 2.0 App does have it, and I have it planned for PDroid Manager but all my time has been going into OpenPDroid for the last month or so.

If you (or anyone else, for that matter) wants to have a shot at adding it, please feel free: PDroid Manager source it as https://github.com/wsot/pdroid-manager

If you do want to do so, you'll need to include the OpenPDroid framework files (from platform_frameworks_base the android/privacy folder) in the project, or add the equivalent class files from the 'framework.jar' file in your 'android.jar' file for Eclipse. I'll aim to write up more details on this in the PDroid Manager thread soon.
[Android Software/Hacking General [Developers Only]] tonyp:
Well, I still do have a different point of view here (and it won't change).

It has the uttermost importance that emergency calls can be taken anytime.

And I do count in calls to other people here, not only the 911 / 112 / 110 / 999 / 000 calls.

In case of an emergency (of any kind whatsoever) I am more willing to allow a very unlikely privacy breach than a calling-not-working scenario.

Yes, like you described other things can fail (and are more likely to fail) as well, but I'm not willing to add another chance.

Again I strongly disagree here, I think a default-allow switch is absolutely needed. I described my reasons above and still stick to them.

I think we just have different feelings about privacy here. Yes, I want PDroid to be as safe as possible, but I wouldn't consider most of the data PDroid addresses as sensitive enough to justify a lockdown.

While you're describing a data leak as a horror scenario in your post, I would be willing to allow that in case of emergencies (and sometimes even for the sake of usability).

(Before anyone not involved in this discussion gets the wrong idea - we're talking of close-to-zero probabilities here).

If PDroid can somehow address both our use cases that'd great. But as long as it isn't I consider usability problems (like the slowdowns of the first version of the patches) of a higher priority as unlikely privacy leaking scnearios.

Someone attacking PDroid while there are millions of other users who're using Android the way Google built it (which is to grant all permissions when installing an app) is just too theoretic to justify it holding back further development on the usability side.

Once the App and the Core include all desired new features I'm totally in for getting rid of the last 0.000001% chance of a data leak, but until then I don't consider an attack on PDroid of current importance.

I know you'll disagree, but we just have to agree to disagree here :)