derek

I'm afraid there is no reason to suspect that ingesting higher-than-suggested doses of vitamins and minerals will make your penis larger. Even while passing the kidney stone.

I can absolutely sympathize with that. There aren't good resources for the uninitiated to get up to speed or which readily justify "this vs that". The goal of the documentation that does exist often has little to do with convincing the tech-savvy public anyway. Marketing and education of laymen isn't going to be the technical writer's forte.

I don't have time to answer all your questions as fully as they deserve but I'll start with one example from the security side, show how I establish a basic from-scratch understanding of that problem, and how I'm able to arrive at a reasonable conclusion about whether it matters or not.

Looking at the previously linked Android comparison table the secure NTP entry will be more straight forward to talk about. That's the

Secure connection to network time server?

entry in that table.

Here are search results for the same question from two different providers:

is secure network time protocol important?

DuckDuckGo: https://duckduckgo.com/&q=is+secure+network+time+protocol+important%3F

Kagi: https://kagi.com/search?q=is+secure+network+time+protocol+important%3F&r=us&sh=D_5b8AmhNdDFwIR62tc9pA

Checking a few of the top results I find the info on Baeldung's site the most accessible. https://www.baeldung.com/cs/ntp-security-authentication-synchronization

Sections 5, 6, and 7 are the most relevant to our discussion. In 5 we see that spoofing, man in the middle, and denial of service attacks are the primary concerns. 6 provides an overview of a secure vs insecure connection. 7 covers best practices and specifically addresses mitigating spoofing and man in the middle attacks.

Referencing the chart again we see that GrapheneOS addresses this and others, including LineageOS and stock Android, do not.

Digging into this further I searched the GrapheneOS FAQ for NTP and found relevant info in the Default Connections section: https://grapheneos.org/faq#default-connections

I searched the LineageOS wiki for similar info and couldn't find any. https://wiki.lineageos.org/

If I've missed some info on theIr wiki please let me know. I went searching for additional info on how LineageOS handles NTP to try and put this to bed but I couldn't find much. The long and short of it is that we can conclude a secure NTP implementation matters and without it we're vulnerable to attacks we otherwise would not be.

While searching I did run across this thread on the Privacy Guides forums that I'd like to share: https://discuss.privacyguides.net/t/is-lineage-os-as-private-as-graphene-os/30738/3

Kev nails it.

It can be as private as Graphene OS if no Google services are installed. Difference is that the former lacks a strong security model because of its unlocked bootloader.

If your threat model involves:

• Counter-forensics
• Sensitive professional work
• Malware exposure

You should consider installing Graphene OS instead. If you want the camera to work better, you can install GCam (Google’s default camera app) and revoke its network permissions.

Otherwise, Lineage OS is a great option for a secondary device, not a primary one.

I suggest malware exposure ought to be within everyone's threat model for, likely, their most used computing device. Couple that with the longer delays between full patches for LinearOS and GrapheneOS becomes a compelling choice.

The other question, asking what power Google has over you, has much more to do with "DeGoogling" and how Google Play services are implemented. For LineageOS, as you mentioned, Google Play services aren't implemented by default and aren't supported.

This is way ahead of alternatives in the same space, like /e/ or Calyx, but their DeGoogling efforts are minimal so they're still defaulting to Google's choices for Domain Name Services, Digital Rights Management, and GPS services. Is that the end of the world? No. You can change that with some effort and maintenance. On GrapheneOS it's already taken care of though.

If a LineageOS user doesn't put in that effort and maintain the changes then they're leaking a ton of useful info to Google by default. So the user doesn't have to worry about Google Play services but does have to worry about Google's data collection, fingerprinting, and influence.

I came across the following blog post a few years ago and it made clear to me how it could be that bad from DNS and GPS info alone. Michael is talking about Google DNS from a corporate Systems Admin perspective but it applies to individuals just the same.

https://www.michaelrinderle.com/2020/05/08/why-systems-administrators-should-stop-using-8-8-8-8-google-dns/

It's categorically better to deny Google this information entirely if possible.

Thanks for being interested and asking good questions. I hope my reply is helpful. <3

You're absolutely correct. Living in the core of the empire or within one of its beneficiaries affords certain advantages which are made inaccessible to those outside of those regions. Your best approach is likely assuming your mobile device is compromised and only conducting sensitive activity on an inexpensive laptop you can reasonably secure.

Some secure-by-default Linux OSes I'd recommend are:

Parrot Security OS https://parrotsec.org/

Tails OS https://tails.net/

Qube OS https://www.qubes-os.org/

