News for hackers. Stuff that matters.
Re:We launched an app with $500k annual revenue, and then Ap... by megous on Monday June 17, 2019 @04:15PM (#20206864)
Apple could have just offered the app usage API, because it was obvioulsly lacking.
Re:We launched an app with $500k annual revenue, and then Ap... by scarface74 on Monday June 17, 2019 @04:27PM (#20206987)
An API for allowing third parties access to your personal information is not a ”feature”.
Re:We launched an app with $500k annual revenue, and then Ap... by megous on Monday June 17, 2019 @05:54PM (#20207758)
Huh? Most useful APIs will allow access to some data/data source.

The whole point of computing is to work with interesting data and process it somehow.

It's up to the user whether he allows the app to both access interesting data and the network, or only allows the apps that can work with the data locally.

Also, this API would be much less sensitive than allowing apps to access contacts list, or whatever, for which the API already exists.

Re:We launched an app with $500k annual revenue, and then Ap... by scarface74 on Monday June 17, 2019 @06:13PM (#20207878)
The application in question had access to all of your communications going to the internet from your device.

The whole purpose of computing is not to have access to all of your private information and to analyze it and sell it to third parties. They even admitted that their business model was fashioned after Onava’s that did just that and was bought by Facebook.

Re:We launched an app with $500k annual revenue, and then Ap... by megous on Monday June 17, 2019 @07:36PM (#20208355)
I was talking about Apple providing api to get information about screen time of other apps, so that these kinds of monitoring apps don't need such hacks.
Re:We launched an app with $500k annual revenue, and then Ap... by scarface74 on Monday June 17, 2019 @07:48PM (#20208445)
This is also why Facebook bought Onava. Even without access via a VPN, that would have been enough information for Facebook to know that people were spending a lot of time on WhatsApp and to know that it was becoming popular. Would you be okay with that?
Re:We launched an app with $500k annual revenue, and then Ap... by panopticon on Monday June 17, 2019 @04:37PM (#20207095)
I feel like the novel uses for such an API don't outweigh the costs.

Even if Apple did provide such an API, the app in question also blocked access to social media apps via the VPN. My head would explode if Apple allowed apps to exercise direct control over others apps in such a fashion.

Re:We launched an app with $500k annual revenue, and then Ap... by megous on Monday June 17, 2019 @06:00PM (#20207804)
Sorry, I don't see it. If some app blocks access to other apps, when you don't want it, you simlpy uninstall it.
Re:We launched an app with $500k annual revenue, and then Ap... by panopticon on Monday June 17, 2019 @07:51PM (#20208468)
If that answer was adequate, Apple wouldn't have to audit apps to ensure they're not abusing the contacts permission.

The potential for abuse and erosion of user trust seems orders of magnitude larger than the apps we are missing out on by not having such an API.

Re:We launched an app with $500k annual revenue, and then Ap... by megous on Monday June 17, 2019 @08:33PM (#20208741)
I was writing specifically about (potential) app blocking API.

I'm not sure what user trust you're talking about, though. Apple allowed shady VPN tracking/blocking apps in the past and users used them.

Re:We launched an app with $500k annual revenue, and then Ap... by panopticon on Monday June 17, 2019 @10:17PM (#20209256)
I was responding generally about either API; my thoughts are similar.

My position is one of a cost/benefit ratio. VPNs have a lot of good use cases (enterprise networking, privacy from shady networks, etc) that outweigh the potential for harm.

Good use cases for apps exercising control over others are screen time monitors and parental controls? Maybe I’m being unimaginative, but that’s a narrow band of functionality better served by OS-level features.