Edit: no, the more I think about it the more this interpretation is completely nuts. It implies that every single software vendor needs to secure consent from every single end user of software they ship through any client.
e.g. if SAP provide CRM software to Contoso, and Jim is a customer of Contoso, even though all the data is processed on Contoso premises, SAP still need to be in communication with Jim?
Contrary to a popular opinion, GDPR is fairly logical and close to common sense.
It gets murkier with "joint data processing" (a cursed cop-out for scenarios like Facebook acting both as a data processor for a website's ad tracking and as a data controller for its own ad tracking at the same time), but the scenario you described is not that.
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.
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.
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.
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.
It doesnt mattet if you good faith assume he user of your app is smart wnough to keep the app and that endpoint secure, you are providing a meansnto exfiltrate your app data
I know that's the opposite of what they led with, I'm not trying to be cheeky. It's just shorter if you invert the premise and avoid technicalities.
In general, on HN, I see people struggling to wrap their mind around that everyone who takes in data has to take it seriously, at least, that's how the app stores view it.
I don't even think this would apply in the pathological case where a bug in the app causes the personal data to be leaked. You didn't leak it, the user did.
EDIT: meant to reply lower.