The article says that Pegasus is installed via a zero-day (presumably via a phishing attack or similar). I love opensource software, but it is not a magic bullet that stops the likes of zero day attacks. In other words, using a fully opensource stack would not prevent something like Pegasus if they exploited a zero day.

Purchasing phones which ensure frequent software patches for a number of years is a far better tactic IMHO. For example I recently purchased a Nokia X20 (https://www.clove.co.uk/products/nokia-x20) which has a promised 3 years of OS upgrades...something I've not seen by other manufacturers.

Partially true, but moving away from proprietary hardware and software and especially cloud services would still greatly reduce the attack surface, and is something I committed to fully half a year ago by purging Google/Play services from my phone, having already wiped Windows off my drive five years ago, replacing it with Arch.

This still wouldn't protect me from a targeted surveillance attempt like Pegasus, but it does protect me from automated mass surveillance in the cloud, and at least partially reduces the attack surface, by getting rid of unvetted, unreviewable, backdoored proprietary software.

0 regrets, only privacy vibes every since.

The current state is not great; I keep trying out the distros for my pinephone but everything is pretty much still unusable. Apps crash a lot, including the window manager and there are a very large amount of bugs.

The hardware seems fine, but, as said above, it seems that critical hardware (and software for that hardware) is closed.

What is great is: replaceable battery and dipswitches to physically turn on and off every module in the phone.

So you don't trust large US tech companies. Fair.

But why do you expect people can trust a group of anonymous developers building open source smartphones?

Isn't that a large part of the open-source nature? Audit the code or hardware designs yourself, determine their trustworthiness from that. It's much harder to trust something when you can't examine the inner workings of it.

Ok thanks, I get that. But how many people can do that? Like 0.001% of the population?

I think its fair to call it 0%. Auditing a large, modern code base is going to be impossible for a single person. For example, the Linux kernel is 27.8M lines of code (as of Jan 2020, [0]). Yes, a lot of that code is for drivers you wont use, or platforms you aren't running on. But still, no one person is going to be able to get through all of it with enough attention to detail to notice things like subtle race conditions, especially if they were inserted maliciously.

[0] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Gi...

How many people can authenticate a dollar bill? How many people can validate a cryptographic signature? How many people can direct a blockbuster action movie?

The point is, right now, nobody can audit these things. Once someone -- anyone! -- can, everyone else can benefit.

There's also the matter of traceability.

Even if there is no direct audit of the code, once a vulnerability is discovered it can be traced back to the person(s) who introduced it.

With a closed system, only the owner of the source code history can do that. With open source, any person in the world can, and can start a discussion to understand whether it was malicious or not, if the person(s) should be banned from pushing code, new code security standards to be adopted, etc. You lean on the world's expertise at that point.

Bad things happen. It's important to have the ability to understand why and mitigate for the future.

Nope, it can be traced back to a random nickname on the Internet, using a computer somewhere in the globe.

That may be so, but it's usually been through code reviews, pull requests and whatnot - which means a maintainer somewhere has approved that code.

In any case, "a random nickname on the Internet, using a computer somewhere in the globe" is a lot more information than none.

Finding out that that's the case for a given project is part of traceability.

How do ensure it wasn't a malicious maintainer?

That information is meaningless if traces back to an empty room.

If the project has a malicious maintainer, it's easier to find out if it's in the open - and either forcing change or not using the project at all. It's impossible to do that when you have no access to that information in the first place.

It's not perfect but it's something vs nothing. I'll take something every time.

How do you track down a malicious maintainer, introducing a back door slowly during one year long, a little change at a time, given how long CVEs in OpenSSL have been unnoticed as example?

I guess you have never had commit rights to any Linux distribution or such?

You don't get commit rights as a random person, so yes, a commit can usually be traced back to a person. Sure, the committer could have received a patch from a unknown person, but then he's still responsible for the commit.

I guess you are a security expert that knows how every single FOSS project that might be used as dependency works.

That's not what I tried to say. It's up to you as a user to make due diligence and make an informed decision if you want to use the software or not.

Any serious project would have some form of web of trust and know who has commit rights. It's up to you to decide if you trust their web of trust.

I guess from your comments that you are not actually interested in contributing to the discussion since you just sprout single line comments with no information at all.

I contribute with experience instead of FOSS ideology absent from how things actually work.

No, you throw out nonsense single line sentences that say and contribute nothing.

>How many people can authenticate a dollar bill? [...] nobody can audit these things.

USGOV has a pretty comprehensive guide on how to validate them:

https://www.uscurrency.gov/sites/default/files/downloadable-...

There is also plenty of documentation and books to learn coding and start auditing if you want to.

Fake validation is less like coding as to catch a really well made fake you would need years of experience seeing all sorts of fakes , while coding needs only experience to see what is good code to able to catch most issues

> coding needs only experience to see what is good code to able to catch most issues

If that were true, the software industry would have a much smaller problem re: bugs and errors than they currently do.

Less bugs would be there if the industry wanted it and paid for it.

Sadly the problem is good enough is how the industry sees everything, constant cost cutting , off shoring or replacing senior talent with fresh graduates , inadequate focus on security, debt is all too common, unless/until something affects bottomline there is no pressure.

Please note the entire absence of the dollar bill from that document.

> Please note the entire absence of the dollar bill from that document.

A fair point. I took "dollar bill" to be the generic "US currency" rather than specifically "the $1 bill". But this page covers everything from $1 to $100 (although it seems the $1 and $2 have barely any.)

https://www.uscurrency.gov/denominations/

You clearly don’t understand the transparency and power of open source code. Fair.

Helping me to understand would be appreciated and in the spirit of HN. Mocking me? Not so much.

Open source is like Open courts or Right to Information.

Just like anything going in secrets courts is bad for judicial integrity, or RTI laws can help keep government somewhat honest, Open source can help like any other transparency framework.

Just transparency is not a magic solution , open source alone is not going to solve everything. It is just one among many other controls we need.