6 ms·

> developers will need to explain why they're using certain APIs. Great! I just hope the same will be introduced on Android. From the very beginning of the sma

> developers will need to explain why they're using certain APIs. Great! I just hope the same will be introduced on Android. From the very beginning of the smartphones history, I immediately noticed apps put pointless requirements to be given permission for everything and I wanted such a policy to exist. No permission besides those strictly necessary to fulfill the very function of the app should ever be given or even asked for. Nevertheless I'm afraid such clauses increase the power of the vendors like Apple to fight the apps which do whatever they hate even if that is what the user wants.

the_lego 3y ago
Don't hold your breath. XPrivacy software for rooted Android could give fake data to apps 7+ years ago [1], effectively accomplishing what that policy would. But rooting has become more difficult and more undesirable due to SafetyNet, and Google has not implemented such a feature in official Android. They are actively hostile to user control. [1] https://news.ycombinator.com/item?id=36645100 https://news.ycombinator.com/item?id=36645100
- qwerty456127 3y ago
  Yes, I used XPrivacy in the past. But it has became more weird and I don't even understand if it or any successor still is maintained or not.
  - folmar 3y ago
    LuaXPrivacy is not maintained but works and is updated for Android 13.
- realusername 3y ago
  Slightly unrelated but we really need an equivalent to userscripts on mobile so that users can inject modifications to their apps for adding changes they need. I really liked the xprivacy concept and it should be extended to full scripts.
  - Zak 3y ago
    That's effectively what Xposed, the framework used by Xprivacy was. Of course the security implications of malicious code running inside Xposed would be nightmarish.
    - realusername 3y ago
      I'm going to have a look then, I heard the name but I did not know it was I think. Sure there's security issues with this concept but it's so powerful that it's worth it.
- criley2 3y ago
  >They are actively hostile to user control. These lines are wild. Android has great privacy controls and has had them as long or longer than Apple has. Android gives 0 permissions by default in an app. Android requires 1 by 1 permission granting following a standard of least-required. Android's default permission selection is "Only this time" and not "Forever", meaning most users only grant temporary permission to the app. Android then automatically removes "forever" permissions that are unused after a period of 30-90 days without user input. Android is so aggressive about it that most "background" apps (widgets/battery monitors/weather) silently stop working as Google ruthlessly rips permissions away. Heck -- unlike Apple, Google distributes nearly all of their apps and even system components through the App Store and still relies on standard user permissioning! You still have to grant Google the same permissions you grant any other app, even though it's "OS level". Imagine Apple authentically asking you for permission when you open a first party app and respecting it! It's basically impossible to have an app use a permission you didn't know about on Android these days. And in light of the great reality we live in, you have some crazy Apple stans in here saying "Google is actively hostile to user control". That line is wild considering almost every major iOS UX or hardware enhancement was ripped straight from an Android device that debuted it years prior... Between Apple and Google, there is no argument that Apple is the most hostile device company to "user control" in history. That's their thing! There's one way to do it, the Apple way, and if you want to customize it differently, you're the problem! ("Hostile to user control")
  - realusername 3y ago
    > Heck -- unlike Apple, Google distributes nearly all of their apps and even system components through the App Store and still relies on standard user permissioning! You still have to grant Google the same permissions you grant any other app, even though it's "OS level". Imagine Apple authentically asking you for permission when you open a first party app and respecting it! That's clearly the big difference between both. Who knows what the internal apps are using on iOS, certainly not anything standard. That's also why it's usually the first attack vector on zero days.
    - photonerd 3y ago
Zak 3y ago
Sometimes the scopes of permissions are surprising. For example. scanning for Bluetooth devices on Android requires the location permission. Why? Bluetooth beacons can be used to precisely locate a device. Unfortunately, there isn't a way provided to the average user to say that an app can use Bluetooth, but not GPS. https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id https://developer.android.com/about/versions/marshmallow/and...
- vxNsr 3y ago
  With Bluetooth beacons they don’t need gps, with just Bluetooth beacons they can triangulate your location, there’s no way to know if an app is gonna do that vs just try to connect to your (non-Apple) headphones or watch
- tzs 3y ago
  > Sometimes the scopes of permissions are surprising. For example. scanning for Bluetooth devices on Android requires the location permission. Why? Bluetooth beacons can be used to precisely locate a device. I am indeed surprised by that. I would have expected the location permission to just control whether or not the app can use the system's location APIs or access GPS (if the system provides low level access to the GPS that doesn't require going through the location APIs). Having it control access to something that is not specifically a location service but that might sometimes be usable to obtain information that can be used to figure out location does not seem wise to me, because all kinds of things that you might not expect to provide such information do. For example internet access can provide location information indirectly via IP geolocation. If they try to stop all of that through the location permission then a bazillion apps that the user does not think of as having anything to do with location would have to require location permission, and users would learn that if an app asks for that they have to give it to them.
  - Timon3 3y ago
    > Having it control access to something that is not specifically a location service but that might sometimes be usable to obtain information that can be used to figure out location does not seem wise to me, because all kinds of things that you might not expect to provide such information do. For example internet access can provide location information indirectly via IP geolocation. Using Bluetooth beacons you can get the location of a user accurate to a couple of meters, possibly granular enough to identify the individual. Continuous tracking can track your movements with the same scale. IP geolocation will at best be a radius of multiple kilometers. There's a big difference between "I know where you're standing at this second" and "I can guess what part of the country you're in".
