3 ms·

No, it's true. On-device actions count in the eyes of the law. "This app processes the user's data on-device, does not allow other apps to access the data, and

by Arnt 2y ago

No, it's true. On-device actions count in the eyes of the law. "This app processes the user's data on-device, does not allow other apps to access the data, and optionally copies it to a server that the user provides" is a description.

cyanydeez 2y ago
Righy, isny it easy to understand, esepcially if your app allows http? The data protection policy would explicitly state such a exposure. "No ezposure" is a state. Any app that allows a user to put in a endpoint that transfers the user data should have a data policy, since a malactor could convince the user to change thta endpoint, leading to a breach. I think that it seems benign only in theory.
- Arnt 2y ago
  IMO it is benign. Real-world apps don't get much better than that. For example, allowing the user to access the data is a feature, not a bug, and if you allow the user access to the data, then a blackhat can persuade the user to access and forward the data. This isn't a matter of HTTP or no HTTP, the user's data access is tightly bound to user's risk of social engineering. Being benign doesn't make the policy self-evident. Google's rule is that you have to state your policy, you're not allowed to argue that users should understand any policy as being self-evident. IMO that's good of Google, because the cost for nice apps like this is so minor: Having to write a one- or two-sentence policy.
  - cyanydeez 2y ago
    The point though, is, your dad is exiting the device and should have a data policy. If everything stays on the device, sure, ignore data privacy. But since you shuttle it through a hostile environment, it's important to identify how that data privacy is ensured.
    - Arnt 2y ago
      That's been used for attacks. Suppose there's an app, Niceapp, that keeps all data on device, and you want to attack it and exfiltrate its data. ① You install it, find out that it stores the data in /sdcard/Pictures/Niceapp, or some other world-readable directory. ② You write your own app with file system and network access permissions. You can find many suitable apps on github that you can rename and prettify. ③ You social-engineer users to install your app, which is then free to read the Niceapp data and exfiltrate them. The attack works because the unstated policy leaves users (and possibly also the Niceapp developers) open to make inaccurate assumptions.

by Arnt 2y ago

cyanydeez 2y ago

Righy, isny it easy to understand, esepcially if your app allows http? The data protection policy would explicitly state such a exposure. "No ezposure" is a state. Any app that allows a user to put in a endpoint that transfers the user data should have a data policy, since a malactor could convince the user to change thta endpoint, leading to a breach. I think that it seems benign only in theory.

Arnt 2y ago
IMO it is benign. Real-world apps don't get much better than that. For example, allowing the user to access the data is a feature, not a bug, and if you allow the user access to the data, then a blackhat can persuade the user to access and forward the data. This isn't a matter of HTTP or no HTTP, the user's data access is tightly bound to user's risk of social engineering. Being benign doesn't make the policy self-evident. Google's rule is that you have to state your policy, you're not allowed to argue that users should understand any policy as being self-evident. IMO that's good of Google, because the cost for nice apps like this is so minor: Having to write a one- or two-sentence policy.
- cyanydeez 2y ago
  The point though, is, your dad is exiting the device and should have a data policy. If everything stays on the device, sure, ignore data privacy. But since you shuttle it through a hostile environment, it's important to identify how that data privacy is ensured.
  - Arnt 2y ago
    That's been used for attacks. Suppose there's an app, Niceapp, that keeps all data on device, and you want to attack it and exfiltrate its data. ① You install it, find out that it stores the data in /sdcard/Pictures/Niceapp, or some other world-readable directory. ② You write your own app with file system and network access permissions. You can find many suitable apps on github that you can rename and prettify. ③ You social-engineer users to install your app, which is then free to read the Niceapp data and exfiltrate them. The attack works because the unstated policy leaves users (and possibly also the Niceapp developers) open to make inaccurate assumptions.