4 ms·

> Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite o

> Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite or something' for example) all make way more of a difference. I'd like to go off a tangent here. On LineageOS, under privacy settings you can deny apps permissions such as run at boot and run in background. I wish deny was default mode in all of Android and that apps would have to ask for permission to run at boot. This is good for the end user and this is good for Google as Play Services should have this turned on by default meaning greater adoption for Google Cloud Messaging. This can't happen in one step because the proverbial cat is currently out of the bag and we have to sort of slowly put it back in. Something similar needs to happen with all permissions. File storage: afaik all apps have access to their own data store. Most apps should not need access to device storage at all. Almost no app should require access to phone permission. For example, look at this page by Capital One: https://www.capitalone.com/applications/mobile/android/permissions/ https://www.capitalone.com/applications/mobile/android/permi... > Don’t worry, we aren’t going to call you to find out your plans for the weekend. This permission allows us to use unique phone information (SIM ID and phone number) to guard against unusual sign-in activity. It’s a little extra security to help protect your money. What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. That being said, I am not an iOS fan either. I have problems with iOS as well. Why isn't there a way to limit data usage to say n MB a month? Why in the world should it take an OS update to update iMessage or Safari? How is this still a thing now that the iPhone is almost ten(!) years old?

gizmo686 9y ago
>What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones.
- thanksgiving 9y ago
  > Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones. This is too heavy-handed. Capital One lets me log in from any computer browser anywhere using just my username and password. As of Marshmallow, > The most straightforward solution to identifying an application instance running on a device is to use an Instance ID, and this is the recommended solution in the majority of non-ads use-cases. Only the app instance for which it was provisioned can access this identifier, and it's (relatively) easily resettable because it only persists as long as the app is installed. https://developer.android.com/training/articles/user-data-ids.html https://developer.android.com/training/articles/user-data-id... The only pertinent use case the document details for using Phone permission for a credit card app: > Abuse detection: Detecting high value stolen credentials > In this case, you are trying to detect if a single device is being used multiple times with high-value, stolen credentials (e.g. to make fraudulent payments). > We Recommend: IMEI/IMSI (requires PHONE permission group in Android 6.0 (API level 23) and higher.) > Why this Recommendation? > With stolen credentials, devices can be used to monetize multiple high value stolen credentials (such as tokenized credit cards). In these scenarios, software IDs can be reset to avoid detection, so hardware identifiers may be used. but the capital one app does none of those things! Even if it did, I'd imagine I am a pretty average user and all I want to be able to do is look at my list of transactions and pay my credit card bill every month and maybe cash out my reward. The phone permission can wait until you really need it. If we criticize Amazon for encouraging users to make their devices less secure https://www.amazon.com/gp/help/customer/display.html?nodeId=201482620 https://www.amazon.com/gp/help/customer/display.html?nodeId=... then we should criticize Capital One for permissions proliferation as well.
jayd16 9y ago
If its any consolation, in the latest version of Android, the permission model is mostly how you describe.

gizmo686 9y ago

>What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones.

thanksgiving 9y ago
> Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones. This is too heavy-handed. Capital One lets me log in from any computer browser anywhere using just my username and password. As of Marshmallow, > The most straightforward solution to identifying an application instance running on a device is to use an Instance ID, and this is the recommended solution in the majority of non-ads use-cases. Only the app instance for which it was provisioned can access this identifier, and it's (relatively) easily resettable because it only persists as long as the app is installed. https://developer.android.com/training/articles/user-data-ids.html https://developer.android.com/training/articles/user-data-id... The only pertinent use case the document details for using Phone permission for a credit card app: > Abuse detection: Detecting high value stolen credentials > In this case, you are trying to detect if a single device is being used multiple times with high-value, stolen credentials (e.g. to make fraudulent payments). > We Recommend: IMEI/IMSI (requires PHONE permission group in Android 6.0 (API level 23) and higher.) > Why this Recommendation? > With stolen credentials, devices can be used to monetize multiple high value stolen credentials (such as tokenized credit cards). In these scenarios, software IDs can be reset to avoid detection, so hardware identifiers may be used. but the capital one app does none of those things! Even if it did, I'd imagine I am a pretty average user and all I want to be able to do is look at my list of transactions and pay my credit card bill every month and maybe cash out my reward. The phone permission can wait until you really need it. If we criticize Amazon for encouraging users to make their devices less secure https://www.amazon.com/gp/help/customer/display.html?nodeId=201482620 https://www.amazon.com/gp/help/customer/display.html?nodeId=... then we should criticize Capital One for permissions proliferation as well.

jayd16 9y ago

If its any consolation, in the latest version of Android, the permission model is mostly how you describe.