4 ms·

This kind of incompetence makes me seriously doubt that Google is doing anything to more substantially review apps for deeper security issues, either statically

This kind of incompetence makes me seriously doubt that Google is doing anything to more substantially review apps for deeper security issues, either statically or at runtime. The asymmetry of effort in this situation is profound: consider that you spend all your time and effort writing a, long, complex, thoughtful message by hand (the app), taking hundreds or thousands of hours, but then they respond with machine generated message that cost them 10ms of computer time. The solution, I think, is obvious: Google needs a "zone defense" with the play store, a much larger (and expensive) staff, to do in-depth app reviews and be a stable, stateful relationship with the developer over time. This person would, in fact, become a 3rd party "expert" on a small set of apks and their contents, with a "feel" for what is changing over time, with the core mission of protecting users from malice, but working with devs, as a human being.

freedomben 5y ago
That sounds awesome to me, but if they were going to do that the cost of submitting an Android app (or the % take by Google on sale) would have to sky rocket to make it worth it. As someone who rejoices in small developers, I would hate to see that. I think it's ok to do automated review for round 1, but I would like to see a human field appeals. Over time I would also think that will help find edge cases and cracks in the automation so that it can be further improved. Edit: Based on other comments here, it sounds like that may be what Google is starting to do
UncleMeat 5y ago
> This kind of incompetence makes me seriously doubt that Google is doing anything to more substantially review apps for deeper security issues, either statically or at runtime. 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. > The solution, I think, is obvious: Google needs a "zone defense" with the play store, a much larger (and expensive) staff, to do in-depth app reviews and be a stable, stateful relationship with the developer over time. This person would, in fact, become a 3rd party "expert" on a small set of apks and their contents, with a "feel" for what is changing over time, with the core mission of protecting users from malice, but working with devs, as a human being. This sort of exists. Google pays external hackers who find vulns in popular apps via a rewards program. These don't need to be Google's apps. There may be other systems for top partners or specific kinds of apps (the org is big) but I'm not aware of anything personally. Expanding beyond a small subset of apps is challenging. Not only are there millions of apps, each app contains tens, hundreds, or even thousands of individual apks. The staff needed to have a concierge for each app would be absolutely freaking enormous, perhaps even larger than the number of people on the planet who actually have deep security expertise on the Android platform.
- 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.

freedomben 5y ago

That sounds awesome to me, but if they were going to do that the cost of submitting an Android app (or the % take by Google on sale) would have to sky rocket to make it worth it. As someone who rejoices in small developers, I would hate to see that. I think it's ok to do automated review for round 1, but I would like to see a human field appeals. Over time I would also think that will help find edge cases and cracks in the automation so that it can be further improved. Edit: Based on other comments here, it sounds like that may be what Google is starting to do

UncleMeat 5y ago

> This kind of incompetence makes me seriously doubt that Google is doing anything to more substantially review apps for deeper security issues, either statically or at runtime. 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. > The solution, I think, is obvious: Google needs a "zone defense" with the play store, a much larger (and expensive) staff, to do in-depth app reviews and be a stable, stateful relationship with the developer over time. This person would, in fact, become a 3rd party "expert" on a small set of apks and their contents, with a "feel" for what is changing over time, with the core mission of protecting users from malice, but working with devs, as a human being. This sort of exists. Google pays external hackers who find vulns in popular apps via a rewards program. These don't need to be Google's apps. There may be other systems for top partners or specific kinds of apps (the org is big) but I'm not aware of anything personally. Expanding beyond a small subset of apps is challenging. Not only are there millions of apps, each app contains tens, hundreds, or even thousands of individual apks. The staff needed to have a concierge for each app would be absolutely freaking enormous, perhaps even larger than the number of people on the planet who actually have deep security expertise on the Android platform.

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.