3 ms·

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

> 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.
    - franga2000 4y ago
      > 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!

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.
  - franga2000 4y ago
    > 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!