These are listed from most user-friendly to least. Signal has a desktop client that I'd be comfortable using on any of those three platforms.

Neither LineageOS nor /e/OS are comparable alternatives. They're significantly less secure than stock Android.

"I don't want to support Google so I refuse to use their hardware with an OS which, by default, prevents Google from achieving their objectives. Instead I'll use insecure platforms that still give Google most of what they want."

Android and Chrome are independent from Google in the same way that AT&T is independent from the NSA. The reality is that Google does what they want with both projects. Their main line of business is surveillance and those projects facilitate their business goals. GrapheneOS is developed for the Pixel platform because of the tight integration with Android from the hardware up.

This has allowed the GOS project to build a modified OS which is stripped of the default tooling and dependencies that give Google power over the device and its user's digital ecosystem. The same cannot be said for any other project at the moment.

Using Google's hardware to deny them access to the reasons they developed and produced that hardware to begin with directly spits in their face. It's more effective to buy hardware from Google, or buy one of their devices second-hand from a trusted source, and then modify it to achieve our goals while denying our would-be owners their own than to continue capitulating to their brand of Surveillance Capitalism.

This position misses the point entirely and introduces personal risk for no benefit. Buy a used Pixel if it makes you feel better about it. Then you're upcycling.

Yeah, I've been watching this guy on youtube, pretty funny. I wonder if he's right about the Coast Guard being called Beach Boys.

Get a Pixel 8 or 9 and install GrapheneOS. The recent changes to AOSP aren't some death knell for the project. Even if it were: using GOS on an older Pixel for the next five years or so is going to be way safer than alternatives.

I'll grant that whether or not this matters to someone depends on their personal threat model. My counter argument is to gesture broadly at the state of things. If they think the computing device they use most often shouldn't be their most reasonably secured and trustworthy computer then I'm not sure there's much else to discuss on the topic.

I want to be able to recommend any of the Linux phone projects or even something like Murena's new partnership with HIROH but they don't solve the problems GrapheneOS does.

The best breakdown of current options I've found is here: https://eylenburg.github.io/android_comparison.htm

Fun fact: Eye of Newt supposedly refers to mustard seed!

Herbalists referred to plant parts as if they were animals parts for reasons I'm not yet educated enough to know off the top of my head. I like to think they just wanted to be innocently spooky.

😐😑🙄⬆️

Another consideration is that expertise in a domain highlights ignorance. I've known experts who refuse to dabble outside their expertise because they're keenly aware of how much they don't know and feel they'd be doing a disservice to the requester if they agreed to help out. Better to leave it to the right experts.

That's a certain kind of person. I'm not like that. I don't mind breaking things so long as their mine or it's agreed to up front. Some people are more anxious about these things though. I'd guess none of us know the fellow, so it's all speculative anyway, but it's possible this angle is the source of refusal.

Absolutely. VMs and Containers are the wise sysadmin's friends. Instead of rolling my own ip blocker I use Fail2Ban on public-facing machines. It's invaluable.

That sounds pretty good to me for self-hosted services you're running just for you and yours. The only addition I have on the DR front is implementing an off-site backup as well. I prefer restic for file-level backups, Proxmox Backup Server for image backups (clonezilla works in a pinch), and Backblaze B2 for off-site storage. They're reliable and reasonably priced. If a third party service isn't in the cards then get a second SSD and put it in a safety deposit box or bury it on the other side of town or something. Swap the two backup disks once a month.

The point is to make sure you're following the 3-2-1 principal. Three copies of your data. Two different storage mediums. One remote location (at least). If disaster strikes and your home disappears you want something to restore from rather than losing absolutely everything.

Extending your current set up to ship the external SSD's contents out to B2 would likely just be pointing rsync at your B2 bucket and scheduling a cron or systemd timer to run it.

After that if you're itching for more I'd suggest reading/watching some Red Team content like the stuff at hacker101 dot com and sans dot org. OWASP dot org is also building some neat educational tools. Getting a better understanding of the what and why around internet background noise and threat actor patterns is powerful.

You could also play around with Wazuh if you want to launch straight into the Blue Team weeds. Education of the attacking side is essential for us to be effective as defenders but deeper learning anywhere across the spectrum is always a good thing. Standing up a full blown SIEM XDR, for free, offers a lot of education.

P. S. I realize this is all tangential to your OP. I don't care for the grizzled killjoys who chime in with "that's dumb don't do that" or similar, offer little helpful insight, and trot off arrogantly over the horizon on their high horse. I wanted to be sure I offered actionable suggestions for improvement and was tangibly helpful.