Hacker News Reader

Comment by ziddoap | Hacker News Reader

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?

View on HN

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.

This could, of course, be an explanation. Except for the _stated fact_ that after they removed the batch import, they were still rejected.

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?

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/contact...

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.

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.

> 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.

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.

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)

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.

> 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?

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".

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.

>* 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.

> 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.

Yes, "considered", not "assumed and banned on the basis of". If I consider what the app could do and chose to accept that risk (hint: you do that every time you install a program on a desktop OS, which have basically no sandboxing and often auto-update), I should be able to use it. Google is doing the deciding here and that's not ok. "There's nothing stopping the devs from abusing this access in the future" is a reason to be careful, not to completely disallow a piece of software (which is what Google effectively did).

> Google is not forcing this app to call themselves "malware"

Many people on this very forum regularly claim that software that does things like upload your contacts to the cloud for no good reason should in fact be considered malware. An app that explicitly brands itself as privacy-friendly being forced to claim it does something that violates user privacy is largely comparable to being called malware.

Let's try this analogy again: imagine Signal needs to call itself "not actually encrypted messenger" because they could in theory push an update that sent messages unencrypted or even forwared them to the NSA - they have all the required permissions!

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

Yes.

Reply on news.ycombinator.com