>When an attacker gains a foothold in a corporate environment, they will immediately try to find any accessible credentials to assist in lateral movement.
So you think this isn't the case with home users? Maybe I still misunderstand the point that is being made here, but from my perspective it's only a matter of time until my encrypted password store gets exposed to the local attacker (as soon as I unlock it).
I didn't say it wasn't a problem for home users. I said that the browser security model works OK for home users who aren't at all bothered by security unless it gets in their way, in which case they will switch to a product that doesn't. It's poor security but probably the best we can do by default.
So that default browser behaviour creates a risk that a business should acknowledge and assess.
A home user can of course also decide it's too risky, or that password managers are too risky and only a yubikey will do.
Have you tried a different USB-A charger? Some smaller devices have problems with USB-C to USB-C. I don't know why this is the case, though. It's just something I have observed with different devices.
What are "absurd" amounts of CPU and memory? Calculating and pinning dependencies is just a very difficult problem which happens to be reducible to SAT. If you think a SAT solver takes a lot of time and memory, then all alternatives would probably be even slower.
Dependency solvers that obey semver are a really hard problem that have very unintuitive challenges. I think a very large number of people who use them will not have spent a lot of time to think about the issues in detail, just their experiences as a user of them. NPM has less complaints than composer for example, but node_modules has an interesting way out of the problem by making dependencies into a hierarchy but this brings a new bunch of challenges elsewhere (in the runtime, any object transiting between a mutual package which has two different package versions of the same package name in the lineage will be have "weird" behaviour).
Your Project --depends-on-> Foo@1.2.3 --depends-on-> SomeLib@1.2.3
Your Project --depends-on-> Bar@4.0.1 --depends-on-> SomeLib@4.5.6
If Your Project touches SomeLib from Bar and passes it into Foo things go sideways. It's easy to state that this violates best practices but it is a reality of how the runtime works. This category of issue is removed in PHP/Python by the package manager (not the language). The trade-off is the large computation that checks for conflicts in SomeLib.
> Dependency solvers that obey semver are a really hard problem that have very unintuitive challenges
throw in platform specific binary packages for which platform triplets can be wildcarded plus dependencies that may vary across these platforms plus specifying package sources for which dependencies may be on another source and you're in for a crazy world of hurt (well, at least I am, given I found some issues in bundler+rubygems and have been trying to solve them upstream for a couple of years)
There's a few novel techniques such as minimal version selection: https://research.swtch.com/vgo-mvs. I know I've seen a few others in the past years but I'm struggling to remember which ones are non-SAT solving approaches.
I use pip-tools with venvs for that and can‘t complain. It pins dependencies and you can create different requirements.txts for local dev and production (production for me is usually dev minus some debugging tools). It‘s not particularly fancy, but it gets the job done.
Threema's protocol doesn't even implement forward secrecy. From a security standpoint Threema is closer to iMessage than to Signal or other Signal-protocol-based messengers.
Except the default seccomp policy is not used for Kubernetes containers.
I didn't really think about this vector where you CLONE_NEWUSER in a container... definitely on systems that allow unprivileged users to do this it is a problem.
Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?
I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly.
systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.
> Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?
Traditionally, init scripts were installed into /etc but package managers (or at least some of them?) took/take care to not overwrite files under /etc but instead let you merge in the new changes.
802.11n with 5 GHz is okayish, but using 2.4 GHz can be brutal. It's not just the bandwidth, the whole frequency band is just bad. My latency regularly goes through the roof and voice calls are noticeably worse than with 5 GHz wifi.
802.11ac mandates 5 GHz, so it's a reasonable baseline. I don't even care if it's SISO, MIMO or whatever as long as I don't have to fall back to 2.4 GHz.
So you think this isn't the case with home users? Maybe I still misunderstand the point that is being made here, but from my perspective it's only a matter of time until my encrypted password store gets exposed to the local attacker (as soon as I unlock it).