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.
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.)
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.
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.
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.
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.
(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.
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.
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)?
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.
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.
The app actually has a bunch of neat features: really nice typography, material design, offline articles, article preview cards. Just try it out, I found it to be a good experience.
Also, the Android version has half a million ratings so you can't really say it's unheard of.
1. Wikipedia is of itself a highly useful online resource, and one of a few that stands almost on its own.
2. Chrome browsers universally suck. They suck in different ways, but they all suck. For the purposes of reading Wikipedia, the Wikipedia app sucks considerably less.
3. Specifically, it's fast and responsive, doesn't keel over, offers a number of features (the next-article preview feature especially) which are useful, and allows me to maintain a tabset that's specific to Wikipedia research rather than The Web At Large. I can download/bookmark specific articles for offline viewing.
4. It is lacking bits. Not being able to access article history, talk pages, and other Wikipedia infrastructure among others. I need to see if it can be Tor routed as well.
Last time I used the app it didn't support 'Find in page' or pinching to zoom. The web site is great and just works for what I want to use it for. The only thing that's annoying is that when sections of the article are collapsed 'Find in page' doesn't work (which is obvious, but annoying).
Wikipedia's mobile site really is a usability disaster, with low-density tables and most of the content hidden by default. I've always had to scroll down and switch to Desktop to do any serious reading. It's as if the interface was designed for the first-gen iPhone, and subsequently abandoned.
At one point, pages had a "Permanently disable mobile site" link at the bottom, but they scrapped that back in 2012.
I don't mind if my app accesses geo as long as it doesn't exfiltrate. In a perfect world, only a small subset of an app's data should leave the device.
This ends up being pretty hard to do generically. If a geofence event triggers a network call, has geo information been exfiltrated?
As things are, I don't feel like I'm past having to trust the app author.
I've suggested separately that Google should can the concept of supporting apps and look at what functions it wants to provide, and provide a Free Software framework for supporting that, with a guidance structure specifying what app authors and package maintainers must and must not do.
This is not an overreaction at all. In fact, with the recent Wikipedia search engine debacal, the chances of these so called necessary permissions being unrelated, or coincidence, is nil and none. Jeez people keep up!
42 comments
[ 5.7 ms ] story [ 92.0 ms ] threadTLDR: 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.
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.
[1] https://play.google.com/store/apps/details?id=eu.faircode.ne...
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.
(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...)
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.
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.
That said, Java has a markedly less-than-perfect record.
https://blog.hboeck.de/archives/880-Pwncloud-bad-crypto-in-t...
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".
What would the alternatives be (given 3 billion user identities)?
A dev-compensation system not dependent on advertising.
https://plus.google.com/104092656004159577193/posts/2eg1rG6k...
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.
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).
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.
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.
Also, the Android version has half a million ratings so you can't really say it's unheard of.
See also: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Why_apps
1. Wikipedia is of itself a highly useful online resource, and one of a few that stands almost on its own.
2. Chrome browsers universally suck. They suck in different ways, but they all suck. For the purposes of reading Wikipedia, the Wikipedia app sucks considerably less.
3. Specifically, it's fast and responsive, doesn't keel over, offers a number of features (the next-article preview feature especially) which are useful, and allows me to maintain a tabset that's specific to Wikipedia research rather than The Web At Large. I can download/bookmark specific articles for offline viewing.
4. It is lacking bits. Not being able to access article history, talk pages, and other Wikipedia infrastructure among others. I need to see if it can be Tor routed as well.
At one point, pages had a "Permanently disable mobile site" link at the bottom, but they scrapped that back in 2012.
I don't mind if my app accesses geo as long as it doesn't exfiltrate. In a perfect world, only a small subset of an app's data should leave the device.
This ends up being pretty hard to do generically. If a geofence event triggers a network call, has geo information been exfiltrated?
As things are, I don't feel like I'm past having to trust the app author.
Pretty much Debian.
https://plus.google.com/104092656004159577193/posts/2eg1rG6k...
(Caution: harsh language.)
Edit: Updated link. Had the wrong Android rant referenced earlier.