Hacker News Reader

Sounds to me like what you're saying is that the walled-garden approach of needing to approve every app that ever gets developed as a whole is what's infeasible without creating kafkaesque conditions dealing with their automation, and I fail to see how you've made a case for this automation being all that good in the first place, given that your main argument for it is that it's found "millions of vulns in apps over the years" but then later cite "millions of apps" as a reason you can't expand the support team.

I would suggest that it might be worthwhile to use OS-level features to stop apps from behaving maliciously in more general ways, but a lot of what I would consider malicious behavior (e.g. sending user analytics to third parties, feeding them misleading ads, messing with other processes, etc) is part of google's business model or claims of added value in many cases, so that seems unlikely to happen.

You are nonetheless astute to point out that we can't really blame the individual or even group-wise incompetence of their support teams here. What it is worthwhile to blame is the entire business model of trying to own and control a platform that supports so many users in the first place without giving them the autonomy to self-govern. No company can possibly be so many things to so many people and not screw them over. In a way, it's the same problem planned economies have. Even making the very generous assumption that this is never out of malice or greed, we can still view the major problems millions of people face due to this scale and inflexibility as practically inevitable.

> Sounds to me like what you're saying is that the walled-garden approach of needing to approve every app that ever gets developed as a whole is what's infeasible without creating kafkaesque conditions dealing with their automation, and I fail to see how you've made a case for this automation being all that good in the first place, given that your main argument for it is that it's found "millions of vulns in apps over the years" but then later cite "millions of apps" as a reason you can't expand the support team.

People definitely make that claim. I don't think I fully agree. From the reviews of this particular system I've seen, they are able to actually hit virtually zero false positives. The challenge is that this comes at a high cost of missed issues, which also generates complaints.

> I would suggest that it might be worthwhile to use OS-level features to stop apps from behaving maliciously in more general ways, but a lot of what I would consider malicious behavior (e.g. sending user analytics to third parties, feeding them misleading ads, messing with other processes, etc) is part of google's business model or claims of added value in many cases, so that seems unlikely to happen.

Unfortunately, people also get pissed when platform behaviors are locked down to prevent abuse. Heck, people demand to have access to rootkits despite also wanting it to be impossible for a malicious app to harm them.

They can’t really have their cake and eat it too.

Either they have a system with zero false positives and they should have a review team for all the complaints of things that slipped through. Or they should aim for zero false negatives and have a review team for anything which gets stuck.

A false positive is "rejecting an app because of a behavior that isn't actually present." You've got them backwards.

> I actually know the team that does security vuln automation for Google Play. They've found millions of vulns in apps over the years. One of the challenges they face is precisely this sort of headline: how do you use static analysis to find vulns and ensure that you don't inundate users with false positives, forcing them down the admittedly limited support channels.

Pay people to do tiered support.

"but that costs money"

Make less. Or don't have an app store.

> Pay people to do tiered support.

This exists. You can sign up for a contract that will grant you various tiers of support.

>Google pays external hackers who find vulns in popular apps via a rewards program.

How does that work? Is the submission farmed out to a 3rd party as part of the verification process, and proactively checked? Or is it reactive, similar to a bug bounty? Are there people out there making their living running apks in desktop simulators looking for issues?

I always wondered about the economics of checking huge quantities of arbitrary code (well, bytecode) for vulnerabilities, even for a 30% cut (which is probably 0 for 99% of apps, right? I would expect a power law distro). Kinda sounds like Google solved this by running the apks through something like a CI/CD gauntlet and then...hoping for the best.

And of course you can't be too transparent or bad actors will game the system. It's almost as if, as a sibling commentor mentions, it's just not possible to adequately run a walled garden that adequately detects malice at scale.

Here's an idea: instead of charging 30%, you should waive that if the dev team agrees to vet 5 other apps for you, over time, especially the open source ones.

> How does that work? Is the submission farmed out to a 3rd party as part of the verification process, and proactively checked? Or is it reactive, similar to a bug bounty?

Bug Bounty. Person finds vuln in popular app. Person submits vuln to Google. Vuln gets reported to developer. Person gets paid.

> Are there people out there making their living running apks in desktop simulators looking for issues?

Most of them use tools, I think. I don't know stats on any individual who is making bank off this but given four figure payouts per issue I could definitely believe somebody living in eastern europe or whatever is making bank on this.

> I always wondered about the economics of checking huge quantities of arbitrary code (well, bytecode) for vulnerabilities, even for a 30% cut (which is probably 0 for 99% of apps, right? I would expect a power law distro). Kinda sounds like Google solved this by running the apks through something like a CI/CD gauntlet and then...hoping for the best.

I'm not sure it is just hope. I don't know how that team works specifically, but I know that they aren't just saying "hey we hope it works" in their reviews with leadership.

> Here's an idea: instead of charging 30%, you should waive that if the dev team agrees to vet 5 other apps for you, over time, especially the open source ones.

If you think that Google's policy enforcement and support is a kafkaesque nightmare now, could you imagine if your app was booted off Play because some other devs working at some company you've never heard of decided your app was bad? How would Google evaluate the quality of these investigations? With only five apps you don't have enough volume to develop a reputation so Google would either be forced to repeat all of the investigations or simply have zero oversight over the process.

>could you imagine if your app was booted off Play because some other devs working at some company you've never heard of decided your app was bad?

I would assume they'd give a reason for booting the app, which could be verified by Google and the author. I would imagine the more likely error mode would be simply clicking "okay" without actually looking at the code at all. You know, like some devs do with code reviews!