Comment by dkopi | Hacker News Reader

Comment by dkopi | Hacker News Reader

This reads to me as an overreaction. Sure, it's important to be vigilant about the permissions you give apps, but it's also important to understand the underlying OS and permission layers.

TLDR: If you're concerned about your privacy, upgrade to Android 6.0

There's nothing wrong with Wikipedia letting you manage your Wikipedia account using the app. They're using the Account Manager API, which is the right way to approach account management on android. Prior to android 6.0, they need the GET_ACCOUNTS permission to use the account manager.

Wikipedia's FAQ explains: Note: The app does not store your Wikipedia login credentials on the device, and it does not access any non-Wikipedia accounts on your device, nor any other aspects of your identity. Note: This permission is only required in Android versions earlier than 6.0 (Marshmallow). For Android 6.0 and above, this permission is not required.

GET_ACCOUNTS is a dangerous permission. That's why google changed the behavior in android 6.0 by: 1. Allowing users to decline specific permissions to apps, instead of the "accept all or none" approach in lollipop and bellow. 2. Allowing apps to manage the account they own without requesting GET_ACCOUNTS.

The Android docs explain this as well: Note: Beginning with Android 6.0 (API level 23), if an app shares the signature of the authenticator that manages an account, it does not need "GET_ACCOUNTS" permission to read information about that account. On Android 5.1 and lower, all apps need "GET_ACCOUNTS" permission to read information about any account.

Bottom line is: if you're concerned about app permissions (as you should be) - you should be running Android 6. Wikipedia won't ask you for GET_ACCOUNTS, and you'll be able to manually control permissions other apps receive as well.

TL;DR: Many Android devices don't have the option for arbitrarily upgrading at the user's option. You're limited to OS updates if and when your vendor can be arsed to get around to it.

The versions of Android on which this permission are required are precisely those on which it's a security issue. Ergo: don't use the permission.

Wikipedia's app describes what their intent is. Last time I checked, a large number of software security bugs were the result not of intent but poor execution. Again, applying principle of least privilege avoids this.

You yourself admit this is a dangerous permission.

More generally, there's a whole mess of problems with Android, its security and permissions system, and its app store. I've addressed those in earlier posts to G+, with the upshot being that Google really need to radically re-think where they're going with this and what they want it to be.

I find some attributes of Android hardware compelling. I find the actual environment to be rather a complete clusterfuck.

Last I checked, Google had registered something over 3 billion Android user identities. Relying on that large a population to 1) trust individual software authors with 2) no specific code of conduct or review process and 3) have a high level of familiarity with permissions systems, architectures, and peculiarities of specific releases strikes me as a good working definition of "unreasonable expectations".

> Last I checked, Google had registered something over 3 billion Android user identities. Relying on that large a population to 1) trust individual software authors with 2) no specific code of conduct or review process and 3) have a high level of familiarity with permissions systems, architectures, and peculiarities of specific releases strikes me as a good working definition of "unreasonable expectations".

What would the alternatives be (given 3 billion user identities)?

A system far more like Debian's in terms of app development/provisioning, and user-centric protections.

A dev-compensation system not dependent on advertising.

https://plus.google.com/104092656004159577193/posts/2eg1rG6k...

Sorry to say: Debian's has advantages, but is a pain in the ass. The focus on security and reliability in packages means both stable and unstable tend to be so far behind head that I rarely find things I want to try are directly supported by the available binaries. Which is not to say Debian's approach is bad for its purposes; I just wouldn't want to use a smartphone app ecosystem designed like that.

Advertising is trickier to wrestle down. I'm not sure in an ecosystem where advertising is allowed, a race to the bottom isn't to be expected, and best of luck banning it entirely.

Rather than respond to what you think I might have written, how about actually reading the suggestion and responding to its points. This would be more valuable to both of us.

People only ever respond to what they think other people have written; such is the nature of communication.

If you mean respond to the multi-paragraph G+ post: too many pieces to dedicate time to at this juncture. I misunderstood what you meant by the Debian model "in terms of app development" to refer to package creation / maintenance approach. If you mean these three elements:

Putting user interests first

Seeing specific limitations on app capabilities

Promoting Free Software in all possible cases

... Then I think from Google's standpoint, it's probably understood that they are covering #1 already (item 1 in https://www.google.com/about/company/philosophy/), #2 ought to be covered by M's security model, and #3 is a bit of a non-starter for a commercially viable app store (though Android certainly doesn't preclude it, as evidenced by F-Droid and other alternate app stores).

> I find some attributes of Android hardware compelling. I find the actual environment to be rather a complete clusterfuck.

Considering how easy it is to break the security on a powered on Android phone by just attaching a debugger to the JTAG interface, I would consider the hardware to also be inadequate when you compare it to the better physical security of iPhones. I don't like Apple or iPhones, but current Android phones can't beat them when it comes to physical security.

