4 ms·

Unfortunately, the number of people qualified and with the time to do a source code review of something as complex as a browser, is very small. For the vast ma

Unfortunately, the number of people qualified and with the time to do a source code review of something as complex as a browser, is very small. For the vast majority of users that's not a realistic prospect...

jedimind 5y ago
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 5y 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 5y 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 5y 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 5y 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 :)
daenz 5y ago
Not only that, but review every single commit forever. It's just not realistic.

jedimind 5y ago

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 5y 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 5y 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 5y 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 5y 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 :)

daenz 5y ago

Not only that, but review every single commit forever. It's just not realistic.