3 ms·

So you're saying that either way he has to trust someone. Then why not trust a company which at least open sources their code so anyone who has an interest in a

So you're saying that either way he has to trust someone. Then why not trust a company which at least open sources their code so anyone who has an interest in auditing the software can do so? (or have experts audit it for them,[who they also need to trust]) Yet people seem to trust google without batting an eye? "Google fired dozens of employees from 2018 to 2020 for accessing users' personal data." https://www.businessinsider.com/google-fired-employees-abusing-user-data-sharing-personal-info-vice-2021-8 https://www.businessinsider.com/google-fired-employees-abusi...

fsflover 4y ago
> either way he has to trust someone. Then why not trust a company which at least open sources their code Because the alternative is to trust a company which open sources their code _and_ a lot of security researchers regularly verify the code. > Yet people seem to trust google without batting an eye There are always people who believe in wrong things.
charcircuit 4y ago
I'm not sure what you expect Google to do? Permission to access personal data was limited to a small number of Google employees and when they abused their power they were fired. Do you want them to have some sort of AI that guesses the intent of looking at personal data?
daenz 4y ago
Trust in the original authors' code is only half of the attack surface. The other half is trust that no future contributors are malicious. Is the project more capable than Google in ensuring that malicious code can't land in the code base? I think the answer is clearly no.
raesene9 4y ago
So (like everything in security) it depends on your threat model. Open source has significant advantages over closed source, from the perspective of allowing the possibility of review (although that can be a false sense of security as we've seen several bugs in high profile projects live for decades) Where closed source might work better is where you are a large company with a smaller supplier. There you can use contractual controls to require a level of review to be done alongside other controls and have meaningful financial penalties if those requirements are not met. At the moment honestly the idea of fully trusting any large project seems like a tricky one as most projects/products are comprised of large quantities of 3rd party open source libraries, which are trusted. Whilst there's work to address that (e.g. the OpenSSF) there's a looong way to go. That's why defence-in-depth/segregation/detective controls are so important, relying on any one control is likely not to end well :) As to trusting Google, again threat model. I have a gmail account, could a google staff member access that? yep they could. Do I think I'm likely to be a target for that, not really :)

fsflover 4y ago

> either way he has to trust someone. Then why not trust a company which at least open sources their code Because the alternative is to trust a company which open sources their code _and_ a lot of security researchers regularly verify the code. > Yet people seem to trust google without batting an eye There are always people who believe in wrong things.

charcircuit 4y ago

I'm not sure what you expect Google to do? Permission to access personal data was limited to a small number of Google employees and when they abused their power they were fired. Do you want them to have some sort of AI that guesses the intent of looking at personal data?

daenz 4y ago

Trust in the original authors' code is only half of the attack surface. The other half is trust that no future contributors are malicious. Is the project more capable than Google in ensuring that malicious code can't land in the code base? I think the answer is clearly no.

raesene9 4y ago

So (like everything in security) it depends on your threat model. Open source has significant advantages over closed source, from the perspective of allowing the possibility of review (although that can be a false sense of security as we've seen several bugs in high profile projects live for decades) Where closed source might work better is where you are a large company with a smaller supplier. There you can use contractual controls to require a level of review to be done alongside other controls and have meaningful financial penalties if those requirements are not met. At the moment honestly the idea of fully trusting any large project seems like a tricky one as most projects/products are comprised of large quantities of 3rd party open source libraries, which are trusted. Whilst there's work to address that (e.g. the OpenSSF) there's a looong way to go. That's why defence-in-depth/segregation/detective controls are so important, relying on any one control is likely not to end well :) As to trusting Google, again threat model. I have a gmail account, could a google staff member access that? yep they could. Do I think I'm likely to be a target for that, not really :)