But taking drugs also affects physiological things such as breathing, heart rate, salivation, sweat, etc. All of those things are tied to physical material that starts outside the body that our physical bodies manage thanks to evolutionary selection. We manage oxygen with breathing/heart rate, water for salivation and sweat, etc. The fact that the physical body and evolution also manage consciousness should probably be evidence that consciousness exists outside the body just like oxygen and water.
The other side of this argument is that the world is not getting off oil. We will need the oil if we want to get every nation up to a Euro/US standard of living.
It’s destroying demand at a massive clip, if the IEA is to be believed [1]. With Riyadh’s elevated break-even price [2] that doesn’t leave them a lot of time.
Excellent call outs, the price of oil doesn’t have to go to zero, it must simply be held below what middle eastern countries need to pacify their populations. Failing that, all hell breaks loose, potentially impairing their petroleum supply chains (depending on intensity of turmoil that occurs).
The industry runs on oil (and gas) and that's not going to be phased away as easily as cars.
It would be nice to see something like Tesla but for heavy/industrial machinery, though. I think I saw something somewhere, but can't find the source at this time.
NetGuard doesn't support the standard OS leak blocking like Mullvad and doesn't try to filter DNS so it inherently has leaks. There are no known remote leaks on Android 14 when a VPN app supporting is already active or when it's down. The DNS leaks in this post were partially caused by an app bug that's not fixed and also happen when the VPN is in the process of connecting. The issue with leaks when the VPN is in the process of connecting may be an app bug or an OS bug. It's not clear that it's an OS bug at this point. It was reported to us for GrapheneOS earlier and we've been looking into it.
There's also leak issue which was reported where multicast packets leak outside of the VPN tunnel to the local network. This is highly likely to be an OS bug, unlike the DNS leak issue where it's not yet clear if the OS or the app is the problem. The OS can likely prevent those DNS leaks even if apps don't get fixed but it wasn't necessarily supposed to be responsible for it. From the OS perspective, a VPN app is supposed to set a DNS configuration and not setting that configuration results in partially using the OS DNS.
If you don't mind clarifying, currently GOS uses ASYMMETRIC MTE for the low overhead and to close the soft time constraint in ASYNC MODE. I was having a read though https://googleprojectzero.blogspot.com/2023/08/mte-as-implem...
Where I had come accross possible MTE bypasses in ASYNC mode and I quote:
'Since SIGSEGV is a catchable signal, any signal handlers that can handle SIGSEGV become a critical attack surface for async MTE bypasses'. Moreover, "The concept is simple - if we can corrupt any state that would result in the signal handler concluding that a SIGSEGV coming from a tag-check failure is handled/safe, then we can effectively disable MTE for the process", hence having MTE as ineffective.
Paradoxically, I don't believe this issue is faced regarding SYNC MODE. As you obviously know, 'in asymmetric mode, read memory accesses are processed as SYNC, while write memory accesses are processed as ASYNC'.
does this mean that the signal handlers in write memory are exploitable?
If this be true, does GOS offer a mitigation for this, or can it be possible to simply allow all users to have the option to pick SYNC MTE to bypass this attack surface?
Furthermore, MTE is not enabled for the kernel, would it be possible to have it enabled by choice as well?
Finally, regarding the OS processes to which GOS recently enabled MTE for as an option for its users, does it also include the cellular firmware, IOMMU/SMMU and the software stack that communicates between the isolated chip and the OS? I address this point because, GAL Beniamini stated that:
" That said, up until now we’ve only considered the high-level attack surface exposed to the firmware. In effect, we were thinking of the Wi-Fi SoC and the application processor as two distinct entities which are completely isolated from one another. In reality, we know that nothing can be further from the truth. Not only are the Wi-Fi SoC and the host physically proximate to one another, they also share a physical communication interface". Nonetheless he further states:
"For example, by going over the IOMMU bindings in the Linux Kernel, we can see that apparently both Qualcomm and Samsung have their own proprietary implementations of an SMMU (!), with it’s own unique device-tree bindings. However, suspiciously, it seems that the device tree entries for the Broadcom Wi-Fi chip are missing these IOMMU bindings". Despite that the research is from a couple years, it remains viable evidence that IOMMU although provides adequate protection, it remains an insufficient mechanism on its own and requires further hardening on the software stack. Does GOS address this profound attack vector?
If you are worried about users holding the DAO hostage by not signing cooperatively, you might want to check out ROAST which is basically FROST done in rounds in such a way that you can withstand some malicious participants.
Since you are evangelizing a little bit, I have a question about nix. I'm a debian user, and I see debian as a base layer. It takes care of security updates and miscellaneous system configurations so I don't have to. In a way, it shifts under my feet, and I like that because those shifts are necessary for security and progress. How are you able to use nix in a way that allows those shifts to silently occur while at the same time maintain full control over your system's configuration? I imagine there must be some kind of tension between fully specifying what you want vs allowing experts to take care of configurations as they see fit.
You don't really fully specify most things. A complete working NixOS config with a few core utilities is like 50 lines without comments. Here is my main workstation's full definition: https://git.sr.ht/~chiefnoah/nixos/tree
It's split up into multiple files, but even the total combination is not that much. If you let Nix take over your system (ie. NixOS) it moves out from underneath you in a completely reproduceable and revertable way so you can almost always just... run the equivalent of a dist-upgrade daily and get on with your life because you're 1 command away from undoing it all.
You'll obviously have more the more you customize things, but for the most part its services.<service>.enabled = true;. The defaults are usually good enough IME.
Your repo is very helpful. Really great comments. It's too bad that I'm so busy. The Nix sirens are certainly calling, but I'll have to plug my ears for now.
MSRs look nice on paper but we don’t have any experience building them. It would take a gigantic up front investment to work out the real world issues and commercialize a technology that has a lot of novel aspects like handling radioactive molten salt.
Meanwhile that same money would buy loads more power in solar/wind and batteries, which are proven technologies that are getting progressively cheaper.
An alternate timeline where we do MSRs in the 1950s and phase out coal by 1990 would have been possible but we didn’t do that and there are better alternatives now.
I have not seen any evidence that solar+wind will provide a proper base load of electricity, and it looks like MSR and its variants will give people the electricity they need.
While nuclear plants do pair well with storage (many pumped hydro storage stations were built to pair with nuclear plants), the idea that they cannot load follow is a myth. It is simply more economical for them to run at full load since fuel cost is a very small portion of nuclear operating expenses.
It will likely take a minimum of ten years to get a non light water reactor certified by the NRC. And that is very optimistic. Then you have to build the first of a kind plant which is always more expensive and takes longer. Then you have to get good at operating these new kinds of plants.
It's true that MSR and Breeder reactors have lots of potential benefits over traditional LWRs but the truth is, LWRs are more than good enough for right now and we literally can't build enough of them if even if we tried.
You wouldn't want to power all of human society off of LWRs simply because they only access ~5% of the energy in the fuel. But we're so far away from that being a constraint. Build LWRs today and keep developing Breeder/MSR tech.
