Love the idea - I wonder what I can use in New Zealand though - these things can't be shipped to NZ (Note I'm not surprised by this fact, I didn't expect NZ to let in random loads of mosquito killing bacteria)
I've seen plenty of smart phone photos on walls. Heaps.
I get the author knows what he's talking about/looking at, but most of us don't. I couldn't tell you which of those was iPhone vs Expensive Camera if you didn't tell me. Maybe I could guess but I'd have to examine.
This is the same as me being incredulous that the author has (made up example) a $20 cheap router his ISP gave him vs my lovingly handcrafted config on my home VyOS router.
Both work for you since you have no idea about actual photography. The second the article loaded on my small screen and I knew it was iphone vs real camera, without seeing description I knew photo on the left was from iphone.
Apple is 'famous' for at least a decade to (by default and basically nobody turns it off) overdo saturation towards red spectrum so that every single photo looks like its taken in golden hour (last hour before sunset). Every single one. Skin tones are affected correspondingly, looking artificial. You may not see it, its glaringly obvious to anybody who even scratched surface of photography (I never got deeper and still).
I get it, people like that 'instagram' look, but when its coming from all directions it loses all beauty and its just plasticky looking people.
Apple has some properly good hardware (and corresponding sw processing), they didn't have to resort to overdoing it so much (also very aggressively removing any skin blemishes and moles which all goes back to above). At the end, apple photos and people on them look too artificial. If you like it as such that's fine, but it doesn't represent reality, at least far less than other phones and proper camera photography.
Well there's a middle ground - Sublime Text isn't free but it's fantastic and isn't sending back all my code/work to the Chinese Government. Sorry, "Telemetry"
And the other side of the middle ground, Grafana being AGPL but requiring you to disable 4 analytics flags, 1 gravatar flag, and (I think) one of their default dashboards was also fetching news from a Grafana URL.
Hasn't this been common knowledge for ~15 years? In NZ there are laws to stop this, but the retailers just set their pricing high/low on the shoulder dates so as not to fall foul of the law.
It's at least 5 years older, it's not 1.0 yet, and it seems to be still under heavy development. For example compression was only added in 2022 and people reported severe performance issues / high RAM usage with larger backups only a few years ago.
Fair point though, both have enough of a user base that they could be considered safe at this point.
Right? I got his email too and man, I love what he does, I'm glad he's recovering from his illness etc. I've donated many times. But it's insane for him to think this was targeted. This was some bot/AI gone rogue. Or similar.
If someone wants to take you DOWN they will. And not by downloading a bunch of a files a heap.
"...and upon reaching for a hand towel I realized that the motif on it was not a diagonal pattern of dog bones but without doubt actually row after slanted row of penises, 100%"
I agree with you fully that mixing up kernel hardening and userspace hardening is one thing, but to suggest this little repo: https://github.com/Kicksecure/security-misc offers the same level of kernel hardening as grsecurity is probably the funniest thing I've read today.
To start with, some of the protections in grsecurity (specifically PaX) offer protections that apply to userspace - specifically MPROTECT and PAGEEXEC. Then there's the many kernel level protections:
KERNEXEC
The 3 different ASLR options (yes, vanilla linux has some watered down versions of these)
Then there's all the options that your little github repo has nothing the eqivilent of (to be fair vanilla linux HAS backported some of these):
[ ] Sanitize all freed memory
[ ] Sanitize kernel stack
[ ] Prevent invalid userland pointer dereference
[ ] Prevent various kernel object reference counter overflows
[ ] Harden memory copies between kernel and userland
[ ] Automatically constify eligible static objects
[ ] Report code regions instrumented for writing to constified data
[ ] Automatically constify eligible allocated objects
[ ] Prevent various integer overflows in function size parameters
[ ] Increase coverage of size overflow checking
[ ] Log missing size overflow hash table entries
[ ] Free more kernel memory after init
[ ] Free more kernel memory after init (verbose mode)
[ ] Generate some entropy during boot and runtime
[ ] Prevent code reuse attacks
[ ] Forward edge defense (deterministic)
└─ Forward edge defense instrumentation method (callabort)
[ ] Backward edge defense (deterministic)
[ ] Backward edge defense (probabilistic)
[ ] Protect kernel stacks from each other
[ ] Report nolocal transformations
[ ] Automatically protect kernel code vulnerable to Spectre v1
[ ] Protect more kernel code vulnerable to Spectre v1
[ ] Automatically protect kernel code vulnerable to Spectre v4
[ ] Protect more kernel code vulnerable to Spectre v4
[ ] Report code found to be potentially vulnerable to Spectre v1/v4
[ ] Convert k\*alloc allocations into their own slabs
[ ] Report autoslab decisions
[ ] Report some potential NULL pointer dereferences
[ ] Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port
[ ] Disable privileged I/O
[ ] Randomize addresses of critical kernel objects
[ ] Harden BPF interpreter
[ ] Disable unprivileged PERF_EVENTS usage by default
[ ] Insert random gaps between thread stacks
[ ] Harden ASLR against information leaks and entropy reduction
[ ] Deter exploit bruteforcing
[ ] Hide kernel symbols
[ ] Randomize layout of sensitive kernel structures
[ ] Use cacheline-aware structure randomization
[ ] Active kernel exploit response
[ ] Dmesg(8) restriction
[ ] Deter ptrace-based process snooping
[ ] Require read access to ptrace sensitive binaries
[ ] Enforce consistent multithreaded privileges
[ ] Disallow access to overly-permissive IPC objects
[ ] Disallow unprivileged use of command injection
[ ] Disable ability of suid root apps to execute unsafe files
[ ] Auto-enable Spectre mitigations for suid-like applications
[ ] Trusted Path Execution (TPE)
I've only grabbed half the options that grsecurity has available as options to turn on, but you get the idea.
Later version of the grsecurity patch also offer kernseal - https://grsecurity.net/featureset/memory_corruption
So yea - to suggest your little github repo that tweaks a few kernel settings is anywhere near the massive security hardening feature set that grsecurity delivers is also, well, embarassing.
reply