10 ms·
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 underlyi
by dkopi 11y ago
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.
- butz 11y ago> upgrade to Android 6.0 That usually means buying a new phone.
- joelhaasnoot 11y agoThe 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.
- Mindless2112 11y agoYou 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.netguard https://play.google.com/store/apps/details?id=eu.faircode.ne...
- AdmiralAsshat 11y agoLess 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.
- pki 11y agothen we get into the whole "at what point do we stop supporting windows xp for real this time guys" argument though..
- AdmiralAsshat 11y agoThere'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.
- JohnTHaller 11y agoFor Google Chrome the answer is: April 19
- fixermark 11y agoThat decision is generally made by the app vendor. Apps in the Play Store declare a minimum OS version they compile / run against.
- radley 11y agoIf 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.
- dredmorbius 11y agoThe 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.
- pramodliv1 11y agoAlso, since the code is open sourced (https://github.com/wikimedia/apps-android-wikipedia https://github.com/wikimedia/apps-android-wikipedia), I guess they get the benefit of the doubt?
- lern_too_spel 11y agoExactly. 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.
- dredmorbius 11y agoOpenSSL 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.
- noobermin 11y agoAs 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?
- Nullabillity 11y agoThis isn't C we're talking about. You don't magically expose random memory with Java code.
- dredmorbius 11y agoTool 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.
- dredmorbius 11y ago
- dredmorbius 11y agoTL;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".
- fixermark 11y ago> 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)?
- dredmorbius 11y agoA 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/2eg1rG6kmJp https://plus.google.com/104092656004159577193/posts/2eg1rG6k...
- awqrre 11y agoDoes Android 6.0 let you feed fake data to apps requesting useless permissions?
- fixermark 11y agoFor legacy apps (that lived in a time before per-permission user-controlled configuration), yes. http://arstechnica.com/gadgets/2015/10/android-6-0-marshmallow-thoroughly-reviewed/5/ 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.