Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android: I don't need your permission

blog.danlew.net

Post reply on HN
Print view View original

111–120 of 190 posts

Re: Android: I don't need your permission

#111

Post by titanomachy »

habosa wrote: post #109
Aldo_MX wrote: post #90

Earlier quoted context omitted.

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.

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.

Even if you failed to guarantee a functional app for people who deny permissions, it would still be an improvement over the current status quo.

Re: Android: I don't need your permission

#112

Post by 9mit3t2m9h9a »

click170 wrote: post #99
Aldo_MX wrote: post #90

Earlier quoted context omitted.

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.

Take it a step further, I should be able to forge the contacts in my address book, my GPS coordinates, the list of installed apps.. The list goes on. But I would happily start with incremental permissions. Baby steps.

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).

Re: Android: I don't need your permission

#113

Post by marvy »

pbhjpbhj wrote: post #93
marvy wrote: post #63

Earlier quoted context omitted.

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 of…

AFAIR Adobe Viewer does give that option, generally I'm sure you're right.

Yes, they are one of the polite ones. Honestly very few are as obnoxious as Chrome.

Re: Android: I don't need your permission

#114

Post by mcintyre1994 »

masklinn wrote: post #53
aferreira wrote: post #50

Earlier quoted context omitted.

Actually, I don't think you need it. 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.

That the phone application is launched does not mean the user is currently in a call, they could be browsing their contacts list.

Skype is an even worse example too, I use it for IM more than calls and it presumably stays open for a long time, probably forever on those occasions.

Re: Android: I don't need your permission

#115

Post by JohnTHaller »

Someone1234 wrote: post #72
JohnTHaller wrote: post #31

Earlier quoted context omitted.

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 com…

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.

Re: Android: I don't need your permission

#116

Post by blub »

mike_hearn wrote: post #87
r00fus wrote: post #77

Earlier quoted context omitted.

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 person…

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.

Re: Android: I don't need your permission

#117

Post by hrktb »

hrjet wrote: post #106
MichaelGG wrote: post #101

Earlier quoted context omitted.

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 h…

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.

Re: Android: I don't need your permission

#118

Post by robert_tweed »

> 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.

Re: Android: I don't need your permission

#119

Post by pjmlp »

robert_tweed wrote: post #118

> 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.…

> If anything, I can see a bright future for Microsoft.

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.

Re: Android: I don't need your permission

#120

Post by leni536 »

gabemart wrote: post #97
quantumet wrote: post #56

Earlier quoted context omitted.

So does Android: http://developer.android.com/training/managing-audio/audio-f... http://android-developers.blogspot.com/2013/08/respecting-au...

This simply doesn't work for pausing audio when the phone rings. The ringer doesn't request audio focus.

The ringer doesn't request audio focus.

I would think that this is a bug in the ringer and not an overall limitation of the Android permission system.

Post reply on HN