Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental(eff.org)
eff.org
Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental
https://www.eff.org/deeplinks/2013/12/google-removes-vital-privacy-features-android-shortly-after-adding-them
29 comments
I think the article is a tad misleading here, and I think your first link is going to add to the confusion.
The ability to revoke permissions was built right into the System Settings app, but the ability to access it was hidden from view. Custom roms would usually add a link to it, and apps like AppOps by ColorTiger (your first link) was simply a pointer that would trigger that view to activate (I'm glossing over the root functionality here).
What Google did in 4.4.2 was remove the hidden view from settings. This means that apps like ColorTiger's AppOps will no longer work at all- there is nothing for it to call. The pointer has been dereferenced, if you will.
Apps like LBE (which I share your desire for a newly updated, open source version which doesn't cause bootloops on newer versions of Android), PDroid, and presumably XPrivacy (which I've never heard of, but am looking into now for the inevitable upgrade to 4.4.2 if OmniRom is unable to provide a new solution) work because they replace the functionality that Google removed, not just call something built into Android, but hidden.
The ability to revoke permissions was built right into the System Settings app, but the ability to access it was hidden from view. Custom roms would usually add a link to it, and apps like AppOps by ColorTiger (your first link) was simply a pointer that would trigger that view to activate (I'm glossing over the root functionality here).
What Google did in 4.4.2 was remove the hidden view from settings. This means that apps like ColorTiger's AppOps will no longer work at all- there is nothing for it to call. The pointer has been dereferenced, if you will.
Apps like LBE (which I share your desire for a newly updated, open source version which doesn't cause bootloops on newer versions of Android), PDroid, and presumably XPrivacy (which I've never heard of, but am looking into now for the inevitable upgrade to 4.4.2 if OmniRom is unable to provide a new solution) work because they replace the functionality that Google removed, not just call something built into Android, but hidden.
The pointer has been dereferenced, if you will.
I do not think dereferenced means what you think it means.
I do not think dereferenced means what you think it means.
Holy shit, I feel like an idiot. Still, thanks for pointing it out.. keeps me humble.
Kids, if you're curious what we're talking about, look up dangling pointers in C, which is what I should have 'referenced' in the first place.
Kids, if you're curious what we're talking about, look up dangling pointers in C, which is what I should have 'referenced' in the first place.
It's OK – I hadn't realised that's what dereferenced meant either! Has been 10 years since I wrote any C though.
>The pointer has been dereferenced, if you will.
...'dereference' means 'access the pointed-to data'
...'dereference' means 'access the pointed-to data'
XPrivacy (FLOSS, uses Xposed framework, mostly fakes data instead of cancelling access, if possible) works for me: http://forum.xda-developers.com/showthread.php?t=2320783
It has some rough edges like asking me to check permissions after every (auto)update, even if app hadn't requested any new permissions, but allows relatively fine-grained (API function-name-level) permission control. Root permissions are only required to install Xposed, after Dalvik's runtime's hooked no root's required.
Oh, and "pro" features are useless (you can just build your own version from GitHub sources to enable export, and sharing is completely awkward without any UI to see what happened), but I still donated. Disclaimer: I have no affiliation to this project other than using it on my phone.
It has some rough edges like asking me to check permissions after every (auto)update, even if app hadn't requested any new permissions, but allows relatively fine-grained (API function-name-level) permission control. Root permissions are only required to install Xposed, after Dalvik's runtime's hooked no root's required.
Oh, and "pro" features are useless (you can just build your own version from GitHub sources to enable export, and sharing is completely awkward without any UI to see what happened), but I still donated. Disclaimer: I have no affiliation to this project other than using it on my phone.
There is an opensource privacy guard built into cyanogenmod. I just installed the latest nightly CM 11 on my phone (built off of latest android 4.4.2 kitkat), and was pleased to see textsecure integrated as the default SMS as well. Thankfully the CM community cares about things such as privacy...can't trust the big corporate behemoth google.
here's a translated version that i've been using this up to 4.3.(haven't updated my nexus phone to kitkat and am not planning to either)
http://forum.xda-developers.com/showthread.php?t=1422479
although i think this might also be working in kitkat. what i can recommend to users though is to use pdroid if they wish to do so. so you could use lbe for all apps. and pdroid for lbe itself. a lot of jelly bean custom roms support openpdroid. i personally use cyankang
http://forum.xda-developers.com/showthread.php?t=2212620
http://forum.xda-developers.com/showthread.php?t=1422479
although i think this might also be working in kitkat. what i can recommend to users though is to use pdroid if they wish to do so. so you could use lbe for all apps. and pdroid for lbe itself. a lot of jelly bean custom roms support openpdroid. i personally use cyankang
http://forum.xda-developers.com/showthread.php?t=2212620
xprivacy does the same thing, and seems to be actively developed. The only problem is that it has an atrocious UX, but again, that seems to be on par for most android utils.
Patch CyanogenMod with OpenPDroid, and install that. That's what I did.
i really miss lbe security on Android 4. Weird how it was abandoned.
You don't need root for that first app! I've been using it just fine without root. The description tells you what extra features you get with root, but you can handle the privacy issue without.
Yes you do need root for that first app if you have android 4.4.2 - which is what the whole discussion is about.
It seems really dumb of Google not to just go with the flow here and let the AppOps feature exist. Whack a giant disclaimer on it that it will break stuff, disable Play Store comments and ratings, let the users use it, and collect the giant PR dividend for looking like you care about privacy. They can do all that and lose virtually nothing because such a tiny percentage of people will ever use this feature that it will make no difference to them at all.
On the other hand they can go the other way and take a giant PR hit for virtually no benefit. Out of some sense of stubbornness or beligerance Google often seems to desire to shoot itself in the foot like this.
On the other hand they can go the other way and take a giant PR hit for virtually no benefit. Out of some sense of stubbornness or beligerance Google often seems to desire to shoot itself in the foot like this.
I'd love it if enabling a feature like just caused the selected data points to be returned, but completely bogus (invalid phone number, empty address list, north pole location, etc). It would work for almost everything except network access, and would ensure that it didn't break apps in a bad way.
The all-or-nothing data privacy model of android makes me a bit crazy now that I'm using it on a regular basis for my tablet. That's one thing BlackBerry got right - you can grant or deny individual permissions to applications, and generally could safely assume that application developers knew this and handled security access exceptions when trying to access protected data.
The all-or-nothing data privacy model of android makes me a bit crazy now that I'm using it on a regular basis for my tablet. That's one thing BlackBerry got right - you can grant or deny individual permissions to applications, and generally could safely assume that application developers knew this and handled security access exceptions when trying to access protected data.
I don't if it will break a lot of applications; probably some. The real problem is the permissions system that doesn't allow users to selectively choose which permissions they want to give to applications thus application developers don't code their applications to not work if they fail to get permission. Users are just shown a screen with the permissions the application requested.
For most users, this is worthless. Do any users decide not to install an application based on asking for too much? Users still don't have any control on stock systems over running services and applications in the background.
It is all 100% anti-users and pro-monetization; which is probably google's intention all along.
It is all 100% anti-users and pro-monetization; which is probably google's intention all along.
Users of Android should realize that they are the product. If Google gives too much privacy control, advertisers won't pay as much for ads, and Google's core business is ads.
Given a fight between privacy and ad dollars for Google, privacy will lose almost every time (within reason; Google doesn't want to kill the golden goose (i.e., you)).
Given a fight between privacy and ad dollars for Google, privacy will lose almost every time (within reason; Google doesn't want to kill the golden goose (i.e., you)).
I have to admit, the EFF has just lost a chunk of support from me over this. Google never released this feature - you needed to install some 3rd party app to expose the settings, this alone is enough for anyone of any intelligence to know they are doing something not intended for the general public.
Seriously EFF, get your act together please. I do want to support you, but not like this.
Seriously EFF, get your act together please. I do want to support you, but not like this.
All these abusive permissions are an excellent opportunity for GNU-licensed software (free, no ads, only strict minimum of required permissions -- all honestly explained) to thrive on Android.
> When asked for comment, Google told us that the feature had only ever been released by accident — that it was experimental, and that it could break some of the apps policed by it.
Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.
Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.
Yeah, because checking return codes and error values is overrated
Thanks Google, for making my phone less secure.
Thanks Google, for making my phone less secure.
Yeah, because checking return codes and error values is overrated
Even Google's own non-AOSP camera is guilty of this too.
The API docs says an app should check for camera capabilities before using them. Still the PhotoSphere feature in Google's non-AOSP camera attempts to set Flash-settings on devices with no flash-capability.
To overcome the issue you have to rewrite the camera-interface code to ignore API calls to SetFlash, SetLightmode etc when not supported, instead of throwing as you should be doing according to the docs.
So yeah. Even Google is guilty of this one.
Even Google's own non-AOSP camera is guilty of this too.
The API docs says an app should check for camera capabilities before using them. Still the PhotoSphere feature in Google's non-AOSP camera attempts to set Flash-settings on devices with no flash-capability.
To overcome the issue you have to rewrite the camera-interface code to ignore API calls to SetFlash, SetLightmode etc when not supported, instead of throwing as you should be doing according to the docs.
So yeah. Even Google is guilty of this one.
Google is one of the worse offenders when it comes to not following android guidelines. Their apps consistently break back button behavior, don't follow UI guidelines, etc.
By allowing you to install software they make your phone less secure. Better buy a feature phone ASAP!
It was never official, it was never announced nor documented.
I can't believe they question Google's authenticity when they say it was accidentally released too soon and then go on to criticize the feature for being unpolished and incomplete!
I think it's a great feature. There have definitely been some apps where I would have liked to use them but they've had permissions requirements that I did not believe the app's core functionality needed.
If you really want it, the CyanogenMod firware has something similar packaged with it.
every time I open facebook messanger with gps enabled, I see it querying my location. I hate it so much. Would love to be able to turn that off
Have you tried not opening it?
Seriously, if you use any of facebooks stuff, you clearly value something they offer more than your privacy. Everybody, and I'm not just talking about the HN crowd, knows how bad Facebook is when it comes to privacy.
Seriously, if you use any of facebooks stuff, you clearly value something they offer more than your privacy. Everybody, and I'm not just talking about the HN crowd, knows how bad Facebook is when it comes to privacy.
This is the sort of sad comment that continually amazes me. Facebook is am important part of the social life of millions (billions?) of people. It isn't feasible to go away from it. It's completely reasonable to have a requirement to use Facebook while not wanting it to be an ass about stuff like constant GPS fixes.
Yeah, sure, don't use Facebook. You're the guy who butts into conversations to tell everyone how you don't own a TV, aren't'cha?
Yeah, sure, don't use Facebook. You're the guy who butts into conversations to tell everyone how you don't own a TV, aren't'cha?
"It isn't feasible to go away from it."
Perhaps you could ask one of around 6 billion people in the world how they survive without this essential utility.
Perhaps you could ask one of around 6 billion people in the world how they survive without this essential utility.
> This is the sort of sad comment that continually amazes me.
Frankly, I'm stumped.
There's nothing sad about pointing out that you clearly:
1) Understand the privacy costs associated with Facebook
2) Choose, Yes, Choose to continue using it
What's sad is that you feel it's impossible to continue your social life without it.
Frankly, I'm stumped.
There's nothing sad about pointing out that you clearly:
1) Understand the privacy costs associated with Facebook
2) Choose, Yes, Choose to continue using it
What's sad is that you feel it's impossible to continue your social life without it.
Sorry to disappoint you, but the rest of America has basically abandoned email and Twitter isn't a serious medium for connections (at least, among non-technical people I know; I have a number of friends who use Twitter on the regular, but only a small few use it meaningfully). If you have friends--especially non-technical ones--who aren't in your local area (or, a lot of the time, aren't in your workplace) Facebook is very frequently the only way to keep in regular touch with most of them.
Network effects matter. That's not sad, that's simply reality. The lock-in effect is real and puts you in a position where, yes, you have to use it unless you wish to move out of contact with people. That doesn't mean you have to like it and it doesn't mean you can't, as the person you sneered at did, express a desire for its improvement.
Network effects matter. That's not sad, that's simply reality. The lock-in effect is real and puts you in a position where, yes, you have to use it unless you wish to move out of contact with people. That doesn't mean you have to like it and it doesn't mean you can't, as the person you sneered at did, express a desire for its improvement.
It's pretty feasible, you just don't want to give it up.
That's the typical response. Except that reality doesn't concur. People who stop using Facebook end up excluded from social circles. Not through malice, but because it's harder to be in contact with that one offhand person who Doesn't Even Own A TV--er, sorry, Doesn't Use Facebook. They're sand in the social gears.
(The self-centered prick's response of "then they're not real friends"--which I am addressing because it frequently comes next--willfully ignores that said self-centered prick is making it harder on everyone else to include them. They get excluded because they're being annoying. You have to give to get, and part of your giving is not making everyone else's life difficult because you're frothy about a web company.)
In the U.S. at least, if you have a basic appreciation of people you have formed friendships with over the years, if you value interacting with them over that self-centered Facebook froth, it's not feasible to ditch it. But you can still express a desire for it to improve.
(The self-centered prick's response of "then they're not real friends"--which I am addressing because it frequently comes next--willfully ignores that said self-centered prick is making it harder on everyone else to include them. They get excluded because they're being annoying. You have to give to get, and part of your giving is not making everyone else's life difficult because you're frothy about a web company.)
In the U.S. at least, if you have a basic appreciation of people you have formed friendships with over the years, if you value interacting with them over that self-centered Facebook froth, it's not feasible to ditch it. But you can still express a desire for it to improve.
I tend to keep GPS switched off in the phone settings because of this sort of thing.
FB is not allowed on my device in the first place because I don't trust it, but it's not the only offender. It really annoys me when I'm in-app or in-browser and I see the GPS icon pop up and start trying to get a lock. Sometimes even before the browser has asked if a page is allowed to have the location.
The answer is no!
FB is not allowed on my device in the first place because I don't trust it, but it's not the only offender. It really annoys me when I'm in-app or in-browser and I see the GPS icon pop up and start trying to get a lock. Sometimes even before the browser has asked if a page is allowed to have the location.
The answer is no!
Open the Facebook app -> App Settings -> Messenger location services -> Uncheck Location is on
Well ...
For me, it's things like Facebook, Dropbox, Google search, Twitter, Skype, and a plethora of others that one would expect to seamlessly allow for permissions adjustments.
I'm surprised this feature wasn't in place from day 1. It probably involves almost no implementation overhead on the OS side of things.
Apps, on the other hand, would have an extra error case to deal with, but they should be dealing with other error cases anyways.
Apps, on the other hand, would have an extra error case to deal with, but they should be dealing with other error cases anyways.
> "they should be dealing with other error cases anyways"
Especially when "Access to all your contacts" (or whatever) is really not needed for the application to work correctly.
Especially when "Access to all your contacts" (or whatever) is really not needed for the application to work correctly.
It's been a pretty shitty week for privacy, hasn't it? First the Disqus hack, then the changed Block feature on Twitter, and now this?
Twitter has gone back on that after listening to user feedback. I honestly think this 'App Ops' feature will also return, it was only found by sniffing about in the APKs and could only be activated (easily) by installing an app which surfaced the settings pane; that's not the same as it being a default menu option that was removed - it wasn't meant for public release yet. I appreciate the EFF and their stance on this but I'm giving Google the benefit of doubt on this one, hopefully we'll see it soon in its full glory.
The changed block feature on Twitter didn't do anything negative for privacy.
It took away users' ability to block other users from viewing their tweets? How is that not privacy?
I think the point is that if Alice hopes to hide her tweets from Eve by blocking Eve, then Eve can always log out of Twitter to see those tweets again.
Conclusion: Blocking users cannot ever be a privacy feature. You cannot prevent a specific user from seeing your tweets without preventing every un-logged-in person from seeing your tweets.
Edit: Though admittedly, that's a bit of a black-and-white perspective. I suppose blocking a user from seeing your tweets could work in the same way that hell-banning works: If Eve never logs out to check whether you blocked her, she won't find out. It's a bit of security through obscurity: far from ideal, but it might work for some practical problems.
Conclusion: Blocking users cannot ever be a privacy feature. You cannot prevent a specific user from seeing your tweets without preventing every un-logged-in person from seeing your tweets.
Edit: Though admittedly, that's a bit of a black-and-white perspective. I suppose blocking a user from seeing your tweets could work in the same way that hell-banning works: If Eve never logs out to check whether you blocked her, she won't find out. It's a bit of security through obscurity: far from ideal, but it might work for some practical problems.
After reading lots of discussion about this yesterday, I think the change being negative hinged on one big thing. Nobody truly believed that the old(current) block on Twitter was actually blocking anyone from reading your posts if they were public, but not being able to follow someone had the (imo) underrated benefit of not letting someone directly interact with your tweets.
That added layer of friction meant it was just a little more difficult for group harassment (e.g. retweet someone you don't like, laugh at them, have a group of your followers send harassing tweets even though they're not individually blocked). The only way to do so would be to open Incognito mode or log into another account and then manually RT or find another way to harass someone (like a forum or chat). The suggested new functionality meant that there was more security through obscurity (well not quite, apparently you couldn't add people that blocked you to lists) but reduced that friction in the harasser's favor.
Personally I'm hoping Twitter keeps the old block forever, but then adds something like the attempted new block functionality under the less-of-a-misnomer-name "mute" - both have their strengths and weaknesses and I don't think one can really replace the other.
That added layer of friction meant it was just a little more difficult for group harassment (e.g. retweet someone you don't like, laugh at them, have a group of your followers send harassing tweets even though they're not individually blocked). The only way to do so would be to open Incognito mode or log into another account and then manually RT or find another way to harass someone (like a forum or chat). The suggested new functionality meant that there was more security through obscurity (well not quite, apparently you couldn't add people that blocked you to lists) but reduced that friction in the harasser's favor.
Personally I'm hoping Twitter keeps the old block forever, but then adds something like the attempted new block functionality under the less-of-a-misnomer-name "mute" - both have their strengths and weaknesses and I don't think one can really replace the other.
They never had that ability (besides making their tweets private, but that's not what blocking is). Blocked users can just log out or log in under an alternate account in order to view the person's tweets.
You just used the term "making their tweets private". If we can't agree this constitutes a privacy feature - however small in scope - I think we'll just have to agree to disagree. :)
Huh? Using a phrase out of context doesn't mean you can insert it into his argument. He explicitly said, pretty much, "it's not about making their tweets private". Blocking wasn't a privacy feature.
You just used the words "insert", "explicitly", and "private." If we can't agree this constitutes hardcore pornography - however small in scope - I think we'll just have to agree to disagree. :)
[deleted]
This was not officially released, nor was it user facing.
I hope it wasn't just an "accident" and Google really was working on a way to make it work for both developers and users, and perhaps it was there much like the ART runtime is in there, even though it's not ready for primetime.
I think Google can make it work, but they need to be committed to it. Surely there's a way for the apps to gracefully transition to not needing certain permissions. Google just needs to introduce the proper rules for developers to make this work.
I think Google can make it work, but they need to be committed to it. Surely there's a way for the apps to gracefully transition to not needing certain permissions. Google just needs to introduce the proper rules for developers to make this work.
I don't have hopes of Google restoring the AppOps functionality in the future. Most of the apps require these excessive permissions because of third-party ad libraries. Google's AdMob library is the most popular of these libraries, being used in 36% of Android apps [1].
[1] : http://www.appbrain.com/stats/libraries/ad
[1] : http://www.appbrain.com/stats/libraries/ad
I didn't use App Ops. Did it allow a general policy to be set? I can see you can set permission per app from the screen shot.
I'm not sure I buy Google's excuse. Any app worth it's salt should be able to cope with not having the permission set. I'm guessing this was impacting their own core apps.
I'm not sure I buy Google's excuse. Any app worth it's salt should be able to cope with not having the permission set. I'm guessing this was impacting their own core apps.
> Any app worth it's salt should be able to cope with not having the permission set.
That doesn't in any way follow. My Android application handles the expected failure cases enumerated in the API. It does not handle the "permissions granted when the user saw your manifest and agreed to grant those permissions disappear because reasons" case because they're is no reasonable expectation that case is necessary. The APIs don't allow for that case, if it throws a catchable exception at all it'll be an undocumented one, I can't differentiate between it any other exception that might roll out of Android. Why would be anything other than unhandled?
Which isn't to say that data permissions should not be mockable; they should. But your "anything I don't understand is easy" post is straight-up bad.
That doesn't in any way follow. My Android application handles the expected failure cases enumerated in the API. It does not handle the "permissions granted when the user saw your manifest and agreed to grant those permissions disappear because reasons" case because they're is no reasonable expectation that case is necessary. The APIs don't allow for that case, if it throws a catchable exception at all it'll be an undocumented one, I can't differentiate between it any other exception that might roll out of Android. Why would be anything other than unhandled?
Which isn't to say that data permissions should not be mockable; they should. But your "anything I don't understand is easy" post is straight-up bad.
Whatever, fuck Google.
If you are interest in doing this with Android, the autopatcher[0] does this for you on a whole series of ROMs on all versions of Android from 2.x-4.x, and has been doing so successfully for a while. There is a pretty active user community on XDA for the PDroid patchset as well.[1]
[0] https://github.com/mateor/auto-patcher
[1] http://forum.xda-developers.com/showthread.php?t=1357056
If you are interest in doing this with Android, the autopatcher[0] does this for you on a whole series of ROMs on all versions of Android from 2.x-4.x, and has been doing so successfully for a while. There is a pretty active user community on XDA for the PDroid patchset as well.[1]
[0] https://github.com/mateor/auto-patcher
[1] http://forum.xda-developers.com/showthread.php?t=1357056
> Whatever, fuck Google.
Well this is going to be productive.
I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.
Well this is going to be productive.
I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.
I don't know if you read the article properly (or maybe I didn't) but the 'accident' was improved privacy. Then they took the better privacy feature out. So that could qualify for a fuck Google comment.
I don't know if you read the article properly but this was never an actual feature. They were debug screens that required a third-party app to access. There's no way to access these settings at all from the system UI.
See, if the accident was a button that fried your phone, your comment wouldn't actually lose any meaning.
Right on, right on. While I like the potential of this app, the millions of devices with billions of applications that would simply stopping working with its introduction mean it will need a carefully orchestrated rollout. HN readers might be comfortable with "ever beta" technologies, but the other 99% of users are not (and it's odd that smart people fail to appreciate this).
"billions of applications that would simply stopping working".
So what? The user can just re-enable the app's access to whatever it was trying to fetch.
I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose.
Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.
So what? The user can just re-enable the app's access to whatever it was trying to fetch.
I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose.
Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.
The point is not to protect apps that are overreaching, by intent or just sloppy permissions, but to reduce the chance of unexpected behaviour to the customer (or if you're tinfoil hat , "the product").
The implementation on the part of the developer may be tiny, but you still have to have give those companies time to make and test the changes. Look what happens when companies move the Send button or whatever on their UI-- I tidal wave of internet bile comes rolling in. An app developer might appreciate a heads up before deluging their inbox/tracker with complaints and 1 star reviews.
The implementation on the part of the developer may be tiny, but you still have to have give those companies time to make and test the changes. Look what happens when companies move the Send button or whatever on their UI-- I tidal wave of internet bile comes rolling in. An app developer might appreciate a heads up before deluging their inbox/tracker with complaints and 1 star reviews.
No, because people coded to the API they were given. They got permission through the application's manifest, as specified by the documentation. They coded to standards. Dynamically revoking permissions breaks that contract.
It sounds like you are more familiar with web frontend programming. I'd caution you that Android app development has differences that are important to this discussion.
It sounds like you are more familiar with web frontend programming. I'd caution you that Android app development has differences that are important to this discussion.
>> "Dynamically revoking permissions breaks that contract."
While I'm no expert in native app dev, it's interesting to see so many people are so confident the apps will break under those circumstances, without actually any first hand experience.
I would likewise caution anyone putting forward this idea, that unless you've seen the effect revoking permissions has had on your app, or another app, then anything you put forward in this discussion is hearsay.
I'm not jumping on the meme train about millions of apps crashing due to permission revoking. Google should just include the feature, and have it default to off, with appropriate warnings about tripping some apps when switched on. It doesn't need to be a complicated thing.
While I'm no expert in native app dev, it's interesting to see so many people are so confident the apps will break under those circumstances, without actually any first hand experience.
I would likewise caution anyone putting forward this idea, that unless you've seen the effect revoking permissions has had on your app, or another app, then anything you put forward in this discussion is hearsay.
I'm not jumping on the meme train about millions of apps crashing due to permission revoking. Google should just include the feature, and have it default to off, with appropriate warnings about tripping some apps when switched on. It doesn't need to be a complicated thing.
> millions of devices with billions of applications that would simply stopping working
[citation needed]
[citation needed]
There is a way of bringing it back, however the phone has to be rooted. See here: http://www.xda-developers.com/android/xposed-module-brings-b...
This is one area where iOS stands head and shoulders above Android. I used to run Cyanogenmod and I remember deciding to not upgrade the Facebook app because doing so would have required giving it a slew of permissions, including the ability to "directly call phone numbers".
By contrast, in iOS, I can choose which apps have access to my location, contacts, etc.
I know that Apple's track record when it comes to privacy isn't exactly spotless but Google would be well advised to follow their lead in allowing users granular control over 3rd-party apps' permissions.
By contrast, in iOS, I can choose which apps have access to my location, contacts, etc.
I know that Apple's track record when it comes to privacy isn't exactly spotless but Google would be well advised to follow their lead in allowing users granular control over 3rd-party apps' permissions.
Do not expect Google to implement it anytime soon, due to the massive app breakage potential.
Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis.
On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.
Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis.
On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.
There is almost zero app breakage potential. Because the implementation shouldn't be refusing permissions, it should simply be mocking them. Ask for a location? Mock it to an arbitrary location. Asking for contacts? Return an empty list, or a list with [email protected]. Etc.
> ..the implementation shouldn't be refusing permissions, it should simply be mocking them. Ask for a location? Mock it to an arbitrary location.
Like 38° 53' 50.55", -77° 2' 14.51"
Like 38° 53' 50.55", -77° 2' 14.51"
This is somewhere where android fragmentation is truly an issue. iOS didn't have granular switchable permissions a couple of versions ago but as the OS moved forward so did the apps.
Do not expect Google to implement it anytime soon, due to the massive app breakage potential.
I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app.
I think this potential is vastly overblown.
EDIT: for example, in the official twitter app, I turn off these:
* Location
* Read contacts
* Receieve SMS/MMS
* Post notification
* Wake lock
Never had a single problem with the app.
I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app.
I think this potential is vastly overblown.
EDIT: for example, in the official twitter app, I turn off these:
* Location
* Read contacts
* Receieve SMS/MMS
* Post notification
* Wake lock
Never had a single problem with the app.
As long as the disallowed permissions simply return empty results (or random stuff) for the API calls, I don't see how this can break apps.
AFAIK, AppOps doesn't do this, it throws a java exception when the app code attempts to use a permission that has been disabled. Depending on how the code is structured, you may or may not have your app break/crash.
CyanogenMod has this killer feature called Privacy Guard which you can enable on a per-app basis. It allows you to use the app and lock it out of unwanted permissions without breaking the app functionality.
So far, I've been an Android fan (I love the customizability and all), but if anything will make me buy an iPhone, it's this feature.
BlackBerry actually gave completely granular permission controls for every app you install, as far back as five years ago. It's a shame that neither iOS or Android have come anywhere close in that regard.
By contrast, in iOS, I can choose which apps have access to my location, contacts, etc.
Could you detail the "etc"? To my knowledge historically the only activity that triggered a permission confirmation was a precise location fix. Later, after a debacle with many apps siphoning and scurrilously offloading contact lists, contact access was added as a confirmation.
Android has very granular permissions, and iOS does not. If you don't like the requests of an app, the general option is not to install it. Such is exactly what I've done with a number of small vendor apps -- if you demand anything that you don't need, I don't install.
Of course on the flip side Android, be design, allows for much tighter integration and leveraging between apps and the OS, so there are more interesting opportunities, both for good and bad. But those, too, are covered under permissions.
Could you detail the "etc"? To my knowledge historically the only activity that triggered a permission confirmation was a precise location fix. Later, after a debacle with many apps siphoning and scurrilously offloading contact lists, contact access was added as a confirmation.
Android has very granular permissions, and iOS does not. If you don't like the requests of an app, the general option is not to install it. Such is exactly what I've done with a number of small vendor apps -- if you demand anything that you don't need, I don't install.
Of course on the flip side Android, be design, allows for much tighter integration and leveraging between apps and the OS, so there are more interesting opportunities, both for good and bad. But those, too, are covered under permissions.
In iOS7 you can granularly allow/disallow apps access to: location services, contacts, calendars, reminders, photos, bluetooth sharing, microphone, motion activity (iPhone 5S and new iPads only)
The first time an app tries to access any of the above you will be asked whether to grant it permission or not. You can then edit this preferences in Settings.app > Privacy
The first time an app tries to access any of the above you will be asked whether to grant it permission or not. You can then edit this preferences in Settings.app > Privacy
I think benefit of iOS privacy controls is that you can still install the app, then simply deny it access to data. Android asks you for _all_ permissions up front: allow access or you don't get the app. See: recent flashlight app fiasco.
I absolutely agree with this. It was very shortsighted that apps weren't, from day one, warned that certain permission types are optional. And it's a mistake with every version of the SDK that they don't add the ability for apps to set permissions as such. Instead it continues that apps work on the notion that if they are running, they must have the permission, when just a few null/error checks would save the day.
Looking at the Settings area on my phone, it is possible in iOS 6 to set App-level permissions for:
-Push Notifications
-Location Services
-Contacts
-Calendars
-Reminders
-Photos
-Bluetooth
-Twitter Account Access
-Facebook Account Access.
Note that iOS7 may have added more.
My only complaint is iOS apps know if the permission is denied, so every time you switch to them they can ask you to enable permissions which is annoying (Facebook messenger). I wish they just returned no data.
That might work for contacts, but what does it mean to "return no data" for location services or bluetooth? In those cases isn't "no data" indistinguishable from "disallowed permission"?
Android's permissions are not granular enough and forcing the user to accept them all or not use the app is a security/privacy fail. I love that Android apps can access the telephony API but the permissions for that need to be more fine grained and the toggles to enable them need to be discreet over individual permissions.
Discreet toggles and the request dialogs are roughly the only thing I prefer iOS to Android on. Too bad the rest of iOS is a prison.
Discreet toggles and the request dialogs are roughly the only thing I prefer iOS to Android on. Too bad the rest of iOS is a prison.
The original intention (as explained by Dianne Hackborn among others) is that if the user sees the app requesting too many capabilities... the user should simply choose not to install the app. Having the user needing to understand all the different capabilities is too much. Having a bunch of pop-ups (cough Vista) is also bad UI design.
The current set of capabilities is too technical for end users to really understand. This all need to be collapsed into a few broad areas like "tracks your location" that have clear, clickable explanations.
For the privacy paranoid, having a configurable way to just inject false data would be great. Have a single fake IMEI number, for example. Then for apps, the API call doesn't fail, it just returns the fake number.
The current set of capabilities is too technical for end users to really understand. This all need to be collapsed into a few broad areas like "tracks your location" that have clear, clickable explanations.
For the privacy paranoid, having a configurable way to just inject false data would be great. Have a single fake IMEI number, for example. Then for apps, the API call doesn't fail, it just returns the fake number.
I can choose not to install an app, but Google prevents me from doing it intelligently, that is, filtering the crappy apps demanding ridiculous permissions. I have to manually click on dozens of them before finding one that does not require, say, Internet access. APEFS (http://www.bs.informatik.uni-siegen.de/forschung/apefs) allowed such filtering, but since Google Play was updated some months ago, it stopped working and was removed. Now I have to resort to F-Droid for free apps, but there are not nearly as many as in Google Play.
Exactly. The Play Store does not allow me to sort by permissions and doesn't display them up-front, making concern about permissions a fruitless endeavor.
Give me a fuzzy-sort option where I can just apply weightings to how much I value out of (1) Permissions, (2) Popularity, (3) Price and (4) Relevance
Give me a fuzzy-sort option where I can just apply weightings to how much I value out of (1) Permissions, (2) Popularity, (3) Price and (4) Relevance
Yes, exactly. I recently had to look through a dozen flashlight apps to find one that was non-scammy. Finally I found a couple that didn't require Internet access as well as personal information. Sheesh. Maybe I should have just written one myself.
> Have a single fake IMEI number, for example.
How would that work in countries where modifying the IMEI is illegal?
UK law (note prison sentence) http://www.legislation.gov.uk/ukpga/2002/31/section/1
I don't know if this is current US law or not. Here's one example http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS:
How would that work in countries where modifying the IMEI is illegal?
UK law (note prison sentence) http://www.legislation.gov.uk/ukpga/2002/31/section/1
I don't know if this is current US law or not. Here's one example http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS:
The suggestion was making a userspace call to retrieve the IMEI return a fake value, not modifying the IMEI itself. Perfectly legal, although I imagine a great legal battle could be fought over the interpretation of "interfere with the operation of".
I am, however, surprised that MAC spoofing is enough to get you a prison sentence if done on a "mobile wireless communications device".
EDIT: apparently as of a 2006 addendum in the "Violent Crime Reduction Act" even offering to do it for someone else will land you in the clink. Gotta keep those violent hackers off the streets I guess.
I am, however, surprised that MAC spoofing is enough to get you a prison sentence if done on a "mobile wireless communications device".
EDIT: apparently as of a 2006 addendum in the "Violent Crime Reduction Act" even offering to do it for someone else will land you in the clink. Gotta keep those violent hackers off the streets I guess.
That law seems particularly draconian. I assume it's an attempt to criminalise the changing of IMEIs on stolen phones? Reading that is slightly alarming, if only because I wouldn't have even considered that it could be illegal before today. I wonder how many other pieces of legislation I've naively violated?
I don't think android would affect the IMEI that gets sent to the network, and the intent of the law was to allow tracking of phones by IMEI (kinda scary in itself, kinda useful for law enforcement) and to allow stolen phones to be blocked from the network and rendered useless, which AFAICT has had a huge impact on levels of phone theft.
>> But a person does not commit an offence under this section if—
>> (a)he is the manufacturer of the device, or
>> (b)he does the act mentioned in subsection (1) with the written consent of the manufacturer of the device.
Perhaps the manual that comes with your phone could come with a line in the license saying that modifying the IDs for the purposes of stopping apps snaffling data is allowed.
>> But a person does not commit an offence under this section if—
>> (a)he is the manufacturer of the device, or
>> (b)he does the act mentioned in subsection (1) with the written consent of the manufacturer of the device.
Perhaps the manual that comes with your phone could come with a line in the license saying that modifying the IDs for the purposes of stopping apps snaffling data is allowed.
It would modify it on the application level (user apps are sandboxed anyways), but not on the system/telephony level. System would still be aware of what the real IMEI is, just not whatever shady app requesting the permission.
That is one of the more shortsighted laws I have ever read. Or farsighted, depending on your cynicism about surveillance.
I wonder if I generate a UUID on your phone in my app, if you delete the app data does that run afoul of this law?
I wonder if I generate a UUID on your phone in my app, if you delete the app data does that run afoul of this law?
I think it's really about the IMEI on stolen phones, rather than anything else. And it's in the UK, where there are differences in legal procedure to US. But the DMCA is supposed to be about copyright protection and yet it's being used to keep phones locked to a carrier, so laws with unintended consequences are worrying.
This is a pretty disturbing trend. Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. I don't think the general public realizes location can be equivalent to a person's id.
> I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out.
This is exactly what I want most of the time. My ISP's servers are usually in neighboring cities, so geoip isn't precise enough, but GPS is too precise for my needs. I just want to disclose what city I'm in. This is enough info to give me useful results (e.g. I search Google for "italian restaurants", it gives me results for my city first) without violating my privacy by giving Google my location habits. Maybe OSes could give an option to reduce the granularity of the location reported, so you could disclose the town or state, but not the exact street, for instance.
This is exactly what I want most of the time. My ISP's servers are usually in neighboring cities, so geoip isn't precise enough, but GPS is too precise for my needs. I just want to disclose what city I'm in. This is enough info to give me useful results (e.g. I search Google for "italian restaurants", it gives me results for my city first) without violating my privacy by giving Google my location habits. Maybe OSes could give an option to reduce the granularity of the location reported, so you could disclose the town or state, but not the exact street, for instance.
There are apps to "fake" your location so maybe you can find a suitable one. I never used one but my external Bluetooth GNSS device feeds its accurate location into Android the same way. Please share if you do find a good one!
>>>Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled.
When it comes to things such as entertainment, regional rights restrictions probably have more to do with that than the app wanting to spy on you. I'm not saying this is right. Just saying how the lawyers have sliced things into pieces like that.
When it comes to things such as entertainment, regional rights restrictions probably have more to do with that than the app wanting to spy on you. I'm not saying this is right. Just saying how the lawyers have sliced things into pieces like that.
They could get that region-level information already from ISP routing info. This ratcheting up of info means: The household owner's name, their affluence, postal code, phone number, a cross match with google street view and all info that shows (new car?). The last thing I want is to watch a home reno show on a tablet and then be deluged with phone calls soliciting for new windows. This is definitly not 'right'.
(edit: on top of watching ads that glitch and repeat.)
>>>They could get that region-level information already from ISP routing info.
I think they want to know you are where you say you are. You'll find if you travel out of the area -- particularly out of the entire country -- you won't have access to entertainment you had while at home due to these regional restrictions. Just think of the times when you've gone to the BBC website to view a video only to be told you can't have it outside of the UK (the BBC license area). (Note that I'm assuming you're in the US although your use of "postal code" likely means you aren't.)
I think they want to know you are where you say you are. You'll find if you travel out of the area -- particularly out of the entire country -- you won't have access to entertainment you had while at home due to these regional restrictions. Just think of the times when you've gone to the BBC website to view a video only to be told you can't have it outside of the UK (the BBC license area). (Note that I'm assuming you're in the US although your use of "postal code" likely means you aren't.)
I'm really disappointed, seems like my next phone won't carry Android!
App opps worked great for me and help alleviate some worries about tracking. I could also see which apps actually used their claimed Android features. Many of them claim to use location yet never access it.
I'm probably going to turn in to that old guy with tin foil who can't play any games because nobody supports his choice of platform, but I really miss when computers were devices you could buy and then put your choice of OS on. Phones are pretty much just little ARM computers, why the hell don't I just install Ubuntu, Firefox OS, Android, WinPhone, Symbian, whatever? I could format a microSD card to boot from and go from there.
And while I'm complaining, phones (devices for communication, remember?) need proper keyboards.
OK. I'll crawl back into my cave now.
And while I'm complaining, phones (devices for communication, remember?) need proper keyboards.
OK. I'll crawl back into my cave now.
Re. proper keyboards - the market says otherwise. There have been plenty of Android phones with hard keyboards but they've not sold in sufficient quantities to make it attractive.
If there was a market for it, people would be making them, if you disagree with that they what are you doing on here, your fortune awaits...
Also worth seeing kids who've never used a physical keyboard to any great extent. I've seen them doing what must be close to 60 words a minute on a touch screen (tablet rather than phone but still). If you're used to it a touch screen keyboard isn't a massive limiting factor.
EDIT: This is interesting: http://psychology.wichita.edu/surl/usabilitynews/122/ipadtyp...
A study showing netbooks to have a typical typing speed of around 60WPM vs 40WPM for iPad, but interestingly it mentions that none of the participants had used an iPad.
I'm guessing that someone with significant experience on a particular OS / soft keyboard with correction could close that gap pretty sharpish.
EDIT2: http://thinkertry.com/2012/10/30/typing-speed-test-iphone-vs...
Someone testing iPhone, iPad and keyboard two years running:
2011: iPhone: 57 wpm, iPad: 60 wpm, Keyboard: 71 wpm 2012: iPhone: 51 wpm, iPad: 75 wpm, Keyboard: 82 wpm
It seems that practice does indeed close the gap. Given that the total install base for touchscreen devices will exceed that for PCs in the next 12 months (probably next 6), that greater level of familiarity will shortly become standard.
If there was a market for it, people would be making them, if you disagree with that they what are you doing on here, your fortune awaits...
Also worth seeing kids who've never used a physical keyboard to any great extent. I've seen them doing what must be close to 60 words a minute on a touch screen (tablet rather than phone but still). If you're used to it a touch screen keyboard isn't a massive limiting factor.
EDIT: This is interesting: http://psychology.wichita.edu/surl/usabilitynews/122/ipadtyp...
A study showing netbooks to have a typical typing speed of around 60WPM vs 40WPM for iPad, but interestingly it mentions that none of the participants had used an iPad.
I'm guessing that someone with significant experience on a particular OS / soft keyboard with correction could close that gap pretty sharpish.
EDIT2: http://thinkertry.com/2012/10/30/typing-speed-test-iphone-vs...
Someone testing iPhone, iPad and keyboard two years running:
2011: iPhone: 57 wpm, iPad: 60 wpm, Keyboard: 71 wpm 2012: iPhone: 51 wpm, iPad: 75 wpm, Keyboard: 82 wpm
It seems that practice does indeed close the gap. Given that the total install base for touchscreen devices will exceed that for PCs in the next 12 months (probably next 6), that greater level of familiarity will shortly become standard.
> If there was a market for it, people would be making them, if you disagree with that they what are you doing on here, your fortune awaits...
This is incredibly disingenuous because of the high barrier to entry on cellphone manufacturing.
This is incredibly disingenuous because of the high barrier to entry on cellphone manufacturing.
It's an offhand line but the point stands - people who have the resources to overcome the barrier have tried and the phones don't sell in great numbers.
Once they get used to a good soft key board like you get on the iPhone or most Android phones people either don't want (or don't feel they need I suspect) physical keyboards.
Once they get used to a good soft key board like you get on the iPhone or most Android phones people either don't want (or don't feel they need I suspect) physical keyboards.
That a large company can make enough money by focusing on one type of phone, thus not splitting their engineering efforts doesn't mean that there wouldn't be a viable niche market, if not for barrier to entry.
I often hear people lament the design of their phone, caused by the preferences of the majority.
I often hear people lament the design of their phone, caused by the preferences of the majority.
It's hard enough to make a profit on popular phones, as evidenced by the woes of HTC, Blackberry and others... making a phone for a niche group, especially if you can't charge materially more (and I mean $1,000 or more, unlocked) just doesn't make any sense. Particularly when you consider that carrier and OEM marketing (large national campaigns, in-store placement, etc) doesn't scale down to small volume products.
Making niche products doesn't work well for consumer electronics in general, unless you can sell that product at a much higher margin. Having a keyboard on a phone just doesn't seem to result in being able to sell it for twice as much.
Another issue with keyboards is they don't internationalize well. So rather than having 1 hardware design worldwide, you now either need a TON of SKUs - one for each country (and you can't move inventory from one market to another) or you need to further limit your target market to just a few regions.
Making niche products doesn't work well for consumer electronics in general, unless you can sell that product at a much higher margin. Having a keyboard on a phone just doesn't seem to result in being able to sell it for twice as much.
Another issue with keyboards is they don't internationalize well. So rather than having 1 hardware design worldwide, you now either need a TON of SKUs - one for each country (and you can't move inventory from one market to another) or you need to further limit your target market to just a few regions.
You can sell a pluggable device, no need to produce the whole phone
A pluggable device doesn't offer the same experience as having a physically built-in keyboard.
You're right, it's better, since you don't have to sacrifice screen area for the keyboard
There were Android phones with keyboards. I had the chance to play with a prototype in 2009 (yes, this was after the iPhone)
Not good. Not good at all.
There were Android phones with keyboards. I had the chance to play with a prototype in 2009 (yes, this was after the iPhone)
Not good. Not good at all.
You don't have to sacrifice screen space for a physical keyboard... http://upload.wikimedia.org/wikipedia/commons/a/a6/DROID_3.j...
That form factor is fine, although not popular with consumers. I had a Droid 2 for a while, and found myself using the soft-keyboard more and more, particularly while not using connectbot.
That form factor is fine, although not popular with consumers. I had a Droid 2 for a while, and found myself using the soft-keyboard more and more, particularly while not using connectbot.
I had one of the first generation Droids, and much preferred that form factor to any later smart phone I had, largely because of easy access to keys normally hidden behind layers of menu.
Yes, the prototype I tested was similar
But the keys are too small for the fingers (IMHO). And it's a fragile item in the hardware.
But the keys are too small for the fingers (IMHO). And it's a fragile item in the hardware.
The problems I had with it were primarily related to build-quality I think. The 'i' key wore out after several months for example. I think these problems could likely be fixed by not skimping on the parts, but who knows.
Poor Motorizon can barely afford to make those Droids... wait, no.
There's actually something fairly interesting at play that should be mentioned: Typing with a physical keyboard is much more accurate than a touchscreen, but a touchscreen makes up this deficiency by a much simpler to use word completion feature. Error correction is also a breeze. Most of the words written in this post took advantage of those factors, and it took me about a minute to type everything up.
Two things:
1) Depends on the keyboard - the research I've posted showed that against a netbook keyboard, an iPad in landscape mode had greater accuracy.
2) Agree on the autocorrect features and it's something I've noticed this with touchscreen typing.
It's taken me a while to get used to the auto-correct features. It used to be that they were basically a prompt that something was wrong that I'd retype mannually, now my instincts work with them.
They also act as autocomplete when you're used to them - either fully or with edits (it'll often prompt with the right root word but with a different ending - say regretfully instead of regretful - in some cases it's quicker to accept it's suggestion and then delete than to continue typing, once you're used to it).
1) Depends on the keyboard - the research I've posted showed that against a netbook keyboard, an iPad in landscape mode had greater accuracy.
2) Agree on the autocorrect features and it's something I've noticed this with touchscreen typing.
It's taken me a while to get used to the auto-correct features. It used to be that they were basically a prompt that something was wrong that I'd retype mannually, now my instincts work with them.
They also act as autocomplete when you're used to them - either fully or with edits (it'll often prompt with the right root word but with a different ending - say regretfully instead of regretful - in some cases it's quicker to accept it's suggestion and then delete than to continue typing, once you're used to it).
User preferences != the market. They are half the market.
What this really says is that virtual keyboards have practically no cost, and so utilizing them instead of physical keyboards saves more in marginal (and perhaps per-unit) cost than the revenue from lost customers that require a physical keyboard.
What this really says is that virtual keyboards have practically no cost, and so utilizing them instead of physical keyboards saves more in marginal (and perhaps per-unit) cost than the revenue from lost customers that require a physical keyboard.
All you're describing is an extension of the user preference - the willing to pay for their preference. Generally speaking if people aren't willing to make a sacrifice for the preference (in the form of money), how strong a preference is it?
After all I can get a physical keyboard on the $5 electronic address book. Even understanding that that's a very cheap keyboard (though that also includes margins for retailer, manufacturer and all the other costs), you're telling me that that the cost of a physical keyboard is going to be a deal breaker on a $300+ smartphone?
After all I can get a physical keyboard on the $5 electronic address book. Even understanding that that's a very cheap keyboard (though that also includes margins for retailer, manufacturer and all the other costs), you're telling me that that the cost of a physical keyboard is going to be a deal breaker on a $300+ smartphone?
The real cost of a physical keyboard (at least a built-in one) isn't the cost of the hardware. It's also the cost of having to have a different hardware unit for each country you want to sell in (and often not just the labels, but the physical layout as well.) That's a massive increase in the inventory risk you're taking, because your inventory has suddenly become less flexible.
> There have been plenty of Android phones with hard keyboards but they've not sold in sufficient quantities to make it attractive.
They haven't sold because they've sucked. They had low-quality displays, crappy software, slow SoCs, and barely enough memory to be usable. The only keyboard phone left is BlackBerry, and that's not selling, well, because it's a BlackBerry.
There is a huge market for regular keyboard cellular devices. It's just that nobody's made a half-decent phone along with the keyboard.
If there is a device with a physical keyboard, a tapered, curved design, high quality components, a top-notch display, excellent build quality, the latest versions of Android, and good marketing, and you have a winner on your hands.
It's just that idiotic OEMs like HTC and Samsung would rather follow the fruity status quo than break from the norm. Only BlackBerry seems to have any balls today. Shame they're practically dead in the consumer sector.
They haven't sold because they've sucked. They had low-quality displays, crappy software, slow SoCs, and barely enough memory to be usable. The only keyboard phone left is BlackBerry, and that's not selling, well, because it's a BlackBerry.
There is a huge market for regular keyboard cellular devices. It's just that nobody's made a half-decent phone along with the keyboard.
If there is a device with a physical keyboard, a tapered, curved design, high quality components, a top-notch display, excellent build quality, the latest versions of Android, and good marketing, and you have a winner on your hands.
It's just that idiotic OEMs like HTC and Samsung would rather follow the fruity status quo than break from the norm. Only BlackBerry seems to have any balls today. Shame they're practically dead in the consumer sector.
"idiotic OEMs like ... Samsung would rather follow the fruity status quo"
Samsung has been immensely profitable with their strategy of 'following the fruity status quo' and have a huge design department and produce dozens of phones and if they thought there was a huge market for a flagship keyboard phone they'd presumably be all over it.
If people want a physical keyboard for their phone there are plenty of case options, e.g.: http://typokeyboards.com/
Samsung has been immensely profitable with their strategy of 'following the fruity status quo' and have a huge design department and produce dozens of phones and if they thought there was a huge market for a flagship keyboard phone they'd presumably be all over it.
If people want a physical keyboard for their phone there are plenty of case options, e.g.: http://typokeyboards.com/
Funny enough, the best keyboard on an Android device that I ever used wasn't even an Android device. I had an HTC Touch Pro 2 (Windows Mobile 6.5) that could be cajoled into running Android, and typing on it was a _joyous_ experience. Sadly it finally died, and besides that it was getting to be ludicrously out of date.
Market realities are not really the substitute for thinking that you seem to think they are.
One of the issues with that is that devices on ARM systems are not as discoverable as a lot of other systems. You tend to need a kernel built for a particular processor variant, and it needs a device map of some sort for your specific device or it won't know how to find any of the stuff on the board and may just crash. Without this map you just can't boot.
Graphics are also very non-open at the moment, so it can be very hard to install other operating systems in a useful way for that reason.
In theory though, I agree entirely, that would be nice :)
Graphics are also very non-open at the moment, so it can be very hard to install other operating systems in a useful way for that reason.
In theory though, I agree entirely, that would be nice :)
Linux supports Device Tree mechanism which solves this issue. You would download a kernel for the correct processor and a .dts file that describes the phone's hardware.
Has this made it to mainline/release yet? I've been doing some ARM kernel support stuff for one of my devices, and DeviceTree isn't there even in 3.11.x (AFAICT)
Previously you had a bit of boilerplate code that did much the same. Either way it doesn't actually solve the issue, because you still need the dts file, there's no hardware discovery.
(ok that's a bit of a stretch, some of the busses and things like I2C are discoverable, but you need a map of GPIOs, UARTs etc etc)
Previously you had a bit of boilerplate code that did much the same. Either way it doesn't actually solve the issue, because you still need the dts file, there's no hardware discovery.
(ok that's a bit of a stretch, some of the busses and things like I2C are discoverable, but you need a map of GPIOs, UARTs etc etc)
http://www.linaro.org/linaro-blog/2011/08/15/enabling-device...
The Linaro kernels ("Linaro Stable Kernel" is the keyphrase) boot from devicetrees (aka FDTs). Not sure how much of that is upstreamed, but devicetrees are pretty standard in the ARM world as far as I can tell. (Also, in general if you're doing Linux stuff on ARM, Linaro is the place to look for everything).
Edit: actually, that link isn't very relevant - I just lazily googled "linaro devicetree". But you should be able to find more info!
The Linaro kernels ("Linaro Stable Kernel" is the keyphrase) boot from devicetrees (aka FDTs). Not sure how much of that is upstreamed, but devicetrees are pretty standard in the ARM world as far as I can tell. (Also, in general if you're doing Linux stuff on ARM, Linaro is the place to look for everything).
Edit: actually, that link isn't very relevant - I just lazily googled "linaro devicetree". But you should be able to find more info!
I'm a debian kinda guy and have been playing with both debian and mainline kernels, and haven't come across it yet, it may be that the ARM maintainers keep it on a separate branch for now.
I'll investigate Linaro at some point, if that's more of a hotbed of ARM development.
I'll investigate Linaro at some point, if that's more of a hotbed of ARM development.
Here are the LWN articles on Device Tree from June/July. Not sure how things have changed:
https://lwn.net/Articles/560523/ https://lwn.net/Articles/561462/
https://lwn.net/Articles/560523/ https://lwn.net/Articles/561462/
I'm not sure how things have changed yet either, and I certainly think Device Tree is an important step forward from each and every board having its own (mostly identical) code in the kernel tree.
But you do still need the dts, so while it makes device support easier, it doesn't solve the problem of discoverable hardware and you still need board specs etc, either from the original manufacturer or reverse engineered.
But you do still need the dts, so while it makes device support easier, it doesn't solve the problem of discoverable hardware and you still need board specs etc, either from the original manufacturer or reverse engineered.
So the next step is convincing manufacturers to put the .dts at a predictable location on a small flash or EEPROM.
I wish you the best of luck in convincing MS to make it easier to install linux on their phones, and convincing embedded system builders to spend extra on hardware.
Either way, I was talking about what we have now, and even if we have device tree now it doesn't solve this problem without other pieces to the puzzle. And that's without even getting on to the mess of closed source graphics drivers that exist in the arm world.
Please don't think I'm trying to say we can't have a situation like the OP wants, I'm just trying to explain why we don't.
Either way, I was talking about what we have now, and even if we have device tree now it doesn't solve this problem without other pieces to the puzzle. And that's without even getting on to the mess of closed source graphics drivers that exist in the arm world.
Please don't think I'm trying to say we can't have a situation like the OP wants, I'm just trying to explain why we don't.
I thought Linaro was a consortium to do exactly that, minus the Microsoft part. As you say this doesn't help us now, but hopefully some day there will be a widespread ARM equivalent of the BIOS and UEFI. It will probably start (or has started?) with ARM servers.
Cool.
All the more reason for me to get up to speed with Linaro then, thanks for the heads up :)
All the more reason for me to get up to speed with Linaro then, thanks for the heads up :)
Because phones inherit from an old business model where they were subsidized by mobile network operators and thus manufactured and sold according to their needs, not to the users need.
This meant you'd have many restrictions and the user was constrained to a tightly-controlled environment that forbode anything the operator deemed unnecessary (and could even contain malware/spyware-like pre-loaded software).
That model gradually evolved into J2ME platforms (and the like), where developers (and sometime users) could make small customizations, until someone decided there was a huge market selling phones designed not for the operators but for their customers (i.e. Apple/Google).
They still built the product partly following the same mindset/model and provided VM-centric phones that still are not designed to give you ring-0 access from the get go and maximize the operator's & manufacturer control on your device, hoping to gain revenues from gated developer communities, reselling applications that are mostly yet another graphical layer on top of code that already exists natively on regular computers since a long time ago.
That model is gradually evolving (hopefully in the right direction) and operators are slowling realizing that they're not device vendors but merely ISPs, which means that the phones are to be sold to customers, centered around their needs and giving them the maximum control (letting them chose the OS and giving them ring0 access).
You still need to get rid of the protected baseband cpu, the SIM, the TEE, the protected bootloaders etc. and eventually might have the device that you speak about.
This meant you'd have many restrictions and the user was constrained to a tightly-controlled environment that forbode anything the operator deemed unnecessary (and could even contain malware/spyware-like pre-loaded software).
That model gradually evolved into J2ME platforms (and the like), where developers (and sometime users) could make small customizations, until someone decided there was a huge market selling phones designed not for the operators but for their customers (i.e. Apple/Google).
They still built the product partly following the same mindset/model and provided VM-centric phones that still are not designed to give you ring-0 access from the get go and maximize the operator's & manufacturer control on your device, hoping to gain revenues from gated developer communities, reselling applications that are mostly yet another graphical layer on top of code that already exists natively on regular computers since a long time ago.
That model is gradually evolving (hopefully in the right direction) and operators are slowling realizing that they're not device vendors but merely ISPs, which means that the phones are to be sold to customers, centered around their needs and giving them the maximum control (letting them chose the OS and giving them ring0 access).
You still need to get rid of the protected baseband cpu, the SIM, the TEE, the protected bootloaders etc. and eventually might have the device that you speak about.
phones inherit from an old business model where they were subsidized by mobile network operators
Only in the US.
Only in the US.
Because while the ARM processor is probably supported, most of the other sensors, camera, cell radios, etc have proprietary binary drivers that are not.
Just read the problems Replicant, the true FOSS android, has had getting all components to work correctly.
Just read the problems Replicant, the true FOSS android, has had getting all components to work correctly.
The touch keyboard lacks feedback but folds to zero size, which is its great advantage. And people are in practice getting along just fine with them, which is why the hardware keyboards have fallen by the wayside.
The main obstacle to boot-your-own-phone in the US is of course the carriers.
The main obstacle to boot-your-own-phone in the US is of course the carriers.
> The main obstacle to boot-your-own-phone in the US is of course the carriers.
Surely if it were profitably one of them would break ranks, right? I mean, we have intelligent businesspeople in telecoms at least occasionally?
Surely if it were profitably one of them would break ranks, right? I mean, we have intelligent businesspeople in telecoms at least occasionally?
It's very anti-profitable for them, because it removes their ability to suppress functionality of your phone in order to sell it back to you.
First rule of phone company: why market when you can monopoly?
First rule of phone company: why market when you can monopoly?
By this assumption, surely everything that can be invented already has, right?
Within telecom pricing strategy? Yes, given current technology.
One can go back in the lit to Bell Labs research in the 60s for all the pricing strategies. Jean Tirole fleshed most of it out with help by Jean Rochet.
Source: Economist, network industries are my object of research
One can go back in the lit to Bell Labs research in the 60s for all the pricing strategies. Jean Tirole fleshed most of it out with help by Jean Rochet.
Source: Economist, network industries are my object of research
Why not? I installed Ubuntu the other day, it was trivial. Plus, there's a multitude of custom ROMs.
Yeah, but what you would call trivial might be insurmountable for lots of people. Cyanogenmod already has a lot of the privacy features missing in Android, but dicking around with clockworkmod recovery, etc. is pretty daunting.
Cyanogenmod now provides a really easy installer that takes care of everything (including unlocking of the bootloader). I used it with my Nexus S last week without any hassles.
Swapping the OS on a desktop computer has never been particularly accessible to most people, either. What percentage of desktops ever get a different OS from what they came with? I'd guess less than 3% if you don't include upgrades from one version of Windows to another.
Fair point.
I think not tying the OS to their hardware was a mistake by IBM. And while it may have let the PC win, what is the point of your platform winning if you get forced out of the business by the clones? There is no money in hardware, you need to control the OS.
> I really miss when computers were devices you could buy and then put your choice of OS on.
uh, those are still around you know. You can even carry them in a backpack.
uh, those are still around you know. You can even carry them in a backpack.
[deleted]
I don't understand this from the EFF first they post a piece lauding an unofficial, deeply buried unannounced functionality, then they condemn Google for removing something that they have never officially released or supported in the first place.
It’s their mistake for jumping the gun and discussing something that wasn't officially, the followup is just to save face, but that is really an unfair attack.
It’s their mistake for jumping the gun and discussing something that wasn't officially, the followup is just to save face, but that is really an unfair attack.
How would anyone know it was not official until Google said it wasn't meant to be released?
What sort of official feature is hidden and can't be accessed via any user interface provided by the vendor?
What sort of "we never meant to release this" feature would get merged into stable tree and even get into the production builds that get shipped on the actual retail hardware?
I thought if feature's meant to be solely experimental it'd just sit in a separate feature branch.
I thought if feature's meant to be solely experimental it'd just sit in a separate feature branch.
I hope this feature will get added again in a future version.
It was not an official feature in KitKat and somewhat breaks the current API, where developers didn't have to check for permissions at runtime.
Android 5.0 maybe?
It was not an official feature in KitKat and somewhat breaks the current API, where developers didn't have to check for permissions at runtime.
Android 5.0 maybe?
They still need to split the permissions more. READ_PHONE_STATE is nasty.
Apps ask for the permission because they (for instance) need to pause playback on a video because you have an incoming call. But it covers all the phone details (numbers, IMEI etc) and who the call is coming from and a hell of a lot of other stuff.
Who the hell thought that was a good idea?
Apps ask for the permission because they (for instance) need to pause playback on a video because you have an incoming call. But it covers all the phone details (numbers, IMEI etc) and who the call is coming from and a hell of a lot of other stuff.
Who the hell thought that was a good idea?
Yep. I have gotten one-star reviews on an app of mine because they think I want to invade users' privacy, when I really just want to pause media when a call comes in.
READ_PHONE_STATE means I have to decide whether I want a handful of one-star reviews for requesting that permission, or a truckload of one-star reviews for the app playing media over their calls.
READ_PHONE_STATE means I have to decide whether I want a handful of one-star reviews for requesting that permission, or a truckload of one-star reviews for the app playing media over their calls.
Have you considered listing the reasoning behind your permissions in your app description?
I'm surprised at the EFF. this post seems intended to save face for them rather than anything else.
They had a post recently lauding App Ops although it was never officially released, announced nor documented. And it certainly was not accessible to the average user.
Also it was obviously not compatible with most apps, as they didn’t fail too gracefully. Again: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only
http://www.androidpolice.com/2013/12/11/googler-app-ops-was-...
I do hope Google is working on something similar on an OS level for future releases, but this hack job by the EFF is disappointing and unnecessary.
They had a post recently lauding App Ops although it was never officially released, announced nor documented. And it certainly was not accessible to the average user.
Also it was obviously not compatible with most apps, as they didn’t fail too gracefully. Again: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only
http://www.androidpolice.com/2013/12/11/googler-app-ops-was-...
I do hope Google is working on something similar on an OS level for future releases, but this hack job by the EFF is disappointing and unnecessary.
I would guess this is because cancelling the internet permission can be used to block ads. Ads that generate money for Google.
If they put it back with next release, it was accidental.
If not, not.
If not, not.
They're claiming the release was accidental. Not the removal.
This is very disappointing. I had hoped the release of App Ops as a hidden feature indicated that permissions would be user-revocable in a future release.
It isn't a burden to handle security exceptions.
It isn't a burden to handle security exceptions.
Jolla and/or Myriad could make some hay by adding a similar feature to the Android compatibility runtime used in Sailfish.
This is a major issue Google needs to deal with in Android IMO. I'm surprised that this feature ever existed in Android because of how coupled permissions are with applications. Since applications request all permissions on install I imagine most developers don't have much conditional code for their failure, unlike iOS where you have to because there's a possibility a user may deny access to a single specific thing, like location data. I'd really prefer to see Android go more towards that. When you look at the permissions an application like Facebook requests on install it's just insane.
That's partially because developers are somewhat incentivized to "front-load" their permissions. If you think there's even a chance you might use a permission, even if your app doesn't currently use it, ask for it on the first install.
Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.
Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.
This doesn't sound right to me. I don't think developers are doing this.
I've done this. Not for sneaky/malicious purposes but just to provide a better experience. Also batching features around adding permissions, I'd rather release one update with two new permissions than two different updates each requesting a new permission.
Nova Launcher has had the "Set Wallpaper" permission from the start, most launchers have it and use it, but Nova didn't actually needed it initially as the set wallpaper functionality was just calling other apps that held the permission themselves. But I knew Nova would at some point require it (and indeed it does now) and users completely expect the launcher to be able to set the wallpaper, but users still get confused or annoyed by the new permission screen.
"Google Play License Check" is another permission I've requested but not used. It's a reasonable permission for a paid app to have and not one that users email me asking about, but when I first added it to WidgetLocker I did get users asking about new permissions (The "Android Market" at that time didn't specifically point out which permissions were new, so people would just ask about any permission they didn't realize the app had all along). In a future update I ended up disabling license checking because it was proving to be more trouble than it was worth, but I didn't remove the permission because if I ever wanted to turn it back on I didn't want users to be prompted about the permission again.
Requesting something like Read Contacts without actually using it would probably upset users, as some will ask about those kinds of permissions and expect a reasonable answer. Saying it's just for future use would seem a bit suspicious.
Nova Launcher has had the "Set Wallpaper" permission from the start, most launchers have it and use it, but Nova didn't actually needed it initially as the set wallpaper functionality was just calling other apps that held the permission themselves. But I knew Nova would at some point require it (and indeed it does now) and users completely expect the launcher to be able to set the wallpaper, but users still get confused or annoyed by the new permission screen.
"Google Play License Check" is another permission I've requested but not used. It's a reasonable permission for a paid app to have and not one that users email me asking about, but when I first added it to WidgetLocker I did get users asking about new permissions (The "Android Market" at that time didn't specifically point out which permissions were new, so people would just ask about any permission they didn't realize the app had all along). In a future update I ended up disabling license checking because it was proving to be more trouble than it was worth, but I didn't remove the permission because if I ever wanted to turn it back on I didn't want users to be prompted about the permission again.
Requesting something like Read Contacts without actually using it would probably upset users, as some will ask about those kinds of permissions and expect a reasonable answer. Saying it's just for future use would seem a bit suspicious.
I don't think developers should do it, but there's no question that they're doing it.
For example, Facebook requests almost every permission under the sun. But if you look at the average user's permission profile for their Facebook app, they'll only show a tiny fraction of the overall permissions that Facebook originally requested.
For example, Facebook requests almost every permission under the sun. But if you look at the average user's permission profile for their Facebook app, they'll only show a tiny fraction of the overall permissions that Facebook originally requested.
And that's the really scary part. Is that so many applications do this for just unreasonable permissions. Then you get one of the bad applications that's actually using that data for something nefarious and it destroys trust in the process. For me at least.
I definitely get that. With automatic updates I bet that a lot of applications sit in that update queue on people's devices since they actually have to confirm the new permissions.
There is another point here, one I think even more important and more disconcerting.
Google released an entire feature of their Android OS BY ACCIDENT. W...T...F?! How do you release a feature "by accident?" By having awful quality control? How does that make me feel about the rest of their Android OS now?
Either this, or they're lying through their teeth in an effort to cover up. In either case, it's evil.
Google released an entire feature of their Android OS BY ACCIDENT. W...T...F?! How do you release a feature "by accident?" By having awful quality control? How does that make me feel about the rest of their Android OS now?
Either this, or they're lying through their teeth in an effort to cover up. In either case, it's evil.
From the comments, it sounds like the preference pane was hidden and had to be enabled by installing 3rd party software. Having experimental features in software that are hidden (but included for testing in limited situations) is not surprising, nor WTF worthy.
This is exactly the case. Someone noticed it somehow (source / activities dump, I forget) and figured out how to launch it. And last I saw it wasn't actually removed, it just had stronger permissions on what was allowed to launch it, which broke all existing launchers. There may or may not be a new way to launch it.
Meanwhile, the source code keeps moving more and more towards having a real runtime-permissions-manager. Honestly I think they'll have something soon, but probably not before 4.5 or 5.0. In the meantime, I've been loving XPrivacy, it's probably more granular than anything they would release anyway (and I've had exceedingly few crashes, blocked data is faked not broken).
Meanwhile, the source code keeps moving more and more towards having a real runtime-permissions-manager. Honestly I think they'll have something soon, but probably not before 4.5 or 5.0. In the meantime, I've been loving XPrivacy, it's probably more granular than anything they would release anyway (and I've had exceedingly few crashes, blocked data is faked not broken).
Hanlon's Razor probably applies here. http://en.wikipedia.org/wiki/Hanlon's_razor
Stupidity and malice are frequently indistinguishable by an outside observer.
Hmmmmmmm, perhaps, but I'd suggest that:
Stupidity is negligence. Negligence is selfish. That makes it malicious. Its willful which ever way one chose to spin it.
IMHO, such phrases are not much different to ones like "what do you have to hide?". They are designed to look like one thing, confuse and win a point, while hiding the fact that something appalling is going on. Its the language of confusion to control.
Its too easy to be allowed to hide behind a false concept of stupidity. Too convenient.
Stupidity is negligence. Negligence is selfish. That makes it malicious. Its willful which ever way one chose to spin it.
IMHO, such phrases are not much different to ones like "what do you have to hide?". They are designed to look like one thing, confuse and win a point, while hiding the fact that something appalling is going on. Its the language of confusion to control.
Its too easy to be allowed to hide behind a false concept of stupidity. Too convenient.
Stupidity is negligence.
False, in general. If you want to assert someone is using stupidity as a cover, you need evidence. I don't believe that should be the default hypothesis.
False, in general. If you want to assert someone is using stupidity as a cover, you need evidence. I don't believe that should be the default hypothesis.
No, EFF is simply wrong. The feature was never released, and instead of posting a "we screwed up" retraction EFF is now trying to shift blame.
If you put software into the wild - you have released it. Just because the cycle has sped up, you didn't document it properly, and your QA failed, does not mean you didn't release it.
I'm not taking sides here, but you have to call a spade a spade.
I'm not taking sides here, but you have to call a spade a spade.
> If you put software into the wild - you have released it.
Even by that definition Google never released it. You needed a 3rd party app to access the feature, Google's software alone was not enough. Google didn't fail here, they flat out never released it.
Or perhaps you could argue that they failed by not releasing it (or something similar), but that's different story.
Even by that definition Google never released it. You needed a 3rd party app to access the feature, Google's software alone was not enough. Google didn't fail here, they flat out never released it.
Or perhaps you could argue that they failed by not releasing it (or something similar), but that's different story.
I would not argue your 2nd point. I did not read that you needed a third party utility to access this.
So they released an unsupported publicly accessible API?
Arguably true, but if you rely on a hidden, undocumented feature and it changes or goes away and you don't like it, I'm not sure you have any right to complain since its volatile nature was quite clear from the start.
But with no clear user-facing way to activate it, meaning you have to use some unofficial app that accesses it in an undocumented manner, it has the smell of something that you could not rely upon as a "feature."
If it's there and it works, then great for you, but you can't expect a whole lot more. It sucks that they didn't actually make it a published feature with an actual means of accessing it, and take on the responsibility of maintaining it, because it seems like something I'd like to use.
If it's there and it works, then great for you, but you can't expect a whole lot more. It sucks that they didn't actually make it a published feature with an actual means of accessing it, and take on the responsibility of maintaining it, because it seems like something I'd like to use.
It's more like they left an undocumented feature accessible.
However something like this needs to be integrated tightly like iOS and apps need to be aware they may not receive requested permissions. I still use App Ops in Kit Kat and it silently breaks apps all the time. Apps expect to be able request information (e.g. contact details) and crash or stall when they can't.
In that respect, LBE Privacy Guard[2] was a much better alternative up to ICS. It was a privacy firewall that would pop up notifications when protected permissions were being used for the first time. Instead of blocking apps when denied, Privacy Guard would feed it blank data instead. This lead to a better UX and stopped blocked apps crashing.
There needs to be an open source version of LBE Privacy Guard since the current one hasn't been updated over a year and is closed source from a Chinese company.
[0]: https://play.google.com/store/apps/details?id=com.colortiger...
[1]: https://play.google.com/store/apps/details?id=biz.bokhorst.x...
[2]: DO NOT INSTALL, FORCES REBOOT LOOP
https://play.google.com/store/apps/details?id=com.lbe.securi...