MTE requires several things to work well. Notably there is some missing hardware believed to be necessary for MTE to be performant on the pixel 11.
In terms of mitigation of UAF, a great deal of new code written for Android userspace these days is in memory safe languages such as rust. Also, a lot of testing with instrumented code sanitizers is still done before release. We don't know how much risk MTE actually mitigates.
There are several peripherals running their own OS. Those have their access to RAM limited by an iommu and they have no direct access to the primary storage (they may have some local ROM storage for firmware). If you're asking about the other OS that runs on the application processor such as the bootloaders, trusted firmware, trusted os, etc, then no, those have a superset of access to what the primary OS running on those cores have access to. This is by design.
The model for Android is that the OS is provided by the OEM. They work in partnership with Google. GrapheneOS tries to work against this model by not partnering with the OEM on supporting their hardware with its OS. Ultimately that's not sustainable given the dynamics of the ecosystem. This is why they are moving to a model where they do work with an OEM directly. These sorts of problems will subside once that happens.
You could argue that the current ecosystem dynamic is not great for the longer term, but it will require a change from the OEMs to enable something different as they are the ones actually in control of the situation.
I'm not sure that's the reason a minority user group is using alternative ROMs. They have always been niche, even before the play integrity API took off.
Arguably it is a rust problem. Rust can be improved to reduce the need to do as much manual maintenance of crates dynamics to allow for faster build times. The "you're holding it wrong" answer is not a good perspective to apply and I am surprised to see a prominent member of the rust community using it.
It has 1.8 million lines of rust. That compilation time seems close to what I'd expect at that size. If you want something faster you should focus on distributed build caching rather than speeding up the compiler. Also note that crates are effectively equivalent to a single file in c++ as it's the compilation unit. This is similar to compiling 2k files that average 1k loc each in c++. I'm sure it's much worse when you account for macro expansion and generics.
There is an assumption that AOSP is how OEMs receive Android updates from Google. However I am not sure that is the case. GrapheneOS is perhaps a minority player due to lack of hardware which they can use to get into a partnership agreement and advanced access.
I don't think that phrase means what you think it does. That only makes sense when there exists an open standard which a company builds an implementation for. Android was built from scratch and there was no standard.
The scale of engineering to compete with Android is an order of magnitude or two larger than that necessary to compete with those other products you mentioned. Not to mention the challenges of getting the developer market to follow you to your fork. It seems like any phone vendor even capable of giving it a go is okay with the current arrangement. Chinese firms can definitely do it and I guess Huawei has, but that's not entirely relevant to Western markets.
There was a split world for a long time even before the more recent changes because of the need to hide secret new features or products from the general public. It was always a tricky arrangement. They just decided one day that there wasn't a lot of folks contributing that lacked access to the private repos, so they might as well just switch all development to occur in that place. Honestly, it's somewhat rationale. If there was a significant number of folks contributing to Android without such access I'm sure that wouldn't have happened. We didn't lose as much as folks think we did given the code drops from the private repos still happened even previously.
I'm curious why you care about whether or not they spent time and effort to write those components themselves. Isn't that their choice as the authors? How does it materially affect you or the product experience? From my vantage point, I love the idea of having even more options as it will create competition, making all sides better for it. Having a singular dominant player in any space (whether it's a browser, kernel, or library) is something we should try to avoid whenever possible.
They don't need to do that to sell their hardware so why would they do that? On the other hand, they have strong incentives to not give you that level of access and information. The only way this will change is by having some disruption by way of a competitor who sells hardware with that feature as being a major reason why it takes off.
Security at its core comes down to trusting the supply chain that provides the software that runs on your hardware. There are many alternative secure supply chain models, but ultimately users often are incapable of making great choices on what is trustworthy. It does generally make sense that the OS vendor needs to play a key part in helping ensure trusted parties are involved in the supply chain.
Comparing phones to PCs isn't a great comparison because PCs don't have a great track record and the amount of personal data and ease of installing lots of apps is quite different. Of course the current arrangement is far from perfect, but acknowledging the problems it's trying to solve is an important step towards trying to find a solution that is better.
Having been on the flip side of this divide in the past, there really are a lot of potential safety and reliability problems when using random third party versions of components. While I'm sure there are strong financial incentives to constrain supply, there are also some other strong reasons as well.
Also it's very expensive to actually make an ecosystem compared to a close one. The best way to incentivize manufacturers to do it is by creating a competing product that is open and having that differentiating feature drive sales away. That's generally the approach that works best.
I saw this happen a bit earlier this year, but most everyone I work with has learned that it was foolish. The feedback that they are doing something wrong needs to be explicit and strong. We're all going through a learning curve and establishing cultural norms is important at this time.
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
My suggestion is to not try to idolize individuals. Products should be judged independent of the individuals involved in creating them, especially when many individuals participate in their creation.
People are all flawed. You can find faults in everyone. Overlooking these flaws is okay to a large number of folks as the product itself is amazing. The fact is that you're likely ignorant to the large number of products and services you use produced by folks with similar flaws.
This feels like the sort of thing that needs to be legislated. Banning accounts after breaking ToS is a pretty common behavior across many companies. The fact a Google account ends up being used for multiple products makes it more interesting but the overall problem here is not unique to them.
No, shared peripherals need to go through a central arbiter for access. In the case of things like storage the AP's OS, eg android, provides that roll. This is also true for the OS that runs under the trustzone. Be careful about spreading rumors without validating them.
The perception that they are able to run rings around Google is not necessarily an accurate one. There are tradeoffs in any engineering situation and GrapheneOS devs make different ones based on different requirements. Google is one of the reasons MTE even exists. I don't think GrapheneOS devs would be capable of helping push forward that technology in the same capacity.
I've written systems level code (drivers and os code) for years and outside of ffi, I've managed to go on year long stretches without touching unsafe. It's really not a commonly needed tool in a well architected code base with good libraries to encapsulate common reasons it might otherwise be necessary. And we don't really consider using unsafe taboo, it's just not necessary.
That's a cultural thing. Push back on it and don't make it acceptable behavior. I would argue most people generally are terrible at code review and do this same behavior with their peers as well, but at least their peers are capable of owning some level of responsibility, whereas the LLM is not.