I feel like we maybe just learned some kind of lesson about malicious code being included in FOSS projects on blind faith that someone out there would catch it if it was there.
What are you missing? When Google has access to the source code, they have the ultimate most effective and simultaneously easy way to verify the criteria is met. Of course that’s relevant to the discussion. It’s how you know what the software does. Only closed-source projects have a problem demonstrating that they’ve satisfied the criteria.
FOSS isn’t magic. Reviewing the source code doesn’t guarantee that the version you get matches the code you were provided. You unconditionally should not get any exemptions to store policy because your code is open source. That’s a terrible idea.
Having actual written policies and meeting other criteria are the rules for a reason. If you’re unwilling to follow them, not being on the play store is 100% your fault. It’s not Google being mean.
FOSS isn’t magic. Reviewing the source code doesn’t guarantee that the version you get matches the code you were provided. You unconditionally should not get any exemptions to store policy because your code is open source. That’s a terrible idea.
No one has suggested exemptions. Otherwise you need to quote where you get that idea from. You’re not grasping the fact that code enables criteria to be verified. It therefore needs no exemption.
The terrible idea we are grappling with is the idea to not review source code that is available. If the code does not match the binary, that is Google’s problem. Google is the repository and has the sole responsibility for either ensuring reproducable builds are in play (to the extent that they care) or compiling it themselves. But I doubt Google genuinely cares as the Playstore is proven to have a quite poor quality standard relative to other repositories.
Having actual written policies and meeting other criteria are the rules for a reason.
Those policies are not above criticism. If Google’s policies fail to include code reviews as verification that criteria is satisfied, that’s on Google and they have no expectation of not being condemned for their incompetent policy.
Yes, you are. The issue they’re complaining about is that they’re being held to additional standards because they ask for a sensitive permission. They absolutely should be.
Being FOSS should literally not be considered in any way at any point in the app acceptance process. It’s terrible policy that’s much worse than the policy that you’re complaining about.
The issue they’re complaining about is that they’re being held to additional standards because they ask for a sensitive permission.
That’s not Snikket’s complaint. Snikket naturally satisfies the standards at hand because they do not export address book data, so they have no reason to object to the standards Google is failing to verify. Their complaint is rightfully about Google’s incompetence in evaluating their compliance. It’s clear from Snikket’s account what a shit show it is at Google who failed copious times to evaluate their software.
There’s nothing more terrible in the position of a software repository than the incompetence of neglecting to review code as part of the acceptance process. I can’t think of a more foolish policy than to ignore the code of software for which you are trying to endorse the quality of.
B. Code review takes a very large amount of highly qualified man hours to not work.
Not if a machine does it. And even if they use humans, it takes even more man hours to do the alternative dynamic analysis and traffic analysis. Code review saves countless man hours even if done 100% manually by humans.
C. Requiring review of proprietary code exposes Google to a crazy amount of antitrust and IP liability. Again, to not work.
Not applicable to FOSS code.
Code review doesn’t happen because it’s a laughably stupid idea that has virtually no chance of being beneficial in any way. It’s not an oversight.
Code reviews happen at every organisation I have worked for to catch unwanted code before deployment and testing. The reason we review code before testing is because it’s cheaper to review code than to test it. It’s laughably stupid to think code review doesn’t work only to then to spend more money on verification tests.
An organization reviewing its own code is not the same, or similar in any way, to an organization reviewing a large volume of external code for malicious intent. And it doesn’t work for a wide variety of reasons (including the one I already gave you that binaries don’t provide you any guarantees that they’re from the source). Onboarding is universally slow because new people take weeks to months to actually meaningfully understand big projects.
Again, you’re asking for FOSS code to get some special treatment and bypass the requirements already in place. It’s completely absurd, because every single one of those tests would still be unconditionally mandatory to get any kind of actual confidence in security. Choosing to skip them because someone in India skimmed the code would be way past gross negligence.
Being FOSS absolutely should not get you a pass on the entirely reasonable policy that touching the permission requires additional criteria be met.
It’s completely irrelevant to the discussion.
I feel like we maybe just learned some kind of lesson about malicious code being included in FOSS projects on blind faith that someone out there would catch it if it was there.
What are you missing? When Google has access to the source code, they have the ultimate most effective and simultaneously easy way to verify the criteria is met. Of course that’s relevant to the discussion. It’s how you know what the software does. Only closed-source projects have a problem demonstrating that they’ve satisfied the criteria.
FOSS isn’t magic. Reviewing the source code doesn’t guarantee that the version you get matches the code you were provided. You unconditionally should not get any exemptions to store policy because your code is open source. That’s a terrible idea.
Having actual written policies and meeting other criteria are the rules for a reason. If you’re unwilling to follow them, not being on the play store is 100% your fault. It’s not Google being mean.
No one has suggested exemptions. Otherwise you need to quote where you get that idea from. You’re not grasping the fact that code enables criteria to be verified. It therefore needs no exemption.
The terrible idea we are grappling with is the idea to not review source code that is available. If the code does not match the binary, that is Google’s problem. Google is the repository and has the sole responsibility for either ensuring reproducable builds are in play (to the extent that they care) or compiling it themselves. But I doubt Google genuinely cares as the Playstore is proven to have a quite poor quality standard relative to other repositories.
Those policies are not above criticism. If Google’s policies fail to include code reviews as verification that criteria is satisfied, that’s on Google and they have no expectation of not being condemned for their incompetent policy.
Yes, you are. The issue they’re complaining about is that they’re being held to additional standards because they ask for a sensitive permission. They absolutely should be.
Being FOSS should literally not be considered in any way at any point in the app acceptance process. It’s terrible policy that’s much worse than the policy that you’re complaining about.
That’s not Snikket’s complaint. Snikket naturally satisfies the standards at hand because they do not export address book data, so they have no reason to object to the standards Google is failing to verify. Their complaint is rightfully about Google’s incompetence in evaluating their compliance. It’s clear from Snikket’s account what a shit show it is at Google who failed copious times to evaluate their software.
There’s nothing more terrible in the position of a software repository than the incompetence of neglecting to review code as part of the acceptance process. I can’t think of a more foolish policy than to ignore the code of software for which you are trying to endorse the quality of.
A. Code review doesn’t work.
B. Code review takes a very large amount of highly qualified man hours to not work.
C. Requiring review of proprietary code exposes Google to a crazy amount of antitrust and IP liability. Again, to not work.
Code review doesn’t happen because it’s a laughably stupid idea that has virtually no chance of being beneficial in any way. It’s not an oversight.
You’re doing it wrong.
Not if a machine does it. And even if they use humans, it takes even more man hours to do the alternative dynamic analysis and traffic analysis. Code review saves countless man hours even if done 100% manually by humans.
Not applicable to FOSS code.
Code reviews happen at every organisation I have worked for to catch unwanted code before deployment and testing. The reason we review code before testing is because it’s cheaper to review code than to test it. It’s laughably stupid to think code review doesn’t work only to then to spend more money on verification tests.
An organization reviewing its own code is not the same, or similar in any way, to an organization reviewing a large volume of external code for malicious intent. And it doesn’t work for a wide variety of reasons (including the one I already gave you that binaries don’t provide you any guarantees that they’re from the source). Onboarding is universally slow because new people take weeks to months to actually meaningfully understand big projects.
Again, you’re asking for FOSS code to get some special treatment and bypass the requirements already in place. It’s completely absurd, because every single one of those tests would still be unconditionally mandatory to get any kind of actual confidence in security. Choosing to skip them because someone in India skimmed the code would be way past gross negligence.