Larrikin 3y ago
This has been a requirement in the Play store for years. You have to explain a number of "sensitive" permissions, often times with videos. You will be rejected if they don't think the feature adds value
- qwerty456127 3y ago
  Nice! I haven't checked for quite a long. I'm glad it is this way already. Especially considering the fact a user still is free to opt out of any policy by sideloading the app from the author's website.

the_lego 3y ago

Don't hold your breath. XPrivacy software for rooted Android could give fake data to apps 7+ years ago [1], effectively accomplishing what that policy would. But rooting has become more difficult and more undesirable due to SafetyNet, and Google has not implemented such a feature in official Android. They are actively hostile to user control. [1] https://news.ycombinator.com/item?id=36645100 https://news.ycombinator.com/item?id=36645100

qwerty456127 3y ago
Yes, I used XPrivacy in the past. But it has became more weird and I don't even understand if it or any successor still is maintained or not.
- folmar 3y ago
  LuaXPrivacy is not maintained but works and is updated for Android 13.
realusername 3y ago
Slightly unrelated but we really need an equivalent to userscripts on mobile so that users can inject modifications to their apps for adding changes they need. I really liked the xprivacy concept and it should be extended to full scripts.
- Zak 3y ago
  That's effectively what Xposed, the framework used by Xprivacy was. Of course the security implications of malicious code running inside Xposed would be nightmarish.
  - realusername 3y ago
    I'm going to have a look then, I heard the name but I did not know it was I think. Sure there's security issues with this concept but it's so powerful that it's worth it.
criley2 3y ago
>They are actively hostile to user control. These lines are wild. Android has great privacy controls and has had them as long or longer than Apple has. Android gives 0 permissions by default in an app. Android requires 1 by 1 permission granting following a standard of least-required. Android's default permission selection is "Only this time" and not "Forever", meaning most users only grant temporary permission to the app. Android then automatically removes "forever" permissions that are unused after a period of 30-90 days without user input. Android is so aggressive about it that most "background" apps (widgets/battery monitors/weather) silently stop working as Google ruthlessly rips permissions away. Heck -- unlike Apple, Google distributes nearly all of their apps and even system components through the App Store and still relies on standard user permissioning! You still have to grant Google the same permissions you grant any other app, even though it's "OS level". Imagine Apple authentically asking you for permission when you open a first party app and respecting it! It's basically impossible to have an app use a permission you didn't know about on Android these days. And in light of the great reality we live in, you have some crazy Apple stans in here saying "Google is actively hostile to user control". That line is wild considering almost every major iOS UX or hardware enhancement was ripped straight from an Android device that debuted it years prior... Between Apple and Google, there is no argument that Apple is the most hostile device company to "user control" in history. That's their thing! There's one way to do it, the Apple way, and if you want to customize it differently, you're the problem! ("Hostile to user control")
- realusername 3y ago
  > Heck -- unlike Apple, Google distributes nearly all of their apps and even system components through the App Store and still relies on standard user permissioning! You still have to grant Google the same permissions you grant any other app, even though it's "OS level". Imagine Apple authentically asking you for permission when you open a first party app and respecting it! That's clearly the big difference between both. Who knows what the internal apps are using on iOS, certainly not anything standard. That's also why it's usually the first attack vector on zero days.
  - photonerd 3y ago

Zak 3y ago

Sometimes the scopes of permissions are surprising. For example. scanning for Bluetooth devices on Android requires the location permission. Why? Bluetooth beacons can be used to precisely locate a device. Unfortunately, there isn't a way provided to the average user to say that an app can use Bluetooth, but not GPS. https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id https://developer.android.com/about/versions/marshmallow/and...

vxNsr 3y ago
With Bluetooth beacons they don’t need gps, with just Bluetooth beacons they can triangulate your location, there’s no way to know if an app is gonna do that vs just try to connect to your (non-Apple) headphones or watch
tzs 3y ago
> Sometimes the scopes of permissions are surprising. For example. scanning for Bluetooth devices on Android requires the location permission. Why? Bluetooth beacons can be used to precisely locate a device. I am indeed surprised by that. I would have expected the location permission to just control whether or not the app can use the system's location APIs or access GPS (if the system provides low level access to the GPS that doesn't require going through the location APIs). Having it control access to something that is not specifically a location service but that might sometimes be usable to obtain information that can be used to figure out location does not seem wise to me, because all kinds of things that you might not expect to provide such information do. For example internet access can provide location information indirectly via IP geolocation. If they try to stop all of that through the location permission then a bazillion apps that the user does not think of as having anything to do with location would have to require location permission, and users would learn that if an app asks for that they have to give it to them.
- Timon3 3y ago
  > Having it control access to something that is not specifically a location service but that might sometimes be usable to obtain information that can be used to figure out location does not seem wise to me, because all kinds of things that you might not expect to provide such information do. For example internet access can provide location information indirectly via IP geolocation. Using Bluetooth beacons you can get the location of a user accurate to a couple of meters, possibly granular enough to identify the individual. Continuous tracking can track your movements with the same scale. IP geolocation will at best be a radius of multiple kilometers. There's a big difference between "I know where you're standing at this second" and "I can guess what part of the country you're in".

Larrikin 3y ago

This has been a requirement in the Play store for years. You have to explain a number of "sensitive" permissions, often times with videos. You will be rejected if they don't think the feature adds value

qwerty456127 3y ago
Nice! I haven't checked for quite a long. I'm glad it is this way already. Especially considering the fact a user still is free to opt out of any policy by sideloading the app from the author's website.