1,301 karma · joined August 31, 2011
I am betting you know what mandatory access control is ; ). They basically amount to a firewall that is placed on applications restricting what they can do. The rules are generally written by downstream distros and are divorced from the implementation. The problem is that it's hidden control flow, so the program just dies and can't fall back gracefully. Capability oriented APIs make broker processes and narrowing of permissions tractable.
[1]: https://sel4.systems/performance.html
[2]: https://lionsos.org/
[3]: https://trustworthy.systems/publications/papers/Heiser_25%3A...
The depressing fact is that you don't need an RCE to accomplish most goals.
Shit hasn't changed much. We still have monolithic kernels written in portable assembly. Linus still doesn't tag bug fixes with potential security impacts as such because he is more worried about unpatched consumer garbage (which compromise all low end phones). When your mitigation for such problems is to not make it obvious, then your OS is not safe enough in safety critical settings (which includes consumer devices).
Process isolation would downgrade the vast majority of critical Linux CVEs to availability bugs (crash a server but not compromise it).
Just because governments don't need to reach for RCE everytime doesn't mean that it is safe. Th fact that such bugs are so cheap is an indication that your safety margin is too thin.
What is your objection?
Air gapping is a baseline requirement in most safety critical systems. Nuclear power plants in particular have lots of redundant layers of safety. AFAIK Russia hasn't physically tried to cause a meltdown, presumably due to the political blow back (although they have attacked Chernobyl's sarcophagus). I assume this limits their digital espionage attacks too.
We do get glimpses of the use of such malware, like when Saudi Arabia hacked Jeff Bezos' phone. But we don't hear about most of it because there is a benefit to keeping a hack secret, so as to keep access.
Finally, it's usually cheaper to social engineer someone into loading a PowerPoint presentation and doing a local privilege escalation. They burn those for things as petty as getting embarrassing political information.
> Those are (mostly) not RCE, and are for consumer devices configured in a default way.
I'm more worried about activists and journalists in developing counties without the financial means to afford flagship phones. But even Google can't manage to keep out a pedestrian mid sized security outfit selling to the cops and the FBI.
When activists lobbying for a fucking sugar tax in Mexico get hacked, then the bar is too fucking low.
Let's not talk about the nightmare that is old networking equipment or IoT devices.
The cost of internally developed exploits is probably much lower. They aren't one shot assets either, they can be used until someone plugs the hole.
There are private companies selling devices to law enforcement that can extract information from locked phones [2]. Availability of that sort of access to anyone's phone by local law enforcement is absurdly cheap.
[1]: https://opzero.ru/en/prices/
[2]: https://arstechnica.com/gadgets/2025/10/leaker-reveals-which...
My main concern is speed and the lack of capability based security. seL4 is faster than Linux by a mile and I'm guessing that this is much slower. You can put a POSIX layer on seL4 but POSIX is inherently flawed too. MAC separates privileges from code and is too clunky to use in practice (see seLinux).
But that's a primary issue with TC's tests: it doesn't consider corner cases like this or water hardness. Consumers want it to "just work" and are not going to use a specific settings based on the contents of their dinner.
Sure, it helps the prewash remove fats. But if the main wash and the rinse aid get rid of all that regardless, then it doesn't really matter.
It's because, as outlined in the linked article, hot water makes the problem of staining plastic worse. So they try to mechanically remove it before the main wash. Note that in the original video, the main wash heat temperature wasn't impacted by preheating the prewash.
Claiming that a leading brand was being beaten by a random formula made by a contractor is a big red flag. They tend to dominate Consumer Reports testing and this is a trend across detergents and cosmetics: the big manufacturers have the money to do original research and the scale to do stuff bit players just can't. Pantene is hated in hair salons but blinded end-user tea ing shows that it outperforms everything else on the market, for example.
But it's also true that making a good enough soap for a given task isn't hard. Otherwise you wouldn't have so many damn cosmetic products out there. The delta just isn't that significant and plenty of people are fine with bar soap for everything. So I'm not surprised that the llama detergent scored well on some tests.
TC really should have partnered with a detergent scientist to check his experimental setup first.
Can't wait for the YouTube drama over something so petty as dishwasher detergent and the prewash!
This is exactly what it felt like to work in crypto.
We might see real world usage of these technologies had browser vendors not frozen them out.
The XML proponents lost this fight a long time ago. Without continued development, the user base shriveled up. Now that no one uses it, the runtimes are looking to cut dead weight.
I disagree with the pivot (RIP noscript) but it's not Google making this move unilaterally. It's been in the works for a long time.
I would love to hear how the benchmarking goes!