For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service).
The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work.
But on the play store it's written "read phone status and identity" and that's really really scary for the users.
And even if we're 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...
> For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call.
It's seriously back-asswards that you'd have to have access to all phone state just to be able to start and stop audio on phone calls.
By comparison iOS has an audio interruption system which gets triggered on phone calls, alarms (calendar and clock) and other applications taking over the audio, the application getting interrupted neither not knows nor cares where the interruption comes from, only that it doesn't have the audio stream anymore.
Curiously, it looks like Google's AOSP music app requests READ_PHONE_STATE but unless I'm missing something they don't use it - relying entirely on focus loss instead. Granted, I'm not sure anything actually uses this code now...
Which doesn't really help the users stuck on Android versions that never get any update or bugfixes. In which case apps have to take the pragmatic route and just work around the issue. Even if that requires a scary permission.
No user would point to Google and say »VLC doesn't pause when the phone rings, fix the ringer, please.«. Rather they point to VLC and say »VLC doesn't pause when the phone rings, fix VLC please.«
Split your APK based on SDK version. Have different manifests with different permissions & code for the respective versions. The new Gradle toolchain makes all of that easy to do, but it is tough to maintain lots of version specific code long term.
It almost seems like they do it intentionally to improve tracking and desensitize users. Only a terrible engineer would think needing to know if the phone is ringing needs a permission, let alone one that provides unique IDs plus the phone numbers on phone calls.
It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and history. They use dark UI patterns to trick people into activating stuff.)
Adding to that: In Android Lollipop, One can't edit / delete local (phone-stored) contacts. They have to be synced to cloud in order to edit / delete them. If this is intentional, it is a sick dark UI pattern.
On one hand it's backwards from the user experience POV. On the other hand it garantees consistency and resolves most of the weird edge cases of contacts syncing.
I think the common wisdom would be to put the burden on the engineers to find a solution that somewhat handles all the quircks. Personally I've had so many sync failure and weird behaviors from all the services tried until now that I would settle for a more reliable system, even it had severe usability limitations.
I envy organizations that can omit "obvious" features when they don't have a good enough solution to satisfy all the edge cases.
It wouldn't matter if contacts were encrypted client-side, but Google seen to have a severe allergy to client-side encryption. Mozilla are really leading the way on this issue.
What I think is particularly sad is that Google could still make a huge amount of money without exposing one's private information directly.
Full-device encryption does nothing when data are transmitted off-device.
E.g., as long as my photos stay on my phone, they are encrypted, but if I back them up to Google+ then Google may read them.
Which is really pretty crazy: Google don't need to read those photos (or my contacts, or my documents); my computers need to, and the computers of those I share the photos with need to.
I could encrypt each photo with a unique key, and encrypt that key with my own private symmetric key, as well as my friends' public asymmetric keys, and then both they and I could view the photos at any time (our devices knowing how to access the keys we have authorised for them), but Google would not.
It should need a permission in my opinion. Why should a calculator (for example) know if there is incoming call?
But this case should be handled by a permission in dialer (or whatever handles incoming calls) - something like "allow to broadcast mute to all other applications".
> Why should a calculator (for example) know if there is incoming call?
Because it's running on a phone.
Remember those cool requestAnimationFrame side-channel timing attacks. I think it'd be pretty hard to hide at least certain things like these from an app if it really wanted to know. In this case I think it's pretty fair to just give it an API call for it.
Why shouldn't it? It's on a phone; it's part of basic usability. And the cure in Google's case is far, far worse. Give them access to your IMEI and phone numbers in and out. I know assume incompetence over maliciousness, but this stretches belief. Especially combined with the rest of Google's little tricks.
> I know assume incompetence over maliciousness, but this stretches belief.
It's worse than that. Android had a saner permission interface, with a separated permission just for detecting if the phone is ringing. Google "updated" it to the current format alledging the previous one was too confusing.
I also have an audio app with a background audio service on Google Play, and I also have to request the READ_PHONE_STATE permission. I have an explanation in my store listing but I still get emails about it every week.
It's totally nuts. Knowing the phone is ringing or off the hook should not be privileged information.
What makes a privacy concern legitimate, to your mind? It's giving data about a person to a group that otherwise would not have had access to it. It seems first order a privacy concern.
There's also some possibility it could be turned into more sensitive data - if my app tends to be recommended around social circles, and I see two people were on the phone over the same period of time, it's likely they were talking.
And if a service can reach out to the Internet, it knows my IP can tell where I am. And if it suddenly cuts out after being on a known IP, then maybe I'm going through a local tunnel.
That's what I meant by you have to get really creative to think how this could possibly be impacting. If you have a sandbox, you have to choose which permissions you're going to ask for carefully, to avoid overloading users.
Android made a bad decision by making phone apps needing permission to know if the phone is active, then compounded that by tying it into device ID and who you're calling.
"The privacy concerns are not significant enough to merit demanding permissions" is certainly a defensible position; I'm not sure whether I agree with it, but it's not crazy.
That is distinct, though, from "there is no privacy concern."
I've been working on a streaming music player for Android lately. After doing some basic testing on one device, onAudioFocusChange seems to be all I need to duck and pause/resume for incoming calls, but I'd like to make sure I handle all the corner cases correctly.
It would be bad either way. Now you have strong permission, otherwise you'd have hundreds of them.
What could help are groups in which you could select only certain items, but it would be presented to users as a group. But they would be able to open the group and see each individual item.
And of course, the biggest issue is that users can't manage (restrict) the permissions themselves (without a superuser app at least).
I don't think it would be bad to have more granularity. Being able to detect when a call is coming in, in order to mute, is entirely different from being able to read phone identity (IMEI etc), incoming phone numbers etc etc.
It may not need hundreds more permissions, it may even only need one more as this one seems to be a very common problem.
The same people that would prefer if you give all permissions. I still see no reason why Google doesn't implement more granular permissions models.
Has the latest Android given you the ability to restrict an apps permissions after install without resorting to trusting 3rd party tools like xPrivacy or uninstalling the app?
The existing permissions are already so fine grained it's insane. Almost every API has its own permission, regardless of whether that would be understandable to normal users or not.
The Android security model does a great job of security. It was not designed to be a general purpose privacy guard that lets you engage in some complicated multi-way negotiation with every app you install over every aspect of your personal data. Such a system might be a feature of future operating systems, but currently I'm unaware of any such OS.
They clearly aren't so fine-grained as all that, not in this area, because they still have a single permission that covers not only knowing when a call is in progress, but also phone identifiers like IMEI, the incoming phone number and a load of other stuff.
The future is here, it's called iOS. Blackberry does a decent job too.
In fact, companies that don't do ads & tracking seem to have this in common. Not sure what the sit with MS is, they used to have something like the Android model.
> The same people that would prefer if you give all permissions. I still see no reason why Google doesn't implement more granular permissions models.
In fact they have gone the other way with "permission groups"
> Has the latest Android given you the ability to restrict an apps permissions after install without resorting to trusting 3rd party tools like xPrivacy or uninstalling the app?
The hidden "AppOps" (post-install management of permissions) appeared in 4.3 but was removed in 4.4.2, so no.
> In fact they have gone the other way with "permission groups"
It's interesting that they went forward and then back on this. Ages ago the permission "read contacts and call log" was split up into two separate permissions. These days the Play Store displays either permission the same way - something like "read contacts or call log".
Google will never do that themselves, because it interferes with their own datamining business. XPrivacy will always be required to control your own data.
This has always baffled me, especially when phones doing their phone mission worse and worse over time. What I would really like is that all non-system applications would be pushed to hold pattern, similar as if application is not visible, except it would be applied to background services as well, so that all resources would be available to calling application. Maybe that would solve the lag I experience with every android phone when someone calls me and I try to pickup.
I installed Pocket. It wanted permission Contacts and Calendar.
Contacts, I understand for sharing purposes. Calendar? Yeah, fuck off.
Maybe they are bundled together like "read phone status and identity" and Pocket has no way around it. Maybe it is not.
As a user, I should not have to worry about that.
Contact and Calendar in no way should be bundled together.
VLC isn't available on iOS anymore. At least not in Apple AppStore in Europe :/
Rumors say Apple removed/hide VLC. Though Apple hasn't removed all the shady gray-zone VLC closed source forks that float around in AppStore with questionable Ads and micropayments. The original VLC is still there for Jailbreak users: http://www.videolan.org/vlc/download-ios.html
You're correct that they are indeed separate permissions but I think when Google started putting them in buckets for displaying to the user they lumped the two together.
For instance on one address book app the website currently shows them asking for:
Contacts/Calendar
-read your contacts
-modify your contacts
While the app on my phone says:
Contacts
-read your contacts
-modify your contacts
Sometimes, I've seen apps on the play store with a section explaining what each permission request is for with details of what it uses and why. Did you consider adding a section like that for VLC?
I think if all such problems are reported to Google (bugs filed), they might fix these in the next versions of the APIs (i.e., making permissions more fine-grained and less inclusive)
If you can request permission to read the list of activities and do so when your activity is paused, you can search for the phone application (or even similar ones, such as Skype) and pause your audio playback?
You don't have to be an activity at all, your service can do that. But the comment where someone might just be browsing their contact list makes sense too.
> If your app is closed-source then they have no way of verifying you're not downloading all their contacts to their servers.
That's a common fallacy. Even if it is open source someone could still be doing that. In order to be secure you would have to:
A) Download the source yourself
B) Inspect the source
C) Compile the source
Just because you have the source doesn't mean what you get from the Play Store/Amazon App store is 1:1 identical or even similar.
There is secret option D, have someone you trust do A through C and then give you the hash of the resulting compiled file. But two programs compiled on two machines often give different results due to library versions, compiler versions, environmental settings, and so on.
I'm an F-Droid developer, and we do in fact do secret option D.
There is a small but passionate group of people who are very focused on deterministic builds in Android working with us as well [0]. The end goal is to be able to install fdroidserver, then run:
fdroid verify
And it will do all of this for you (download source, compile source, verify binary against another binary).
Of course, option B) is always a problem, but I guess the best solution short of paying to audit every single open source app is to fall back to the many eyes theory and hope it holds us in good stead.
EDIT: For those interested, one of the reasons we are interested in deterministic builds is so that we can verify that our build of the source corresponds to the upstream build. If that is the case, then we will be confident distributing the upstream binary (i.e. signed by the upstream developer). It is not possible to install a .apk from upstream, and then update it with a version signed by F-Droid - for very good and legitimate reasons. Distributing builds signed by upstream alleviates this problem.
> Unless you build you computer yourself from silicon
And the chip design, and the fab control software, and the tools that make the tools that make the tools.
And descrete components won't help you because transistors are large enough to conceal a mircocontroler emulating a transistor and listening for high-frequency handshake signals.
Relays are probably safe since you can make those yourself out of iron and copper (rods, springs and wire), and conveniently those are the same things you need to build motors!
There is a simple antidote to this problem, as long as you have 1) the source code to the compiler you suspect of being bad, and 2) a second compiler (binary only), written by someone who is not friends with the first one. For instance, if you want to verify that gcc is not evil, you need the gcc source, and MS Visual C++. The basic idea is summarized by Bruce Schnier here:
https://www.schneier.com/blog/archives/2006/01/countering_tr...
Except that it is possible to have lots of someones reliably do A through C with a defined environment and get the exact same output every time they compile it. It's referred to as 'deterministic' builds. Bitcoin and Tor are doing it, for example.
Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
> Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
If you wish to imply the issue is due to my lack of understanding then go right ahead, but at least first explain why what I said is wrong.
A lot of people get their apps from the app stores on Android/iOS/etc. App stores do not provide the raw source and let you compile it last time I checked. So in order for OSS to provide a security advantage over closed source you'd have to sideload your apps after doing the inspection and compilation stages yourself (or having a trusted third party do it).
People throw the "open source so secure" justification around all the time, it is rarely justified. Really you aren't trusting OSS, you're trusting third parties who inspect the code on your behalf (e.g. distro' vendors in the Linux world). In the app world there are no third parties doing the verification step for you, unless you count Apple.
As a general rule, you're trusting both the publisher and 3rd parties that can verify the code makes the build.
An app store can easily provide a binary that can be verified by 3rd parties. Again, it's more about others being able to verify it rather than you being able to build it yourself. And the publisher can provide the source via another means to all interested parties.
App stores aren't the best example since it's mostly closed source games and social apps... think Candy Crush and Facebook. On Android, I run many apps that have the full source code available like Firefox and KeePass. Quite a few public eyes are on apps like Firefox, including on the build system. Most real work and real apps run on desktops and laptops where you don't even have the limitations of the app store to worry about (though you do moreso with each build of Mac OS X).
Saying 'both types of publishers can lie!' is a bit of a false equivalency. On the open source side, you have deterministic builds. And, even without verification, open source is a big advantage over closed source. Others can look through the code to see how it works. Verify that security elements are properly implemented. Submit fixes to such elements. Even see how it works in code to ensure you have more complete testing of the provided binary and have an easier time knowing if something that wasn't in the code was added, since the binary is doing something it shouldn't be based on what the code says. You get no such benefits from closed source code.
And if you can't make head or tails of it, you may conclude "good, it seems encrypted. Unfortunately, that means I cannot tell what they send to their server".
I assume you'd set up a custom CA on your proxy so you can spy on the https traffic. I'd be suspicious if I saw large blogs of data that had been encrypted in the application instead of at the network layer.
But then best practices say you should be doing cert pinning. That will block your CA.
Although for most apps modifying that check to look for another cert is probably not too hard. (But of course if the app is obfuscated and does integrity checks on itself, it can get arbitrarily complicated.)
I visit sites with cert pinning at $EMPLOYER. $EMPLOYER runs a very expensive solution from Blue Coat which includes a MITM CA - no issues intercepting anything here. Amusingly, this meant the proxy itself was vulnerable to Heartblead while the client machines were not.
The only foolproof way to get around this is to hardcode the certificate into the application itself, or at least the intermediate chain. Otherwise, you could have always intercepted the first request and made that the certificate of record.
Anyone could use a network sniffer to see it is uploading something, but you can't tell what since the content may be encrypted. Advanced user may be able to follow the data in a debugger, but that's a lot of work. Very advanced user could instrument the code to perform data flow analysis, see https://www.cs.cmu.edu/~wklieber/papers/soap2014-didfail.pdf
You can relatively easily MITM most applications by uploading a custom root certificate to your phone, and doing SSL termination + re-establishment on a router your phone is using.
The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler yourself. At the end of the day you will have to trust some bootstrapping binary compiler unless you put it together yourself in machine language.
Schneier's summary of Wheeler's method says: "This countermeasure will only fail if both [compilers] are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first. You can greatly increase the odds that the triggers/payloads are not identical by increasing diversity: using a compiler from a different era, on a different platform, without a common heritage, transforming the code, etc."
Good point. Given sufficient paranoia this train of suspicion can be continued even deeper down the rabbit hole: you'd need to inspect the hardware designs and make sure the hardware you've got was actually produced according to the inspected designs.
In technology as elsewhere, it seems life is ultimately based on trust in someone.
Trust is a function of the expected incentives of the trusted.
One way to manage their incentives is by exercising control, but there are other more friendly ways, too. For example, shared goals, community, reputation, financial rewards, reciprocity and ethics standards all provide weaker or stronger reasons to trust others.
In practice you can disassemble Java apps to pseudo source code anyway. I've done it several times to APKs to see what is going on under the covers. Deliberate obfuscation would be immediately suspicious.
I wouldn't say that. Obfuscation isn't that rare in Android. Proguard offers tree shaking and optimization features that are useful in mobile. Some frameworks even require it. AFAIK most set ups for scala on android need proguard because the standard lib is so big.
1. How closely would you have to look to notice something like a weak crypto setup or other “accidental” change less obvious than sending everything to “all-your-bytes.nsa.gov”?
2. How many people other than blackhats actually have the time to do this for every single automatic update?
I tried understanding the APIs several phone apps are using, (the apps are heavily obfuscated), so I decompiled them and hacked my own small deobfuscater where I could rename stuff half-automatically.
Then I went through the code of Google Apps with this, and it’s actually really nice. Although kinda surprising how many Google Apps have hardcoded API keys for their services floating around, for example there is one Google App which has a hardcoded key that allows full unthrottled API access to all of the Google Maps APIs. For free.
I just did this out of fun, as I’m mostly working on Android OpenSource apps, but it was quite easy and interesting to see how Google obfuscates their apps.
Finding predictable things like hard-coded strings is a significantly easier task than proving that none of the code is doing something sneaky. It's much easier to look for something like an access key than confirm that the numeric constants being passed to a crypto function are the correct ones or that it's not leaking something which would make it much easier to crack.
This is encryption and obfuscation on multiple levels, classes passing each others state through hashing and encryption schemes on multiple levels, added bytecode hackery, etc.
Exactly my point – it's unreasonable to expect that higher level of reverse engineering will be done reliably for every release of even a small percentage of the apps being published.
That assumes that Apple fulfills the role of "someone you trust do A through C." Even if you trust Apple's intentions, they don't do a very good job of checking apps for actual damaging stuff (as opposed to irrelevant crap that offends their sensibilities), so it's not helpful.
> Case in point: android.permission.CALL_PHONE. You need it to initiate phone calls from your app, right?
This kind of thing is why I can't see myself switching to Android as my primary mobile OS any time soon. If anything, I can see a bright future for Microsoft. In spite of the fact Windows Phone exists, Android is very much the Windows of the mobile ecosystem.
Permissions on Android are horrendous for developers. But they are even worse for users. If a developer can't tell the difference between ACTION_CALL and ACTION_DIAL, what chance does the average end-user have?
And when every app requests at least half a dozen permissions, how many users are going to carefully review each and every permission and how many are just going to give up and grant all requested permissions to every app the way that everyone reflexively clicks "agree" to every online ToS? Even if Android actually had a working method to deny individuals permissions, nobody ever has any idea which permissions are essential to which classes of app and which should be treated with suspicion.
Compare this to iOS, where you may occasionally get asked to grant an app access to contacts or location - this is a rare occurrence and you can choose deny every time with no negative consequences (except for restricting that functionality).
The comment by jbk illustrates just how big a mess permissions on Android are, beyond just being confusing. On top of that you've got custom intents, which while a great idea on paper, just pile more complexity on top of a broken foundation of complexity and obfuscation.
This IMO is the single biggest thing wrong with Android, which Google should prioritise fixing like Microsoft in 2002. Never mind signed-app stores like Play: the fundamentally broken security model is the reason why Android is the only mobile platform to have a problem with malware. It's also a brilliant case study in over-engineering with a complete failure to consider human psychology.
Could be the fact that Microsoft updates their iOS and Android apps before the same app on Windows Phone. I've seen that complaint from some of the WP community.
>And when every app requests at least half a dozen permissions
I think this is the core problem here. The "list of permissions" system doesn't make sense to anyone and just seems like some project manager following a list of checkboxes from a list of security practices.
I recently stopped using my Nexus 10 due to getting an iPad3 for a steal. I love being asked if an application can use my location, as opposed to having god knows how many apps on my N10 silently sampling my position. I love knowing that the entire OS isn't dedicated to better selling ads for app publishers. Apple, for all its faults, isn't in bed with the ad industry like Google is.
I really was hoping features like this would come to Lollipop, but apparantly this isn't a priority for Google. Instead we get a byzantine line of permissions no one understands and we all say "Yes" because we want the app. There's no alternative. If the Amazon Kindle app has a permission I must accept it to read my books. I can't just say "No" to location awareness or contact list reading.
I' an Android (Cyanogenmod) user and agree with your point, this could--and should--be done a lot better.
I am not familiar with iOS and iPhones at all. You state iOS apps only rarely need to be granted permissions, how do they make that work? I can see only three ways that could happen:
Either the app can do most things without asking permissions (bad for the user--there'd be malware). Or the app simply can't ask for permission to do a lot of things (bad for the developer, and ultimately the user--because less functionality). Or it's a combination of the first combined with the iOS App Store's walled-garden quality check approach (bad for everybody, and the biggest reason I got an Android instead of iOS device).
I could be wrong but I'm guessing it's the third option?
I'm going to try to be objective here, crazy how I can just feel that seed of fanboiism in my head, let me just leave it at me being idealistically opposed to the walled garden approach for reasons that have been rehashed on HN for ages now :)
That said, there's also a few practical things the iOS walled-garden App Store could improve upon. First one being the $99 developer fee. I teach kids computerstuff and one time a particularly clever 11-year old needed some help setting up Eclipse, I didn't have a smartphone myself back then, I wasn't sure what he was trying to do, so I just helped him navigate the English menus, install the proper Java things and let him at it. Sure enough, an hour later he proudly showed me his Android phone. "Hello World", it said.
Another thing, this iOS App Store review process, it's done by humans yes? Does it scale? From what I've heard, even though I mostly heard it in the form of complaints, you get rejected by actual humans, yes? That's obviously never going to happen to Google's Play Store. But then again, the Google Play Store isn't quite as deeply engrained into Android as the iOS App Store, you don't need to use it, you can even completely step out of Google's ecosystem and still use Android (though it's hard, a bit like using Linux 15 years ago). Does the iOS App Store also use scanners and automated tests for new applications? I bet they do, do we know what kinds? Like it could test for certain kinds of API calls so the human reviewers know what sort of thing to look for.
One funny thing is, I used to have to explain people what "repositories" are in Linux, what they do, what they're used for and why they're so much cooler than (Windows) having to download .exe installers from all sorts of websites to get your software. Nowadays I can just tell people "it's pretty much like an app store", and they know all they need to know. That Ubuntu Software Centre even looks like an app store, with all the stars and ratings (blegh).
However, the repositories in Linux, are not quite like either the Google Play Store or iOS App Store. They obviously do not have the walled-garden approach, it's entirely open. Linux software from the repositories doesn't need to ask for permission for anything (except sudo). Still, there is no malware in the repositories, at all. I admit I am a little bit vague on how this works too, perhaps I'm missing something obvious, but how do they do that?
> I could be wrong but I'm guessing it's the third option?
Nah, it's a combination of two things:
1. Applications are granted internet access by default. It's possible to disable cellular access on a per-application basis, but not networking in general
2. Permissions are asked for at point of use with a big allow/deny dialog. This has several consequences
* it's easier for the user to understand why the application would want to e.g. access their contacts
* the user only gets the dialog if they're accessing a feature which claims a need for it, no paying a privacy/permission cost for stuff you don't do
* the more stuff an application wants access to the more scary dialogs they'll prompt, so application developers have tended to not go overboard
Also all permissions can be revoked (or granted) afterwards, aside from cellular they all live in Settings > Privacy, and inside each permission is the list of applications which asked for it, and whether they're allowed or denied access
Thanks, that makes sense. Better option than what Android does too, IMO.
Especially if the permissions are also more granular than they are on Android. Otherwise I could imagine an evil app prompting a type of permission in the context of something completely innocuous and reasonable (say, to pre-fill contact data to some input field), only to use that very same permission immediately afterwards for something evil (sending all contacts data to their servers).
The app starts out completely sandboxed. No access to any hardware other than speakers and display (and even then, iOS has a layer on top of your canvas for the status bar and system dialogs). No access to the hard disk other than the app's local files. Instead of asking for permissions on app install, the app asks for permissions as you try to use them.
For example if you installed Instagram, you could scroll through the news feed fine but if you wanted to take a picture it would ask you to access the camera as soon as you try to. If you tried to take a video, it'd ask for permission to use the mic. Similarly it would ask for access to your photos as soon as you try to select a picture to upload from your camera roll. If you try import your contacts to find people to follow, it would ask for permission to read your contacts list. If you try to tag your location in a picture it would ask for access to the GPS as soon as you click the check mark. If for some reason Instagram allowed people to make calls, as soon as it tries to make the call you get a pop-up asking to confirm if you want to place the call or not.
> That said, there's also a few practical things the iOS walled-garden App Store could improve upon. First one being the $99 developer fee.
> Still, there is no malware in the repositories, at all. I admit I am a little bit vague on how this works too, perhaps I'm missing something obvious, but how do they do that?
All of the code on Linux repositories are (is?) open source if I'm not mistaken.
Linux software from the repositories doesn't need to ask for permission for anything (except sudo). Still, there is no malware in the repositories, at all. I admit I am a little bit vague on how this works too, perhaps I'm missing something obvious, but how do they do that?
You are simply trusting whoever is running the repository, most of the time this the distro itself, which you already trust.
There are two additions to the permissions API that I think would be very helpful:
1) Incremental Authorization - let Android apps ask for permissions only as they need them. So if you never use the phone dialing feature, they never ask for the permission.
2) One-time auth - allow an Android app to do something once. Say, scan your contacts one time. This gives you a little more control, so you know the dev isn't monitoring your phone at 3am.
Here is the problem though: most people don't actually care. The vocal minority cares, but most Android users don't know what a permission is if you ask them. So all that developers get for trying to work around permissions is less people using their app or less features in the app. Sadly there is no real incentive for a developer to be sparing with permissions for apps that target the mass market.
1) Incremental Authorization - let Android apps ask for permissions only as they need them. So if you never use the phone dialing feature, they never ask for the permission.
Not only incremental authorization, but the ability of denying specific permissions.
As far as I understand, there is an option that is even simpler for application developers: all applications have the permissions to see and alter whatever they want on the phone, up to a storage quota for modifications. Most of their accesses are hellbanned, though… Hellbanning logic can be altered by applications (obviously, the user would have to allow the configuration application to access the real settings), so granularity can be added as a bolt-on.
But I guess giving users actual security and privacy is against both Google's and Apple's interest, so this can only exist on a custom ROM without Google Play Services (or with sandboxed Google Play Services, which is probably against EULA).
Well with incremental the developer would put what is 'required' into the manifest for install-time prompt and incremental the rest.
You can't expect a developer to allow you to deny any permission, the whole app would be a giant if-statement spaghetti accounting for all of the permission combinations and workarounds.
As a user, I don't care if your app will self-destruct if you don't get access to permissions like "read and send SMSs". I simply don't want a free to play game to scan my SMSs for advertisement purposes.
iOS has taken option 1 since the beginning and it works.
I can install Instagram and deny it access to the camera. It still works, it doesn't crap out on me. I don't need to install 3rd party rooted tools to provide fake camera for it.
This is the another reason I use CyanogenMod. It has Privacy Guard and I can disable the nasty permissions as I please. If you have Android 4.3+, you can also install it indivudally https://play.google.com/store/apps/details?id=com.findsdk.ap... (requires root I guess)
The most helpful one, even if you are not privacy/security concerned is to disable wake up/keep awake requests, which Facebook and FB Messenger used it apporximately 6800 times since I installed my clean rom 1 week ago.
I love CyanogenMod (or at least the concept...I'm over dealing with the headache in practice), but the reason I used it was certainly not for improved stability and security.
Not that I particularly trust OEMs/carriers, but the only way I'd feel more secure with CyanogenMod is if I had time to audit the source and build the kernel and OS binaries myself, and that includes whatever code is used to root and unlock your device in the first place. If you do that though, more power to ya.
Also, disabling permissions at runtime is a foolproof way to make an app crash, as the vast majority of apps will assume they're granted the permissions hardcoded in the manifest at compile time.
One last point - rooting your phone and granting apps root access just to disable crucial permissions such as holding a wakelock seems pretty reckless - have you personally seen the source code for that app? At least the dev's website seems legit: http://www.findsdk.com/
EDIT: Even better, looks like the author of App Ops, or at least the owner if the findsdk.com domain, is in China :) https://who.is/whois/findsdk
IIRC, Privacy Guard simply returns empty sets of data instead of just revoking the permissions so the app shouldn't crash. It probably will lose functionality, but by actively turning on PG you're signing up for that.
CyanogenMod's "deny permission" behavior is largely the same as XPrivacy's, but way less fine-grained (and way easier to use). Basically it just returns "empty" data for requests - it doesn't revoke the permission, because yes, that would cause crashes.
The vast majority of applications work with this with no problems. They just won't e.g. show your contacts.
It is really a shame that Android doesn't provide this feature enabled by default anymore (as they did for at one point). It could easily be provided with a warning that this might break your apps and use with caution.
Security often has a UX trade-off, that doesn't mean it can't be handled well by good design.
As someone who is working on a (secure) Android ROM, I don't recommend trying to build the kernel from source unless you're serious about doing it, the Android repo build system is a mess and will take you hours to get working right.
This reminds me of the recent fireside android chat at I/O where someone said something like "I need to be prepared for although I got the permission, it might not be there".
...and they said "We work on the Play Store, and uh... that's not something we have any idea about"
"No, I think he's talking about the ROM's that let you take a permission away. Wanna talk about AppOps?"
This makes it all the more egregious that so many applications ask for permission to access contacts and similar.
Perhaps Android should rephrase these permissions as, for instance "direct access to contacts without your knowledge", as opposed to "access to user-selected contacts upon request" (which, as demonstrated, does not need permission).
I would be very happy if instead of preventing me from installing apps which require a given permission, Android would let me install them at my own risk in a sandbox which provides the app with dummy data and interactions (whether from a sensor, contacts db, camera etc).
It would be even better if the framework explicitly supported running apps without the necessary permissions and simply threw some sort of PermissionException. This would cripple some functionality while preserving the rest.
Developers could of course write the apps to not work under such reduced conditions, but Google Play could reject such apps.
Android had a hidden feature in certain iterations of Android 4, called "App Ops," that would let you do this but it never made it to prime time. Though Cyanogenmod does leverage it for their "Privacy Guard" feature.
This sounds like a great way for paranoid but uninformed users to break lots of apps, and then blame the developer/phone/carrier (in any random order).
We sometimes forget that really with smartphones the manufacturers are trying to produce something for the masses. This would also seem to include reducing the amount of security consciousness the user needs to have in order to have an "acceptable" experience with the device.
And yet, the iPhone basically does this for a number of permissions (location, push notifications, contacts access, etc.), and for the most part it seems to work for even uneducated users of iOS.
For most permissions, you might not want this, but for some of the more sensitive and personal-information rich sources, this is a really highly desirable feature.
Why aren't we as users allowed to fine grain the data on our device that we want the app to have access to?
A benign example would be a camera app; it wants access to my camera and mic, perhaps the local storage. It may have further features to store images in it's cloud service, assign the image to a contact and so forth.
But as a user I only want the app for it's picture taking ability - the app requests at the point of installation the permissions it requires, and I only grant it access to the camera.
It's then down to the app / developer to handle the exceptions and offer a message saying "You have taken a picture, but the app doesn't have permission to save it to storage. Please allow access by clicking here, otherwise this feature will not work/be unavailable".
A bit more of effort on the developers part, no question - but a user than has complete control over what an app can access.
I'm not an app developer, but skimming over how intents work and chiming along with this article - I don't think it would be a significant change to the underlying structure of android to hand back specific permission controls to a user.
I guess the app would have to handle not being allowed permission to do these things gracefully.
That's possibly a tall order based on my experience with apps these days, although for a difference reason: a lot of them assume there's internet connectivity, which isn't always the case, and a lot of apps don't handle this gracefully at all, even for doing things like opening maps, finding location, turning data off, going to another app, then back to maps again, and it takes ages for it to display because it's expecting to have network access.
I think it is not done that way because it would overwhelm most users. Maybe it could be some kind of expert mode, though. Don't some Android mods (like Cyanogen) allow you to do that?
Best i can tell, quite a few requested permissions do not come from the developer. Instead it is the defaults of some framework or other the developer used to handle some of the nitty gritty details, like the ads.
This is one of those weaknesses about 3rd party dependencies on Android. Unless business and product teams value user privacy and permissions, they usually could care less than vendor X's library requires permissions to read phone state or contacts when your app itself doesn't need it. Esp. given that iOS treats permissions differently, the distinction is often ignored in favor of whatever iOS does. To those managers, the fact that Android doesn't ask the user about using a permission is a happy coincidence.
Another angle being missed is that Android won't auto-update apps if they have new permissions (modulo some minor details). The developers I worked with always added more permissions to their initial app versions for things they weren't using, but might in the future.
Still, with the latest change in permissions handling in Play, it will happily auto-update an app if the new permission(s) are in the same category as a previous one...
Another reminder of how eagerly I await Xposed / Xprivacy on ART for 5.0... that said, his examples are fairly benign, I agree that if your app needs to initiate a call, it should show me the dialer to see if I would like to do that now, or some other time (including never).
If you're just waiting for permission controls, App Ops [1] should work just fine on 5.0. There are other comparable apps that also don't require Xposed.
In the case of bluetooth, you can either (1) request BLUETOOTH_ADMIN permission and enable BT yourself, or (2) ask Android to show an "Enable Bluetooth Dialog" (BluetoothAdapter.ACTION_REQUEST_ENABLE) which doesn't require that permission.
Good article. As good as Google's permission system is, it lacks obvious features. Maybe I'm missing something, but I think that Android permission are overly general and not specific enough in a majority of apps.
This is interesting because it's essentially the same security model as the web.
Your app runs in a controlled environment, and it has the option to nest another app (on the web, in an iframe) which it can send messages to, but can't affect the code or UI of.
The fact that the UI cannot be manipulated by the nesting app, is crucial, since it allows the security model to tie certain user actions, like pressing dial, to certain actions, like making a phone call.
I think all apps should be given a choice to have ephimeral permission. For example I dont want someone to find an exploit in my app and steal my user's contacts.
I would only take contacts permission when I need and keep it for a short duration and then willingly give it up. User can be explicitly prompted.
Also, Camera and Microphones should have only this sort of permissions other than for those which are explictily whitelisted by Google.
In the example about the phone call, you could give the user the option to hit the call button, but once this is complete a dialog should popup saying, "Do you want this to happen automagically henceforth?" which would then take full use of the Phone permission. This would also allow permissions to be toggled on/off, which a feature I really want in Android.
Just curious though for these specific examples as it says "if you read the source", could these intent's change in future releases, or is it documented outside of the source and accepted that using these intents is not relying on Android internals that could change?
This is why I love xprivacy. It gives me a popup when an app tries to access something, and I can whitelist or blacklist it, either on a temporary or permanent basis. Unlike google's halfarsed attempt at a privacy layer, it also doesn't give an exception when an app tries to access restricted data as that can cause apps to crash; it just sends back fake data (device ID is DEFACE, contacts are empty, location is christmas island, etc.). It also covers just about every permission you can think of, unlike app ops/privacy guard that are just a few.
Although really, what needs to change isn't just in android itself; it's also developer behaviour. Stop trying to do intrusive things like prefilling forms, as it doesn't benefit the user in any real way.
> Stop trying to do intrusive things like prefilling forms, as it doesn't benefit the user in any real way.
Speak for yourself -- I find prefilled forms to be a time-saver.
However, I don't want apps trying to read through my contacts in order to do it. What I want (but haven't actually configured) is xprivacy configured to make contacts appear empty.
This is classic privilege elevation via a 3rd party privileged process. I thought Android's permission system carrying the security context from app to app through Intent. Guess the assumption is wrong.
In most OS, the security token/context of the initiating process is carried over to the target process when it's asked to do something on behalf of the initiating process via IPC so that the target process runs at the privilege level of the initiating process even if the target process has a higher privilege to start with.
However that's not the only use case for android.permission.INTERNET - you need it for anything that does networking on the internet, such as API calls to your web application.
So the entire computer world had run like this for decade. why are people complaining about that now? Because Apple is doing strict verification of your code behaviour?
Yesterday adobe pdf viewer tell me that an update was available both on my mac and pc! So without asking my permission, this computer application (and many others) are querying the web...
The PCs didn't sit in your pocket all data with sensing GPS location, mic, camera, footsteps, discovery of bluetooth and wifi devices around you; neither were they single point of communication with the rest of the world.
People have been complaining about it for ages. Firewalls for outgoing connections are ancient technology. Like a lot of things that people rely on, the functionality is gradually moving into the OS proper.
A lot of people get upset at PC programs that do things like query for updates without permission.
Yes, but this relies on the program being friendly enough to give you a choice. The OS is not blocking it, it voluntarily refrains. Some are not so polite. For instance, Google Chrome auto-updates without asking permission, and the only way to stop it on Windows is to edit some registry setting. It will update even when it is not running, which annoys me since I have Chrome installed and don't use it, and every so often my computer slows to a crawl, I open Task Manager, and see "aha, chrome decided to update". It doesn't even give me the courtesy of displaying a notice, so I don't have to waste 5 minutes of acting like a detective with task manager.
If you disable the google updater service, it stops chrome from intrusively background updating. Be careful though, as it often gets reenabled when you open chrome.
When you do that, you delegate your UX and proper functionning of your app to a third-party app.
The UX can vary according the app. One thing is certain, it won't always be consistent with your app. It is also going to be more complicated for the user (more actions to make, more choices, just because you don't want to add permissions).
The proper functionning is even worse. Did you ever heard about the fragmentation of Android? Well, Intents are where it's worse. Some apps plainly don't work, or are buggy.
Intents are great to save time prototyping something. However, if a feature is central to your app, you are better off ensuring yourself that it works well and is easy to use, something that Intents can't guarantee.
Of course, the permission system is far from ideal, and some people will not install your app because you ask for some permissions. I'd say that's a price to pay for developping on Android.
P.S.: some examples of Intents that don't work so well:
1) sending a mail. Good luck finding how to properly use an Intent that is not handled by text apps and allow you to put attachments
2) picking a photo from gallery and resize. A lot of photo apps are plain broken for that Intent. And I'm not talking about some obscure device on a rooted Android, I'm talking about Google's Nexus, with stock apps.
I recently got a Moto E as my first smart phone, ever, and after checking out some apps, I was astounded and befuddled by the access permissions that it seems every app needs.
Take ESPN's fantasy football app, which requires:
device and app history - whats apps are running, browsing history, bookmarks
identity - accounts on the device, profile data
photo/media/files - access to files on the device and the device's external storage
wi-fi connection information - whether wi-fi is enabled, names of connected wi-fi devices
device ID and call information - determine the phone number and device IDs, whether a call is active, and the remote number connected by a call
I can understand why it might need access to the file system to, for example, upload an avatar. The access to wi-fi seems innocuous, although I would expect something like network connectivity and status to be delegated to a kernel module or background daemon with which an app interfaces.
But is there any legitimate (i.e. some non-financial oriented mine as much data as possible) reason it needs to be able to see what other apps are running, my browser history or who is on the other end of a call? There might not be any reason, and ESPN could potentially build the app to have as many or as few permissions as they deem valuable, because people want an app to manage fantasy football teams first. While this example might not be the best, since ESPN is a huge brand and there is no alternative if they are hosting your league, the situation was the same with so many other apps; just absurd permission requirements.
For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop the music when a phone call is coming in. We just use it to make pause on incoming call. (VLC on Android is also an audio player, with a background audio service).
The catch is, this is not an Intent you can send or request easily. We tried so many other ways, but none work.
But on the play store it's written "read phone status and identity" and that's really really scary for the users.
And even if we're 100% open source, so people can check the application, and even people recompile VLC, this is a complaint we receive a lot...