4 ms·

I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit? If Google approved it as-is, could the developers add a

I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit? If Google approved it as-is, could the developers add a few lines as an "update" and skip over the full review process? Seems like the ruling is being made on what can be done with the current permissions, rather than what is being done. If that's the case, I sympathize with the devs but I think I support the position Google is taking there. Off-topic comment: I use NoScript, and the entire text of the article renders for a half second before disappearing and for some inexplicable reason requiring JS to be enabled. If you can render it for that half second, why hide it? Why force me to use JS when you just proved that you can render it without?

Marsymars 4y ago
> I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit? Yes.
jsnell 4y ago
It does sound like they're batch-copying the entire contact book into their app at startup, rather than using the Android contact picker. The static analysis problem of determining whether there is / isn't a batch import seems a lot easier than determining with certainty what happens with the contacts after they were saved to disk. Though the article doesn't actually show any screenshots from the review emails, but just paraphrases them, so we don't even know that their interpretation of the rejection reason is correct.
- TheNorthman 4y ago
  This could, of course, be an explanation. Except for the _stated fact_ that after they removed the batch import, they were still rejected.
  - jefftk 4y ago
    I don't see where they say they removed batch import? Just that they removed caching. I don't think they're using the default contact picker?
    - tadfisher 4y ago
      Just to clarify a few things: "Batch import" is querying the system Contacts Provider [0] with essentially a "SELECT *" query. This requires the READ_CONTACTS permission, which is granted by the user via a runtime permissions dialog. "Batch import" under this definition includes the use case of displaying the contacts list in the app's UI, regardless of whether that list is cached offline or uploaded somewhere. The "contact picker" is an Intent the app sends to the system contacts application, which then returns a single contact. The UI is handled by the contacts app, filtering options are limited/non-existent, and there's no way to display app-specific metadata. It also requires no permissions. [0]: https://developer.android.com/guide/topics/providers/contacts-provider https://developer.android.com/guide/topics/providers/contact...
exprez135 4y ago
Re: the off-topic comment: Same here, but I noticed that Firefox's reader button was still appearing. I was able to read with that without loading the scripts after all.
londons_explore 4y ago
The code review is done 'black box' - ie. the reviewer doesn't have access to the code. All the reviewer can see is what permissions the app has. They see internet permission and contacts permission, and have to assume that evil code might be uploading the contacts to the internet. There isn't really any other way to do it - even a thorough code audit (a process that would take months for just a single app) would be unlikely to uncover a well hidden flaw that is intended to allow an evil app developer to steal contacts of users only after the app passes the review process.
- capitalsigma 4y ago
  It seems most likely that there is some static analysis being done to the binary here, or maybe some instrumented JVM that "poisons" bytes that come from the contact list and traces them to see if they ever land on disk or sent on the network. Clearly Google doesn't ban every app with that combination of permissions.
- franga2000 4y ago
  > There isn't really any other way to do it There is, it's called balancing the probabilities. What's more likely - that someone started a company, developed a full-featured VoIP app, set up all the infrastructure to provide their service, made the app open source and established themselves in the market, all just to secretly harvest people's contact lists.......or are they telling the truth and no data is being uploaded? These are all things Google can verify, they just don't want to.
  - chiggsy 4y ago
    One founder leaves and the replacement has a different mandate and/or worldview. Happens all the time. You should assume any app requiring contacts and access to photos is exfiltrating them.
    - franga2000 4y ago
      You may choose to assume that, or you may choose to believe them due to various other factors. The choice is and should be yours, not Google's. And even if you do choose to assume that, you're aware it's just an assumption, not a fact. But if Google does the assuming for you and gives you their assumption as a fact, you don't have that very important context. Google is more than welcome to add a disclaimer such as "no claims in the app description have been verified and may change at any time" to all apps - I'd even welcome it. But don't make us lie to our users! (I'm not affiliated with the posting company, but I've had a similar issue in an app with location permissions for use on a simple map)
GordonS 4y ago
> Seems like the ruling is being made on what can be done with the current permissions, rather than what is being done. If that's the case, I sympathize with the devs but I think I support the position Google is taking there. Not sure if I'm missing something here, but the "access contacts" permission exists for a reason, and plenty of apps use it - how can it be justified that Google will arbitrarily ban this app, but allow others, even though the authors in this case are clearly willing to do anything to prove no bad intent?
- ziddoap 4y ago
  I'm not arguing that it's justified here but not elsewhere. Selective enforcement of rules is one of my biggest gripes with companies. I'm also not arguing that applications shouldn't be able to use contact permissions, obviously some applications will need it. But I do think that if you need X permission, you should be evaluated against everything that the permission grants and not just "we promise not to use Y part of X permission".
  - franga2000 4y ago
    This isn't a case of "not using every part of the permission" (like it often is with the location permission, which you need to scan wifi an bluetooth). It's a case of asserting that an app does something just because it technically could, refusing to listen to any evidence to the contrary and demanding they put this nonexistent anti-feature in the description. It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access.
    - ziddoap 4y ago
      >* It's a case of asserting that an app does something just because it technically could* Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice. >It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access. Not even close. Both your forced analogies involve something inherently negative ("ransomware", "for stalkers"). Google is not forcing this app to call themselves "malware" or anything like the situation in your examples, nor is Google asking the company to rename their application.

