3 ms·

running software is inherently unsafe -- beyond legit security threats where an app is getting information you haven't granted it, their use of sensitive inform

running software is inherently unsafe -- beyond legit security threats where an app is getting information you haven't granted it, their use of sensitive information you have permitted needs to be more carefully audited of course they're sometimes violating their privacy policy -- no real history of punishment / legal consequences here except (1) at the highest size scale (FB / G), and even they get away with minor fines in the US. And (2) sometimes terms get read by courts in other matters, i.e. zappos. Plus product probably doesn't know the policy at some small companies; lawyers don't get involved enough. the solution here is much stronger OS-level permissions models that can track the provenance of sensitive information. very big difference between my location getting uploaded as part of a 'search nearby' (i.e. a click) vs in the background. sensitive information should audit every read and should be required to dump communication messages to an audit DB visible to the user. this is an area where open source can lead because it's easier for us to both run a policy checker / privacy linter and prove that it's running.

swiley 7y ago
I would argue that a far better solution is community maintained software like what’s used on many open source OSes. Occasionally these end up with backdoors inserted by large governments but it’s no where near as bad as what happens with smartphone apps.
- Fnoord 7y ago
  Open source and smartphone apps is not mutually exclusive. I guess you mean you want open source smartphone apps instead of closed source / proprietary smartphone apps. There are some. For example, Marcel Bokhorst developed the following applications: NetGuard, XPrivacyLua, and FairEmail [1] [1] https://github.com/M66B https://github.com/M66B
  - swiley 7y ago
    Note my phrasing, I'm aware of OSS apps. I'm sure the development experience is less extreme on android but smartphone development is nothing like the experience on the PC where dev tools (visual basic/TCL/python/bash even gcc) are very lightweight and easy to work with. On the iphone you actually have to send apple money and sometimes even fax them a copy of your drivers license. Yes, you can have "open source smartphone apps" (although it's much closer to source available since the users really have no way to modify it) but you absolutely can't have community maintained software (again, on the iphone. You can on android in theory but the tooling really doesn't seem built for sharing with other people.)
wool_gather 7y ago
Yup. In some cases it's not actually the app doing this either. That is to say, the devs at Yoyodyne Inc, who wrote the functionality you're actually paying for, also had to include some third-party SDKs for ads or SSO or analytics or whatever as part of the business requirements. And this is the problem: that SDK has all the same permissions as the code that the devs can see and audit. Even if the app isn't explicitly passing info into the SDK for tracking, the SDK can do whatever the heck it wants. (And there are sneaky workarounds like IP-based geolocation, which isn't perfect but also can't be easily stopped.) This is not to absolve the company that incorporated the SDK of responsibility; but it's also worth noting that in a lot of cases they're probably not doing it deliberately, aren't benefiting directly, and may not even know that it's happening. We, as iOS developers selling an app to our users, absolutely should know, but don't always. This is something that I think engineers should be pushing back on the business side whenever we can. These leaks that we open up aren't worth the gain. I would love it if Apple came up with a way to expand their extension model and let us easily sequester third-party code. We'll see if something like that develops.

swiley 7y ago

I would argue that a far better solution is community maintained software like what’s used on many open source OSes. Occasionally these end up with backdoors inserted by large governments but it’s no where near as bad as what happens with smartphone apps.

Fnoord 7y ago
Open source and smartphone apps is not mutually exclusive. I guess you mean you want open source smartphone apps instead of closed source / proprietary smartphone apps. There are some. For example, Marcel Bokhorst developed the following applications: NetGuard, XPrivacyLua, and FairEmail [1] [1] https://github.com/M66B https://github.com/M66B
- swiley 7y ago
  Note my phrasing, I'm aware of OSS apps. I'm sure the development experience is less extreme on android but smartphone development is nothing like the experience on the PC where dev tools (visual basic/TCL/python/bash even gcc) are very lightweight and easy to work with. On the iphone you actually have to send apple money and sometimes even fax them a copy of your drivers license. Yes, you can have "open source smartphone apps" (although it's much closer to source available since the users really have no way to modify it) but you absolutely can't have community maintained software (again, on the iphone. You can on android in theory but the tooling really doesn't seem built for sharing with other people.)

wool_gather 7y ago

Yup. In some cases it's not actually the app doing this either. That is to say, the devs at Yoyodyne Inc, who wrote the functionality you're actually paying for, also had to include some third-party SDKs for ads or SSO or analytics or whatever as part of the business requirements. And this is the problem: that SDK has all the same permissions as the code that the devs can see and audit. Even if the app isn't explicitly passing info into the SDK for tracking, the SDK can do whatever the heck it wants. (And there are sneaky workarounds like IP-based geolocation, which isn't perfect but also can't be easily stopped.) This is not to absolve the company that incorporated the SDK of responsibility; but it's also worth noting that in a lot of cases they're probably not doing it deliberately, aren't benefiting directly, and may not even know that it's happening. We, as iOS developers selling an app to our users, absolutely should know, but don't always. This is something that I think engineers should be pushing back on the business side whenever we can. These leaks that we open up aren't worth the gain. I would love it if Apple came up with a way to expand their extension model and let us easily sequester third-party code. We'll see if something like that develops.