The issue is that the ad network economy, as currently structured, allows inflicting these costs against consumers -- who couldn't possibly keep track of them all even when technologically well-educated because there are so many apps, SDKs, advertisers and publishers -- while incentivizing application authors to take part with the assumption that they are safe in the crowd.
Rather than pay $5 for an app and hope that it won't misbehave now and/or in future, it generally seems preferable to use a competing free and open source application backed by a community that can inspect and modify it to add features and fix any discovered problems. When such software doesn't exist, it can be developed given enough demand and interest.
Most people always go for the cheapest option no matter how junky it is, and no matter how much an improvement paying a but extra would make (exhibit A: airplane tickets for tourists).
It seems like the only working method to get rid of the junk is to outlaw it.
Obviously nobody wants hackwerware.
The question posed by the OP is systematic: people are willing to 'not pay' for things because the 'short term benefit' is 'less cost' while the longer term risk, ie 'hackerware' is more vaugue.
A lot of things in life are like this.
Back in the day, the fire Dept. were private, they didn't come unless you were paying them insurance.
Given the common nature of 'fire' - and especially that it 'spreads to other homes' ... it makes too much sense for everyone to have it, and so we socialised it. We all pay for fire insurance via our homes.
The argument being, is that if people paid for apps, devs wouldn't have to resort to as much trickery, and there would be less use of malware. Though it's not so clear.
Given the excessive cost of iPhones and the significant rake on apps (~30%), Apple should cover this problem. They mostly do, but obviously not entirely.
I wonder if there should be a 3rd party lib repo where the code has to be open sourced, and 'someone' has to pay for a review of some kind. And you have to stick to such repos if you want a certain kind of certification.
It's an interesting problem in 2020, and looking back, it's almost amazing that in 1999 the web was so amazingly relatively safe, and that there wasn't so much existential angst over security. How naive we were!
That's really clever. It looks like it uses ObjC dynamic linking to swap out calls[0].
When I read stuff like this, I'm glad that I'm a "dependency curmudgeon."
I'm not sure I would have figured this out, if I had vetted the dependency (Actually, I'm pretty sure I would have missed it).
I'm wondering if Apple would be able to detect this behavior, in their review process. There are certainly legitimate uses for it, but I like to avoid these types of hacks, in my shipping apps.
It reminds of something I'd done to get past the App store review a long time ago. This was when the iPad had just come out and UISplitViewController was super buggy. I found that the only way to get the universal app I was building to work satisfactorily on both the iPad and the iPhone was to use one of their undocumented methods. We submitted the app for review and as I'd half expected, it was rejected for using an undocumented API. The work around was to rot-13 the selector for the undocumented method and to decode it at runtime, dynamically call the method with performSelector. That made it pass the review. And that's when I learnt that the reviewers were probably just running strings (the unix program) and grep to find apps using undocumented APIs. That was a long time ago, I hope things have gotten better by now. :)
Reviewer techniques of course improve somewhat and evolve over time, but in terms of basic heavy reliance on automation and the like it's doubtful much has changed. But that's ok, because the battle is about economics and layers not perfection. The final layer is what HN has been so up in arms about: eventual detection after the fact, at which point Apple bans the devs and in extreme instances can revoke certs/delete the malware in question (all while its harm is limited by sandboxing/trust chains/etc). The $100/yr wall layer stops some automated attacking and makes anonymity more difficult, the signing requirements make it harder to avoid specific attribution, the restrictive permissions model and such stop some attacks, the review process maybe catches a few more and certain softer attacks, all of which combined hopefully reduces the final volume of what gets through and the value of what can be achieved with it vs consequences to a level where post-hoc response (the most expensive kind) can keep up. And the single market means the process is hard to avoid entirely, and the interests of users can collectively push back on the power of developers.
So no silver bullets, each layer has a part to play. That's kind of expected though isn't it? It's the typical trade off scalability vs specificity.
I mean, there's a lot I don't understand about macOS but that's somehow less fun
If a heavily sandboxed, walled-garden App Store is still vulnerable on its smaller attack surface, then the open-for-all alternative will be absolutely plagued.
What is the point you're trying to make?
The App Store is a single target. It makes "discovery" easier for malware. Imagine if these apps had to get users the "old fashioned" way, one-by-one, word-of-mouth, etc. It also requires less initial setup for malware developers, as opposed to having to develop their own software distribution infrastructure. Every claim about the App Store making things easier for developers also applies to malware.
Moreover, the App Store race to the bottom undermined the previous paid upfront software model in favor of everything being free, supported either by ads or by "cash cow" manipulative IAP.
The Play store is such an unimaginable cesspit of crap that I've now stopped using it entirely except for official company apps, and then it will still suggest me malware clones every time.
Like I wanted a battery display for my AirPods and the choice was stuffed with ads, battery draining IAP from the Play store or a simple, free OSS one from F-Droid:
https://github.com/adolfintel/OpenPods
Of course, go figure, this app had to itself be modified to prevent scam artists from loading it up with advertisements and malware and putting it onto Play, where license violations are widespread and go entirely undetected.
Linux doesn’t have an “App Store” instead you have to engage with the community and publish your app source code if you want it easily installed by most users. I guess that’s still not quite a “free for all” (although there’s nothing stopping users from installing whatever they want) but it’s certainly not as strict as what apple does.
For the end user they were still watching ads just the same
Naive swizzling of system API's will be detected/stopped by App Review, right? Or perhaps only if it's private methods?
Not entirely sure how Apple's review-process works but if a majority of it is done in Mountain View there's a large chance that most reviewer devices aren't well spread out w/r/t to setting them to other regions.
Sometimes when looking for signs of malware the easiest thing to observe is either it’s use of Persistance or its checks for root/jailbreak rather than the malicious code itself.
I know there are many legitimate reasons for an app to obfuscate its code or to check if the device is rooted or running through a MITM proxy (such as banking apps for example) but I would think that if an app were submitted with these checks it should get flagged for further review at least.
There's an argument to be made that even those aren't legitimate, since you can do online banking from a desktop computer where you have root. I'd be in favor of app stores banning root checks from apps that don't need root.
