41–50 of 186 posts
you edited your comment 3 times to downplay Daniels difficulty to work with? following this link http://slash-r-slash-rust.github.io/archived/2u1dme.html do you have a comment
We detached this comment from https://news.ycombinator.com/item?id=20149702 and marked it off-topic.
It supports the Google Pixel range of phones only so far. So in order to get that is more secure and more independent from Google I have to buy a Google phone?
Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.
Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.
https://android-developers.googleblog.com/2019/05/queue-hard...
As such I have a very hard time believing that Librem with be as secure as modern Android.
Earlier quoted context omitted.
Chain of trust does protect you from evil maid attacks. And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs. These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.
No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/…
Source, the Kernel Self Preservation Google's talk at the Linux Kernel Summit 2018.
Earlier quoted context omitted.
Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.
That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning. The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.
Android Q has another round of such measures.
https://android-developers.googleblog.com/2019/05/queue-hard...
Earlier quoted context omitted.
Well their long term goal is evidently moving to a microkernel based based OS rather than Linux. This seems like a lofty goal if they aren't for instance planning on switching to Fuschia (which may replace Android all together). Also its not like there are a lot of open mobile stacks that don't involve basically creating a ecosystem from scratch, aside from the Librem phone by Purism which is trying to integrate with…
Doing away with the Linux kernel is a much longer term aspiration. The intention is to use virtualization as a way of reinforcing the app sandbox and/or user profile isolation in the meantime. There has been successful experimentation with this already, but fully integrating it and maintaining it will need to wait until the project has gotten further underway and has more developers that are up to speed on it. It's o…
Check the Google IO 2019 talk about Linux support on ChromeOS.
Earlier quoted context omitted.
Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.
While with each Android interaction, Google locks down the amount of C and C++ code that gets exposed to outside world. https://android-developers.googleblog.com/2019/05/queue-hard... As such I have a very hard time believing that Librem with be as secure as modern Android.
In FOSS initiatives spent ages building fee and and open software, combating proprietary systems and software that they had no control over.
All that would be loss just to give it up now that we have moved from PCs to phones....
I for one want control over all the software I run on hardware I own. I am not sure why we are so willing to give that control up simply because the platform changed.
It supports the Google Pixel range of phones only so far. So in order to get that is more secure and more independent from Google I have to buy a Google phone?
Exactly my question. I have seen a bunch of these OSs, all useless because there is no build for my phone and no described path for making one. I would love to get the T-Mobile spyware off my phone. What do i do?
The obvious way to get a phone not running T-Mobile spyware is to not buy a phone from T-Mobile.
Not trying to be snarky here, I have one of these phones too. Though if you happen to have a T-Mobile Oneplus phone like I do it is possible to flash the international ROM and replace the T-Mobile spyware with Chinese spyware.
Creator of CopperheadOS [0] and now GrapheneOS, Daniel Micay, was a prolific contributor to rustlang-core [1] but did rub off the rustlang community the wrong way? If I'm not mistaken he has a history of contributing to Arch Linux, as well. What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following a…
This project and its predecessor are so cool. I've been glad to see their continued progress. It's probably not wise to post this, since I never talk about it publicly, he might not like it, and this thread should be about GrapheneOS, not Rust or myself. But with the mention of his Rust involvement and the history of CopperheadOS, I feel compelled at the moment to add some context and give him props. He is an excepti…
I wanted him to stay a little more around the Rust 1.0 era because I thought as many warts as possible should have been fixed before the backward compatibility guarantee was made, but he left too early.
Didn't know about the CopperheadOS incident, too bad such a situation happened to him. Good to see it's kinda resolved now.
Creator of CopperheadOS [0] and now GrapheneOS, Daniel Micay, was a prolific contributor to rustlang-core [1] but did rub off the rustlang community the wrong way? If I'm not mistaken he has a history of contributing to Arch Linux, as well. What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following a…