Also, since the code is open sourced (https://github.com/wikimedia/apps-android-wikipedia), I guess they get the benefit of the doubt?

Exactly. Their explanation for requesting the permission looks reasonable, and the source code confirms that they aren't using it for anything else. Wikimedia did nothing wrong here, and OP is getting worked up over nothing. If he wants better assurances, he should use a better phone.

OpenSSL was open sourced. That worked out real well.

It's not being open sourced that leads to secure, well-behaved software.

It's being well-behaved, secure software. Which, among other properties, means following the principles of least privilege and least capability. See the OpenBSD project for more on that philosophy.

This isn't C we're talking about. You don't magically expose random memory with Java code.

Tool choice may improve security. See again OpenBSD, which has specifically rewritten parts of the C library to avoid classes of bugs.

That said, Java has a markedly less-than-perfect record.

As someone else mentioned, open source is not a golden bullet. But, it being open source led tot he discovery of the bug and the fix, right?

And, in related news, Pwncloud:

https://blog.hboeck.de/archives/880-Pwncloud-bad-crypto-in-t...

The Android 6.0 version is better in some ways, but has its issues. For instance, in Android 6.0 the Internet permission is assumed. For the truly privacy conscious, the best internet is no internet.

There is something 'clean' about building an app without internet access. I created an app with schedule data that's updated every two months. With no need for regular updating, updates are distributed as app updates. The app was created in a weekend: no backend services to create or maintain.

You can use NetGuard [1] to block internet per app without root. (However, you can't use it if you need to use a VPN because NetGuard pretends to be a VPN, and Android only lets you use one at a time.)

[1] https://play.google.com/store/apps/details?id=eu.faircode.ne...

> upgrade to Android 6.0 That usually means buying a new phone.

Less than 5% of phones currently run Android 6.x. I don't really think that's a fair "requirement" to give to people, given that many people are otherwise prevented from getting a Marshmallow update not because of the age or model of their phones, but because the carrier has prevented it.

then we get into the whole "at what point do we stop supporting windows xp for real this time guys" argument though..

There's a big difference between a 10 year-old OS and a two-year old phone, though. Especially if the unlocked model of the phone has received a Marshmallow update, but your carrier decides they don't feel like going through the cert process for that when they could easily twist your arm to getting a nice, new $750 phone instead.

For Google Chrome the answer is: April 19

That decision is generally made by the app vendor. Apps in the Play Store declare a minimum OS version they compile / run against.

If someone was truly that concerned, they'd make the choice to buy a Nexus device for that protection rather than embrace a 3rd party device with manufacturer and carrier crud.

The user in question:

1. Purchased the device at a major electronics reseller during a period of specific contingency whilst travelling.

2. Prefers strongly to avoid mail-order purchasing for numerous reasons, including the possibility of in-transit interceptions and undocumented third-party enhancements.

3. Couldn't find a Nexus device at said major retailer.

4. Isn't aware of Nexus devices which offer expandable storage. Device in question has 128 GB of MicroSD storage. Max possible Nexus is ~16-32 GB last I checked, with no expansion possible.

I've explored other options, including a CyanogenMod reflash, though that's less than straighforward.

So, unfortunately, the world involves numerous compromises. I treat the device as hostile though of some utility. I've pressed several other app vendors on permissions, and am batting somewhat above 0.500 for having those reversed.

I've also vented considerable spleen at Google over how it manages Android. Given my previous record with recommendations, I expect to be fully vindicated in about 3-4 years.

The Nexus 6P comes in a 128 GB variant and it's available at a couple of Best Buy locations in the Bay. It also has the latest Android version.

What's the 10" tablet Nexus equivalent?

(Another gripe, this one about electronics generally: sorting out manufacturer's offerings is all but impossible ... so I don't bother. Apple actually does far better than most through simplicity, though I have other objections...)

It has nothing to do with fairness. The Android permission model prior to 6.0 was terrible. If you care about this stuff, then you'll want to use 6.0 or newer (or a non-Android phone with similar capabilities). It may not be fair that the phone you bought recently can't upgrade to 6.0 because Android OEMs are terrible, but the facts remain.

Besides, if you really care about this stuff, you bite the bullet, root your phone, and install an alternate OS that allows for permission faking and more graunular control.

As much as people on HN seem to hate to admit it, the average consumer does not care sufficiently (or have enough to hide) for the ability to do fine-grained permission control to be valuable to them, so it's a niche feature. Most apps from big vendors can be trusted; the maximum-harm case isn't the common case. On the plus side, in a couple years (when the average Android comes with M pre-installed), users will have the ability to do fine-grained control whether or not they care. That's an improvement.

Does Android 6.0 let you feed fake data to apps requesting useless permissions?

For legacy apps (that lived in a time before per-permission user-controlled configuration), yes. http://arstechnica.com/gadgets/2015/10/android-6-0-marshmall...

I don't know that it lets you tune what fake data is fed; the intent of the feature seems to be to make it possible for legacy apps to run in M at all, not to fuzz the metrics an app author might be collecting.

Reply on news.ycombinator.com