Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
On Sun, Aug 26, 2012 at 10:33 PM, Tom karbonki...@gmail.com wrote: So it's really a situation of a few bad apples ruining the whole bunch. I don't like them apples. Yup. And to the extent we can figure out ways to better filter the bad apples, without saying we cannot have any apples, the better off we are. Though, in retrospect, a better choice of fruit might be in order... :-) DeviceAdministrators are un-installable until they are disabled, and what's to stop an app from doing just that? Apps cannot enable or disable device administrators automatically. The device administrator path involves additional steps and warning prompts, to make it less likely that someone will set one up accidentally. So, for an app locker, it will make some sense why the app might need this capability; for some hacked version of Angry Birds, users will hopefully think twice. Again, it's just one idea for how to filter bad apples without avoiding apples entirely. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
I think my explanation of DeviceAdministrators was poor, I didn't mean to suggest that they can enable themselves. I dislike how DAs are un-installable until disabled but I do agree that it makes it more difficult to do malicious things this way. Pop-up permissions could also work, like in iOS (since that's where Android is headed). Why not prompt the user this app wants to do X, allow/ disallow. I know it's a pain but it then it doesn't break existing apps the same way absolute removal does. It's the same way with Accessibility, it's a pain for users to have to enable but at least that way good apps can do things like monitor notifications while bad ones might seem suspicious and never get a chance to do real harm. If that doesn't work I would have honestly suggested removing KILL_BACKGROUND_PROCESSEShttp://developer.android.com/reference/android/Manifest.permission.html#KILL_BACKGROUND_PROCESSESlong before removing the ActivityManager APIs. Task-killers aside, I can't think of any good uses for that permission. By removing it, don't you also remove the ability for apps to kill Settings and prevent the preventing of un-installation? Anyway, I think I'll start reading into OpenGL. Cross-platform, plus I could build live wallpapers with it (I think), which seems like a much safer development strategy than personalization apps that may or may not be permitted to exist in the future. BTW, it took until my app broke to know about the SET_ACTIVITY_WATCHERhttp://developer.android.com/reference/android/Manifest.permission.html#SET_ACTIVITY_WATCHERthing. Is there some official blog or something I can read to know when and why large changes like this might occur in advance? I'm wondering about other permissions too, like SYSTEM_ALERT_WINDOWhttp://developer.android.com/reference/android/Manifest.permission.html#SYSTEM_ALERT_WINDOW? That could also be quite dangerous in the wrong hands, but also quite useful too (another one I use). Tom On Monday, August 27, 2012 7:09:50 AM UTC-4, Mark Murphy (a Commons Guy) wrote: On Sun, Aug 26, 2012 at 10:33 PM, Tom karbo...@gmail.com javascript: wrote: So it's really a situation of a few bad apples ruining the whole bunch. I don't like them apples. Yup. And to the extent we can figure out ways to better filter the bad apples, without saying we cannot have any apples, the better off we are. Though, in retrospect, a better choice of fruit might be in order... :-) DeviceAdministrators are un-installable until they are disabled, and what's to stop an app from doing just that? Apps cannot enable or disable device administrators automatically. The device administrator path involves additional steps and warning prompts, to make it less likely that someone will set one up accidentally. So, for an app locker, it will make some sense why the app might need this capability; for some hacked version of Angry Birds, users will hopefully think twice. Again, it's just one idea for how to filter bad apples without avoiding apples entirely. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
On Mon, Aug 27, 2012 at 9:18 AM, Tom karbonki...@gmail.com wrote: If that doesn't work I would have honestly suggested removing KILL_BACKGROUND_PROCESSES long before removing the ActivityManager APIs. Task-killers aside, I can't think of any good uses for that permission. By removing it, don't you also remove the ability for apps to kill Settings and prevent the preventing of un-installation? Killing the Settings app is a nice to have -- simply preventing the user from accessing your app's page in Settings (by taking over the foreground yourself) would be sufficient to make it seriously annoying to get rid of an app short of safe-mode reboot, which is not a highly-documented technique. BTW, it took until my app broke to know about the SET_ACTIVITY_WATCHER thing. Is there some official blog or something I can read to know when and why large changes like this might occur in advance? Since the techniques you described are not part of the Android SDK -- so anyone using them should have expected them to break at any time, on any device -- we will not be informed officially regarding changes in their behavior. For example, the reason we were not informed about the changes in READ_LOGS is because reading the logs is not part of the SDK -- it took discussion on this Google Group to help nail down what happened there. I'm wondering about other permissions too, like SYSTEM_ALERT_WINDOW? That could also be quite dangerous in the wrong hands, but also quite useful too (another one I use). They changed some of the behavior of SYSTEM_ALERT_WINDOW a while back with regards to touch events and the tapjacking attack, IIRC, though I forget the details. To the best of my recollection, touch events that are intercepted by such windows cannot be delivered to the underlying app, but don't quote me on that. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
For what it's worth, there were a few interesting APIs that could accomplish this effect much better. IActivityWatcher (no longer exists in Jelly Bean), available 1.5 - 4.0 and never required a permission IProcessObserver (now guarded by the SET_ACTIVITY_WATCHER permission in Jelly Bean), available 3.0 - 4.0 and never required a permission IActivityController (always required SET_ACTIVITY_WATCHER permission which is only available to system apps) The last is perfect because you can return a boolean and the OS will allow/ deny an app from opening. Unlike App Lockers which simply kill the app AFTER they open, this stops it before then. Unfortunately, as of Android 4.1 Jelly Bean NONE of these are available for use with third-party applications (unless of course on rooted devices and installed in /system/app). The removal of these was more upsetting to me because at the end of the day they provide NO security benefit. If I REALLY want to know when the top app changes I will just poll every 100ms. These simply made it more efficient for me, no need to poll! I'm curious why those APIs are now enforced with a permission? I suppose there is the argument of no good use, but honestly is there a bad use? If the platform doesn't provide these features in the same version it was removed, users lose out. Oh well, what's done is done I'm just curious for some rationale. I guess Android is showing signs of maturation and going the way of iOS: becoming less hacker-friendly and a beautiful but closed garden. It was only a matter of time. Tom On Thursday, July 26, 2012 3:41:56 PM UTC-4, Bryan Ashby wrote: Now that READ_LOGS permission is not available to applications in Jelly Bean (API 16), what are developers of Application Locker type apps to do? These are populate applications among parents who would like to prevent their kids from accessing various apps (generally password protected) but the implementation of such applications has required a hack of reading logcat to determine when/what Activity has been launched or brought into focus. Surely Google is not saying You cannot have these apps? Is an official API (perhaps in the Device Admin realm) planned? Is there a work around besides polling the top level activity (not really reasonable). Google please advise! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
It's not just inconvenient because you have to poll: it's inefficient and forces the everlasting service pattern on an app, which means that you not only have to poll, you also have to write your app in a way that is inconsistent with good programming practices. kris On Sun, Aug 26, 2012 at 5:10 PM, Tom karbonki...@gmail.com wrote: For what it's worth, there were a few interesting APIs that could accomplish this effect much better. IActivityWatcher (no longer exists in Jelly Bean), available 1.5 - 4.0 and never required a permission IProcessObserver (now guarded by the SET_ACTIVITY_WATCHER permission in Jelly Bean), available 3.0 - 4.0 and never required a permission IActivityController (always required SET_ACTIVITY_WATCHER permission which is only available to system apps) The last is perfect because you can return a boolean and the OS will allow/ deny an app from opening. Unlike App Lockers which simply kill the app AFTER they open, this stops it before then. Unfortunately, as of Android 4.1 Jelly Bean NONE of these are available for use with third-party applications (unless of course on rooted devices and installed in /system/app). The removal of these was more upsetting to me because at the end of the day they provide NO security benefit. If I REALLY want to know when the top app changes I will just poll every 100ms. These simply made it more efficient for me, no need to poll! I'm curious why those APIs are now enforced with a permission? I suppose there is the argument of no good use, but honestly is there a bad use? If the platform doesn't provide these features in the same version it was removed, users lose out. Oh well, what's done is done I'm just curious for some rationale. I guess Android is showing signs of maturation and going the way of iOS: becoming less hacker-friendly and a beautiful but closed garden. It was only a matter of time. Tom On Thursday, July 26, 2012 3:41:56 PM UTC-4, Bryan Ashby wrote: Now that READ_LOGS permission is not available to applications in Jelly Bean (API 16), what are developers of Application Locker type apps to do? These are populate applications among parents who would like to prevent their kids from accessing various apps (generally password protected) but the implementation of such applications has required a hack of reading logcat to determine when/what Activity has been launched or brought into focus. Surely Google is not saying You cannot have these apps? Is an official API (perhaps in the Device Admin realm) planned? Is there a work around besides polling the top level activity (not really reasonable). Google please advise! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
On Sun, Aug 26, 2012 at 5:10 PM, Tom karbonki...@gmail.com wrote: The removal of these was more upsetting to me because at the end of the day they provide NO security benefit. If I REALLY want to know when the top app changes I will just poll every 100ms. These simply made it more efficient for me, no need to poll! You presume that the polling option will be maintained in future releases in its current incarnation. I would not make that assumption. I'm curious why those APIs are now enforced with a permission? You mean, besides the security and privacy reasons? For example, I've been personally reporting apps that use crap like this to prevent themselves from being uninstalled. The ability for any app to find out about the foreground, come to the foreground itself, then kill the background process, has always been seriously scary, even though knowledge of what is in the foreground has legit uses. I suppose there is the argument of no good use, but honestly is there a bad use? See above. If the platform doesn't provide these features in the same version it was removed, users lose out. Some users lose out, from lost (or less-efficient) functionality. Some users gain, from lost (or weakened) malware. Google, in their estimation, and given plans for upcoming releases, presumably believes that what they have done is a net gain. You, of course, are welcome to disagree. Oh well, what's done is done I'm just curious for some rationale. I guess Android is showing signs of maturation and going the way of iOS: becoming less hacker-friendly and a beautiful but closed garden. It was only a matter of time. You are welcome to contribute changes via the AOSP for a more controlled means of providing this sort of app-locker capability, such as via an extension to the device admin APIs. Of course, I wish that this contribution process would be substantially easier (and more likely to succeed) than it is. You are welcome to add app-locker capabilities to your favorite ROM mod, if the AOSP option is not working. You are welcome to make a complete fork of Android, if you so choose. You are also welcome to brainstorm other ways where app lockers can exist while the same techniques cannot be used for nefarious purposes. Personally, I think that's impossible -- the device admin approach at least makes it a whole lot less likely that a user will accidentally run into problems. But I have certainly been wrong before. Google's decision to make the Play Store be non-curated (i.e., no up-front manual inspection of apps, a la the iOS App Store and the Amazon AppStore for Android) means that Google is going to have to continue to tighten the screws to help prevent malware from doing the mal part. Yes, these changes will result in some fallout with some legit apps. And, one hopes that if they do remove the polling option that they turn around and expose something else that enables the legit apps while helping slow down the malware (e.g., making this information available via device admin APIs). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
You presume that the polling option will be maintained in future releases in its current incarnation. I would not make that assumption. Why should I not make *that *assumption? Those are *public *APIs in ActivityManager and the polling part could be done 100 different ways (Threads, Handler, TimerTasks, etc.) I guess I forget that Google has removed public APIs in the past so there is nothing stopping them from doing that again. You mean, besides the security and privacy reasons? For example, I've been personally reporting apps that use crap like this to prevent themselves from being uninstalled. The ability for any app to find out about the foreground, come to the foreground itself, then kill the background process, has always been seriously scary, even though knowledge of what is in the foreground has legit uses. So it's really a situation of a few bad apples ruining the whole bunch. I don't like them apples. Some users lose out, from lost (or less-efficient) functionality. Some users gain, from lost (or weakened) malware. Google, in their estimation, and given plans for upcoming releases, presumably believes that what they have done is a net gain. You, of course, are welcome to disagree. That's a fair point, but honestly at the current moment they just made malware less efficient. I have serious doubts that Google curbed an epidemic because of this. You are welcome to contribute changes via the AOSP for a more controlled means of providing this sort of app-locker capability, such as via an extension to the device admin APIs. Of course, I wish that this contribution process would be substantially easier (and more likely to succeed) than it is. You are welcome to add app-locker capabilities to your favorite ROM mod, if the AOSP option is not working. You are welcome to make a complete fork of Android, if you so choose. You are also welcome to brainstorm other ways where app lockers can exist while the same techniques cannot be used for nefarious purposes. Personally, I think that's impossible -- the device admin approach at least makes it a whole lot less likely that a user will accidentally run into problems. But I have certainly been wrong before. Google's decision to make the Play Store be non-curated (i.e., no up-front manual inspection of apps, a la the iOS App Store and the Amazon AppStore for Android) means that Google is going to have to continue to tighten the screws to help prevent malware from doing the mal part. Yes, these changes will result in some fallout with some legit apps. And, one hopes that if they do remove the polling option that they turn around and expose something else that enables the legit apps while helping slow down the malware (e.g., making this information available via device admin APIs). Unfortunately, from my perspective this only worsens fragmentation (not to beat a dead horse). At the end of the day, hackers will find a way around this (polling still works). DeviceAdministrators are un-installable until they are disabled, and what's to stop an app from doing just that? Once enabled, they listen for the opening of that Activity and force close it? I would have preferred something along the lines of notifying developers we will remove this API X and replace it with API Y in the next version similar to the READ_EXTERNAL_STORAGE permission. Too late for that. I would like to contribute to AOSP but I really don't have the time. I honestly don't even know how, but I've heard from other developers that you'll get nowhere fast offering enhancements. I just don't need to waste my time with that. Also, I develop applications even if they go a bit outside the SDK. AOSP is great but it powers a small percent of devices right now. Custom ROMs are FAR fewer. I don't target root users, I target the average user. My goal is to bring the personalization features of custom ROMs via applications to REAL Android devices. Unfortunately, I'm coming to terms with the fact that I either need to work a heck of a lot harder, or move on. To Google's pleasure I'm definitely leaning toward the later. Tom -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Why should I not make that assumption? Those are public APIs in ActivityManager and the polling part could be done 100 different ways (Threads, Handler, TimerTasks, etc.) I guess I forget that Google has removed public APIs in the past so there is nothing stopping them from doing that again. You shouldn't assume that because it's been said consistently over the past few months by Google engineers that this is a possibility. kris -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
On Fri, Jul 27, 2012 at 1:26 PM, Bryan Ashby nuskoo...@gmail.com wrote: Perhaps another solution is a API set and a new level of permission authentication. E.g., an developer would need to sign with a key that contains a trusted CA (Google stamp of approval or such) That is not how Android works. There are no CAs, no entity (including Google) who owns the platform to approve what apps can do. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
How about a broadcast to DeviceAdminReceiver. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Note that app-locking is not the only use-case for running-app- detection. My app does app-specific actions like 'if in Browser turn on wifi', 'if in Reader AND (if device orientation is vertical brightness high else brightness low)' However, Dianne has stated in another thread along the lines of the potential for abuse in app detection being too high, so don't be confident of a replacement for READ_LOGS. Pent p.s. I don't use READ_LOGS -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Generally if you can do this, it's kind of considered a security hole, and while these chinese wall policies are implementable, I'm a little skeptical as to their real utility... On Jul 27, 2012 2:09 AM, Pent supp...@apps.dinglisch.net wrote: Note that app-locking is not the only use-case for running-app- detection. My app does app-specific actions like 'if in Browser turn on wifi', 'if in Reader AND (if device orientation is vertical brightness high else brightness low)' However, Dianne has stated in another thread along the lines of the potential for abuse in app detection being too high, so don't be confident of a replacement for READ_LOGS. Pent p.s. I don't use READ_LOGS -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Generally if you can do this, it's kind of considered a security hole, By whom and for what reason ? while these chinese wall policies are implementable, I'm a little skeptical as to their real utility... Luckily my customers aren't. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Most people I know on this list argue that apps should never be allowed to change system behavior. I hope you understand the implications for apps that aren't legitimate, unlike yours. Sure there are hacks, removing them happens slowly. Whats your app title, since I'm assuming you won't disclose the trick you're using, people can at least disassemble it to find out, then submit patches to Android to ensure future versions make it diffult. On Jul 27, 2012 7:34 AM, Pent supp...@apps.dinglisch.net wrote: Generally if you can do this, it's kind of considered a security hole, By whom and for what reason ? while these chinese wall policies are implementable, I'm a little skeptical as to their real utility... Luckily my customers aren't. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
By the way, I think anyone at Google would argue this is a security hole, so I'm not alone On Jul 27, 2012 9:37 AM, Kristopher Micinski krismicin...@gmail.com wrote: Most people I know on this list argue that apps should never be allowed to change system behavior. I hope you understand the implications for apps that aren't legitimate, unlike yours. Sure there are hacks, removing them happens slowly. Whats your app title, since I'm assuming you won't disclose the trick you're using, people can at least disassemble it to find out, then submit patches to Android to ensure future versions make it diffult. On Jul 27, 2012 7:34 AM, Pent supp...@apps.dinglisch.net wrote: Generally if you can do this, it's kind of considered a security hole, By whom and for what reason ? while these chinese wall policies are implementable, I'm a little skeptical as to their real utility... Luckily my customers aren't. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
By the way, I think anyone at Google would argue this is a security hole, so I'm not alone They seem to allow services to do virtually anything that an activity can do at virtually any time. Doesn't seem to me they consider it a security hole. My app is called Tasker. It uses ActivityManager polling, which I detest. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
I didn't say that was a security hole, but I believe you could. What I said was bad was when an apparently could gain power over the system. AM polling is an option, but while it's a possible hack, they certainly don't *want* this, hence lack of an API, you can see the lengthy discussions as to the lack of a broadcast supporting this On Jul 27, 2012 10:00 AM, Pent supp...@apps.dinglisch.net wrote: By the way, I think anyone at Google would argue this is a security hole, so I'm not alone They seem to allow services to do virtually anything that an activity can do at virtually any time. Doesn't seem to me they consider it a security hole. My app is called Tasker. It uses ActivityManager polling, which I detest. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
By the way, I don't think your apparently shouldn't exist, I think there should be a way to extended system functionality in a secure way, and I don't think poor undocumented interfaces subject to change are the right way On Jul 27, 2012 10:05 AM, Kristopher Micinski krismicin...@gmail.com wrote: I didn't say that was a security hole, but I believe you could. What I said was bad was when an apparently could gain power over the system. AM polling is an option, but while it's a possible hack, they certainly don't *want* this, hence lack of an API, you can see the lengthy discussions as to the lack of a broadcast supporting this On Jul 27, 2012 10:00 AM, Pent supp...@apps.dinglisch.net wrote: By the way, I think anyone at Google would argue this is a security hole, so I'm not alone They seem to allow services to do virtually anything that an activity can do at virtually any time. Doesn't seem to me they consider it a security hole. My app is called Tasker. It uses ActivityManager polling, which I detest. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
App, not apparently, I have an overzealous autocorrect On Jul 27, 2012 10:13 AM, Kristopher Micinski krismicin...@gmail.com wrote: By the way, I don't think your apparently shouldn't exist, I think there should be a way to extended system functionality in a secure way, and I don't think poor undocumented interfaces subject to change are the right way On Jul 27, 2012 10:05 AM, Kristopher Micinski krismicin...@gmail.com wrote: I didn't say that was a security hole, but I believe you could. What I said was bad was when an apparently could gain power over the system. AM polling is an option, but while it's a possible hack, they certainly don't *want* this, hence lack of an API, you can see the lengthy discussions as to the lack of a broadcast supporting this On Jul 27, 2012 10:00 AM, Pent supp...@apps.dinglisch.net wrote: By the way, I think anyone at Google would argue this is a security hole, so I'm not alone They seem to allow services to do virtually anything that an activity can do at virtually any time. Doesn't seem to me they consider it a security hole. My app is called Tasker. It uses ActivityManager polling, which I detest. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
That activity manager API was never intended to be used to poll the state, it was there to provide debugging information. I regret making it part of the SDK. There is really no good use of it for regular applications, and lots of bad uses. I do agree that having facilities to provide restricted environments for children are important. I think the goal in the platform will probably be to provide this as a feature in the platform, not an API for people to build on top of. On Fri, Jul 27, 2012 at 8:00 AM, Pent supp...@apps.dinglisch.net wrote: By the way, I think anyone at Google would argue this is a security hole, so I'm not alone They seem to allow services to do virtually anything that an activity can do at virtually any time. Doesn't seem to me they consider it a security hole. My app is called Tasker. It uses ActivityManager polling, which I detest. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
Glad to see a response, thanks. While I think a platform feature vs an API set developers can access is better than nothing, it's also much too restrictive. What I mean by this is that parents and admins want to buy the devices they want to buy -- and still have the ability to lock them down. This goes for the consumer and enterprise world: - Consumers want the latest cool gadgets and/or the budget gadgets -- And they want parental controls on them. - Many enterprise users are now allowing BYOD policies as long as certain software is installed on them (e.g. for DLP, etc.) - Filtering solutions are very much like anti-virus anti-malware solutions: People have the one they trust; they don't want any others. Forcing buyers to stick with devices that have enabled parental control features for example is highly limiting, and I think, a mistake. Perhaps another solution is a API set and a new level of permission authentication. E.g., an developer would need to sign with a key that contains a trusted CA (Google stamp of approval or such) On Friday, July 27, 2012 1:26:16 PM UTC-6, Dianne Hackborn wrote: That activity manager API was never intended to be used to poll the state, it was there to provide debugging information. I regret making it part of the SDK. There is really no good use of it for regular applications, and lots of bad uses. I do agree that having facilities to provide restricted environments for children are important. I think the goal in the platform will probably be to provide this as a feature in the platform, not an API for people to build on top of. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
I just realized I may have misunderstood your response. If Android provided parental controls, again, it would be better than nothing, but very much too limiting. The main point in my list there is this: People want to choose their filtering / parental controls / enterprise control solution, not have one particular solution forced upon them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly Bean, READ_LOGS and 'Application Lockers'
On Fri, Jul 27, 2012 at 3:26 PM, Bryan Ashby nuskoo...@gmail.com wrote: Glad to see a response, thanks. While I think a platform feature vs an API set developers can access is better than nothing, it's also much too restrictive. What I mean by this is that parents and admins want to buy the devices they want to buy -- and still have the ability to lock them down. This goes for the consumer and enterprise world: Consumers want the latest cool gadgets and/or the budget gadgets -- And they want parental controls on them. Many enterprise users are now allowing BYOD policies as long as certain software is installed on them (e.g. for DLP, etc.) Filtering solutions are very much like anti-virus anti-malware solutions: People have the one they trust; they don't want any others. I still think all of this fits in the category of apps that can change system behavior, which doesn't fit into the current vision I have of the Android platform. (And, apparently, this view is shared by most others, given Google's philisophy and track record of restricting APIs that allow such things..) Forcing buyers to stick with devices that have enabled parental control features for example is highly limiting, and I think, a mistake. That have enabled them? Why would they ever be enabled by default? I think that at the current time the quick fix is for vendors to have specific apps integrated into their firmware (say, for example, your app, with a system signature or otherwise integrated into the platform), and then have vendors market their devices as being safe for kids. This is certainly a feature of Android that vendors do by default now (looking at recent ads for custom firmware extensions..) Perhaps another solution is a API set and a new level of permission authentication. E.g., an developer would need to sign with a key that contains a trusted CA (Google stamp of approval or such) Yes, that is one possible road for a system extension capability. I would also be interested in such a utility. However, a mere CA type signature probably won't really work (we've all seen CAs fall in the past, and while it helps, it might not be enough from a really mission criticial standpoint). I think one thing that may help is custom android extensions whose security implications can be verified and enforced at runtime may be an option, but I'm not sure of this. kris -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