Marsymars 4y ago

> I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit? Yes.

jsnell 4y ago

It does sound like they're batch-copying the entire contact book into their app at startup, rather than using the Android contact picker. The static analysis problem of determining whether there is / isn't a batch import seems a lot easier than determining with certainty what happens with the contacts after they were saved to disk. Though the article doesn't actually show any screenshots from the review emails, but just paraphrases them, so we don't even know that their interpretation of the rejection reason is correct.

TheNorthman 4y ago
This could, of course, be an explanation. Except for the _stated fact_ that after they removed the batch import, they were still rejected.
- jefftk 4y ago
  I don't see where they say they removed batch import? Just that they removed caching. I don't think they're using the default contact picker?
  - tadfisher 4y ago
    Just to clarify a few things: "Batch import" is querying the system Contacts Provider [0] with essentially a "SELECT *" query. This requires the READ_CONTACTS permission, which is granted by the user via a runtime permissions dialog. "Batch import" under this definition includes the use case of displaying the contacts list in the app's UI, regardless of whether that list is cached offline or uploaded somewhere. The "contact picker" is an Intent the app sends to the system contacts application, which then returns a single contact. The UI is handled by the contacts app, filtering options are limited/non-existent, and there's no way to display app-specific metadata. It also requires no permissions. [0]: https://developer.android.com/guide/topics/providers/contacts-provider https://developer.android.com/guide/topics/providers/contact...

exprez135 4y ago

Re: the off-topic comment: Same here, but I noticed that Firefox's reader button was still appearing. I was able to read with that without loading the scripts after all.

londons_explore 4y ago

The code review is done 'black box' - ie. the reviewer doesn't have access to the code. All the reviewer can see is what permissions the app has. They see internet permission and contacts permission, and have to assume that evil code might be uploading the contacts to the internet. There isn't really any other way to do it - even a thorough code audit (a process that would take months for just a single app) would be unlikely to uncover a well hidden flaw that is intended to allow an evil app developer to steal contacts of users only after the app passes the review process.

capitalsigma 4y ago
It seems most likely that there is some static analysis being done to the binary here, or maybe some instrumented JVM that "poisons" bytes that come from the contact list and traces them to see if they ever land on disk or sent on the network. Clearly Google doesn't ban every app with that combination of permissions.
franga2000 4y ago
> There isn't really any other way to do it There is, it's called balancing the probabilities. What's more likely - that someone started a company, developed a full-featured VoIP app, set up all the infrastructure to provide their service, made the app open source and established themselves in the market, all just to secretly harvest people's contact lists.......or are they telling the truth and no data is being uploaded? These are all things Google can verify, they just don't want to.
- chiggsy 4y ago
  One founder leaves and the replacement has a different mandate and/or worldview. Happens all the time. You should assume any app requiring contacts and access to photos is exfiltrating them.
  - franga2000 4y ago
    You may choose to assume that, or you may choose to believe them due to various other factors. The choice is and should be yours, not Google's. And even if you do choose to assume that, you're aware it's just an assumption, not a fact. But if Google does the assuming for you and gives you their assumption as a fact, you don't have that very important context. Google is more than welcome to add a disclaimer such as "no claims in the app description have been verified and may change at any time" to all apps - I'd even welcome it. But don't make us lie to our users! (I'm not affiliated with the posting company, but I've had a similar issue in an app with location permissions for use on a simple map)

GordonS 4y ago

> Seems like the ruling is being made on what can be done with the current permissions, rather than what is being done. If that's the case, I sympathize with the devs but I think I support the position Google is taking there. Not sure if I'm missing something here, but the "access contacts" permission exists for a reason, and plenty of apps use it - how can it be justified that Google will arbitrarily ban this app, but allow others, even though the authors in this case are clearly willing to do anything to prove no bad intent?

ziddoap 4y ago
I'm not arguing that it's justified here but not elsewhere. Selective enforcement of rules is one of my biggest gripes with companies. I'm also not arguing that applications shouldn't be able to use contact permissions, obviously some applications will need it. But I do think that if you need X permission, you should be evaluated against everything that the permission grants and not just "we promise not to use Y part of X permission".
- franga2000 4y ago
  This isn't a case of "not using every part of the permission" (like it often is with the location permission, which you need to scan wifi an bluetooth). It's a case of asserting that an app does something just because it technically could, refusing to listen to any evidence to the contrary and demanding they put this nonexistent anti-feature in the description. It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access.
  - ziddoap 4y ago
    >* It's a case of asserting that an app does something just because it technically could* Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice. >It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access. Not even close. Both your forced analogies involve something inherently negative ("ransomware", "for stalkers"). Google is not forcing this app to call themselves "malware" or anything like the situation in your examples, nor is Google asking the company to rename their application.