3 ms·
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
by advael 5y ago
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.
- UncleMeat 5y ago> 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.
- eproxus 5y agoThey 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.
- UncleMeat 5y agoA false positive is "rejecting an app because of a behavior that isn't actually present." You've got them backwards.