A reputation has to be earned again and again.

Maybe your threat model can tolerate an "oopsie woopsie". Politically exposed persons probably cannot.

If you don't personally write the software stack on your devices, at some point you have to trust a third party.

I would trust a company more if their random features sending data are opt-in.

A non-advertized feature, which is not independently verified, which about image contents? I would be prefer independent verification of their claims.

Agreed, but surely you see a difference between an open source implementation that is out for audit by anyone, and a closed source implementation that is kept under lock & key? They could both be compromised intentionally or unintentionally, but IMHO one shows a lot more good faith than the other.

No. That’s your bias as a nerd. There are countless well-publicised examples of ‘many eyeballs’ not being remotely as effective as nerds make it out to be.

can you provide a relevant example for this context?

That was an entire body of research at the University of Minnesota and the “hypocrite commits” weren’t found until the authors pointed people to them.

https://www.theverge.com/2021/4/30/22410164/linux-kernel-uni...

How long did the log4j exist?

https://www.csoonline.com/article/571797/the-apache-log4j-vu...

What was the other package that had the mysterious .?

And yet they were found. How many such exploits lurk unexamined in proprietary codebases?

yet you say this like Apple or Google or Microsoft has never released an update to address a security vuln

Apple[1], Google[2], and Microsoft[3] you say?

You say this as if being shamed into patching the occasional vuln is equivalent to security best practices.

Open code which can be independently audited is only a baseline for trustworthy code. A baseline none of those three meet. And one which by itself is insufficient to counter a reflections on trusting trust style attack. For that you need open code, diverse open build toolchains, and reproducible builds. None of which is being done by those three.

Are you getting your ideas about security from the marketing department?

1: https://arstechnica.com/security/2024/03/hackers-can-extract... 2: https://www.wired.com/story/google-android-pixel-showcase-vu... 3: https://blog.morphisec.com/5-ntlm-vulnerabilities-unpatched-...

Go ahead and put that cup of kool-aid down for a minute. There are so so many OSS packages out there that have never been audited? Why not? Because people have better things to do. How many packages have you audited? Personally, I don't have the skillz to do that. The people that do expect to be compensated for their efforts. That's why so many OSS packges have vulns that go unnoticed until after they are exploited, which is the same thing as closed source.

OSS is not the panacea that everyone touts it to be.

> There are so so many OSS packages out there that have never been audited? Why not? Because people have better things to do.

I'm not aware of any major open source projects that haven't experienced some level of auditing. Coverity alone scans everything you're likely to find in a distribution like Debian or Fedora: https://scan.coverity.com/o/oss_success_stories

> How many packages have you audited?

Several on which I depend. And I'm just one pair of eyeballs.

> Personally, I don't have the skillz to do that.

Then why are you commenting about it?

> OSS is not the panacea that everyone touts it to be.

I don't know who's touting it as a panacea, seems like a strawman you've erected. It's a necessary pre-requisite without which best practices aren't possible or verifiable.

The developer-to-user trust required in the context of open-source software is substantially less than in proprietary software. this much is evident.