Android: I don't need your permission(blog.danlew.net) |
Android: I don't need your permission(blog.danlew.net) |
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...
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.
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.)
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".
It's totally nuts. Knowing the phone is ringing or off the hook should not be privileged information.
It seems like it could be a privacy concern. It seems a common enough need that it probably shouldn't be lumped together with other things, though.
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.
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).
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?
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.
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
They aren't.
That does not prevent the emails.
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?
Just a thought.
We're a background service to play audio.
And adding a new permission is the opposite of what we want.
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.
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.
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.
Not only incremental authorization, but the ability of denying specific permissions.
But I would happily start with incremental permissions. Baby steps.
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.
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.
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.
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).
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.
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.
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.
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.
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...
[1] https://play.google.com/store/apps/details?id=com.findsdk.ap...
But #2 has been busted for a while https://code.google.com/p/android/issues/detail?id=60002
They didn't fix it, and marked it obsolete. So I guess we need BLUETOOTH_ADMIN after all.
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 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.
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.
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.
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.
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...
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.
We all eventually accepted that you should let the OS do its native thing. Android is no different.
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.
None were installed.
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
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.
[0] - https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...
Even compiling from source, one also has to trust the compiler...
(see, e.g. the classic http://cm.bell-labs.com/who/ken/trust.html, pdf version at https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)
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.
You can use two different compilers that compile each other to prove that the compilation won't be tampered with.
See https://www.schneier.com/blog/archives/2006/01/countering_tr...
In technology as elsewhere, it seems life is ultimately based on trust in someone.
2. How many people other than blackhats actually have the time to do this for every single automatic update?
I have both Android and Windows Phones.
The Windows Phone is actually quite good and from developer point of view, a pleasure compared with Android tooling and APIs.
Just the way Microsoft behaved with the customers has made many look elsewhere.
If WP would achieve just 10% market share in my country, I'd drop Android in a heartbeat.
My app deals primarily with Bluetooth BR/EDR + BLE comms to to external devices. Its been nonstop bugginess.
Nevermind Wifi Direct, which I can't get working on a good day. I keep hoping the opengarden guys will be able to overcome the crappy Android apis.
(An example of how the Windows phone permissions and intents systems work in practice would be nice too)
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 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?
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
The way permissions work in iOS is like this:
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.
Thankfully there's a huge market for jailbreaks now, so pretty much the latest version of iOS is jailbroken about half the time. (http://iphonedevwiki.net/index.php/Compiling_iOS_application...) It ends up being much easier than Android development.
> 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.
You are simply trusting whoever is running the repository, most of the time this the distro itself, which you already trust.
Huh? If a developer had made the choice correctly, the user would never need to know about it.
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
The vast majority of applications work with this with no problems. They just won't e.g. show your contacts.
http://www.guidingtech.com/23409/enable-android-permissions-...
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.
...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?"
Everyone looks awkward. 'No'. Ok... let's quickly talk about something else instead.
(watch it here. Fun times. http://youtu.be/K3meJyiYWFw?t=17m27s)
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).
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.
It may not need hundreds more permissions, it may even only need one more as this one seems to be a very common problem.
It's not like you have a large choice of good compilers for any given language/platform pair.
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.)
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.
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.
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).
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.
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.
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".
trust is a function of control. With free software it is distributed trust and control. With proprietary Sw it is centralized trust and control.
Real life proved that centralized control is a bad idea, that is why we invented democracy and free software.
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.
That is distinct, though, from "there is no privacy concern."
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.
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 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.
I have no desire to use syncing, so I would be stuck without an essential feature, in order for them to fix edge cases in something that I don't need.
What I think is particularly sad is that Google could still make a huge amount of money without exposing one's private information directly.
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.
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!
You're still probably screwed though.
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
According to Android Police an update earlier this month to the Play Store app appears to have separated them again: http://www.androidpolice.com/2014/12/06/apk-teardown-play-st...
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.
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.
You give your permission when you install it with auto-update enabled. I always disable auto-update.
A lot of people get upset at PC programs that do things like query for updates without permission.
I would think that this is a bug in the ringer and not an overall limitation of the Android permission system.
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.