13 ms·

GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

AstralStorm 7y ago
Security focused and Android in the same sentence? All I can say is good luck with various firmware, custom services and drivers.
- robotbikes 7y ago
  From the link- "In the current early stage of the project, GrapheneOS provides production releases for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL. It will support other devices in the future, but devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas."
  - Mediterraneo10 7y ago
    Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.
    - jtl999 7y ago
      May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication. I do think more research is needed.
      - letstrynvm 7y ago
        I was pretty amazed when I bought an MR200 lte-capable router that the LTE module actually runs its own personal Android discrete from the router cpu. https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.
        strcat 7y ago
        The cellular, Wi-Fi / Bluetooth and NFC radios do receive firmware security updates. GrapheneOS isn't going to support devices without proper security support, which includes ongoing maintenance and security engineering / research for the firmware and drivers. Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.
    - strcat 7y ago
      A component being on the same die as the CPU doesn't mean that it isn't isolated. The SoC components in Snapdragon chips have IOMMU isolation. In modern computers, including smartphones, there are many components inside and outside SoC with memory access. A component being on the SoC is orthogonal to whether it has direct memory access. Direct memory access is supposed to be contained properly by an IOMMU, and that's the case for most of the components in the devices targeted by GrapheneOS. It's one of many kinds of hardware / firmware security properties that's going to play a substantial role in researching and choosing devices as targets. Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.
    - temptemptemp111 7y ago
      Yep!
- deleted 7y ago
  [deleted]
- huahe 7y ago
  maybe take a look at /e/ https://e.foundation/ https://e.foundation/
  - 0xdeadb00f 7y ago
    /e/ is not as "un-googled" as they claim to be: https://ewwlo.xyz/evil https://ewwlo.xyz/evil https://infosec-handbook.eu/blog/e-foundation-first-look/ https://infosec-handbook.eu/blog/e-foundation-first-look/
- skrowl 7y ago
  Found the Apple zealot! Seriously though, I hear Apple is super great on privacy now as long as you take their word for it and not their track record of being a member of PRISM https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29 https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%... , etc
  - strcat 7y ago
    Every US company has to comply with lawful US government orders if they're going to continue operating. I highly recommend reading carefully through the details on the page you linked. It doesn't only apply to a few companies. It's very difficult to fight the government even in cases where it's arguably unconstitutional, etc. You have to assume that all US companies are going to comply with US warrants to obtain information, including when those warrants come from a secret court with a gag order. There were consequences to the US passing draconian surveillance laws like the Patriot Act and the updates to it. Companies / organizations and individuals based in the US are subject to those laws. Many other countries have similar or even more oppressive laws when it comes to these things. A company being based in for example France doesn't mean that the same kind of things don't apply. If you don't want data to be subject to warrants requesting the information from companies, you need to either avoid having your data there or make sure it's encrypted with a key that the company doesn't have. End-to-end encryption is important. The companies could also have the data exposed by a malicious insider or a data breach. Many countries will happily demand the key from you and then treat you as a criminal for not turning it over but that doesn't work for mass surveillance.
- strcat 7y ago
  > Security focused and Android in the same sentence? The whole point behind it is working on a new mobile OS, while providing Android app compatibility by using the Android Open Source Project. As the page states, the long-term goal is to turn AOSP into an application layer while moving away from entirely depending on Linux for low-level security since it's a huge liability / weakness. It already isn't 'Android' since it makes changes deviating from what's required to be Android (the Compatibility Definition Document and Compatibility Test Suite). The goal is practical compatibility with Android applications rather than conforming to what's requiring to be Android. > All I can say is good luck with various firmware, custom services and drivers. Hardware, firmware and drivers aren't an OS specific issue beyond drivers being tied to Linux. There's barely any content on the site yet, but it does cover how important it's going to be to make careful choices about which hardware to support in the device support section. It talks about how much of the privacy and security is tied to hardware capabilities and security support.
neilv 7y ago
A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).
- robotbikes 7y ago
  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 the existing Debian/GNU Linux ecosystem.
  - strcat 7y ago
    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 one thing to simply integrate Xen or KVM for toy examples and quite another to more meaningfully integrate it in an invisible way that preserves the existing functionality rather than being useful only as a proof of concept for research or presentations.
    - pjmlp 7y ago
      That is how ChromeOS runs the new Linux sandbox, implemented in Rust. Check the Google IO 2019 talk about Linux support on ChromeOS.
- duxup 7y ago
  I always wondered what the backstory was there, but the internet is one of those places where if I heard to the real story I don't know if I'd know enough to belive it.
ignoramous 7y ago
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 and there's hope, given his exploits in the past, that he'd be able to steer this non-profit to heights where industry leaders building SilentCircle [5] and CyanogenMod failed. Sure will be following the project from afar and routing for its success. Good luck Daniel. [0] https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodbye/ https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodby... [1] https://news.ycombinator.com/item?id=9551937#9552769 https://news.ycombinator.com/item?id=9551937#9552769 [2] https://news.ycombinator.com/item?id=17289536 https://news.ycombinator.com/item?id=17289536 [3] https://news.ycombinator.com/user?id=strcat https://news.ycombinator.com/user?id=strcat [4] https://news.ycombinator.com/item?id=19501643#19559969 https://news.ycombinator.com/item?id=19501643#19559969 [5] https://news.ycombinator.com/item?id=12047219 https://news.ycombinator.com/item?id=12047219
- CaptainBern 7y ago
  He's also the author of Termite[0]. Pretty impressive how many projects he's been involved with. [0] https://github.com/thestinger/termite https://github.com/thestinger/termite
  - strcat 7y ago
    Termite has been officially maintained by https://github.com/jelly https://github.com/jelly for quite a while now though.
- brson 7y ago
  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 exceptionally skilled developer. Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code. And from what I recall he was in high school at the time. Amazing. I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone. It is totally fair to say that Rust would not be what it is today, both technically and socially, without him. I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS. Good luck, Daniel. (edited to remove some Rust cheerleading)
letstrynvm 7y ago
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/ 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.
- yegortimoshenko 7y ago
  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.
  - letstrynvm 7y ago
    I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.
    - yegortimoshenko 7y ago
      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.
      - letstrynvm 7y ago
        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/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.
racuna 7y ago
Also, https://postmarketos.org/ https://postmarketos.org/ is a good project too.
- neilv 7y ago
  PostmarketOS seems the most promising effort for a truly open and affordable handheld OS with mainline kernel and other good practices. And there's also a useful incremental path for evolution, that starts with a familiar GNU/Linux and moves gradually towards handheld tweaks (UI, power, devices, apps). It's important to be upfront that PostmarketOS is not yet viable as a daily driver, or people will feel they wasted their time looking at it. What it really needs is programmers, like the earlier Linux ones, who will power through the pain of getting things working well, and stick with it for months, as a labor of love.
  - Dunedan 7y ago
    PostmarketOS reminds me a lot about the approach Openmoko (https://en.wikipedia.org/wiki/Openmoko https://en.wikipedia.org/wiki/Openmoko) took way back over a decade ago, except that they did have to build the hardware as well.
    - neilv 7y ago
      There've been several such prominent open source handheld projects in the last 20 years. PostmarketOS seems the most viable, IMHO, because it emphasizes the old Linux (and GNU) principles of getting working on lots of available hardware, with true open source, mainlined. (Separately, it also potentially builds on a wealth of GNU/Linux stuff that there's no good reason shouldn't have a lot of commonality between desktop and handheld.)
- Funes- 7y ago
  PostmarketOS in tandem with the Pinephone[0] should be a great choice in the future. [0]: https://www.pine64.org/pinephone/ https://www.pine64.org/pinephone/.
huahe 7y ago
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 http://slash-r-slash-rust.github.io/archived/2u1dme.html do you have a comment
- dang 7y ago
  Please don't use HN to promote personal attacks. It damages the community, regardless of how badly someone might have behaved in another context. We detached this comment from https://news.ycombinator.com/item?id=20149702 https://news.ycombinator.com/item?id=20149702 and marked it off-topic.
ThinkBeat 7y ago
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?
- astazangasta 7y ago
  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?
  - opencl 7y ago
    If you have a phone with T-Mobile spyware then it almost certainly also has a locked bootloader with no official unlock method. What are you expecting people developing alternate OSes to do about that? 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.
    - skrowl 7y ago
      To clarify, some of the phones you can buy directly from T-Mobile can also be bought "unlocked" in the open market. In general, if you want any hope of unlocking your phone (either for use on other carriers or unlocking the bootloader) then you should NOT buy from the carriers' online or brick & mortar stores.
  - gibspaulding 7y ago
    Unfortunately all you can really do is pick up a different phone. Luckily finding an old unlocked Nexus 5 or OnePlus One on ebay is pretty easy and relatively cheap.
  - kevin_thibedeau 7y ago
    Stop buying telco subsidized phones.
markstos 7y ago
I can see what the focus is, but I couldn't find a page that clearly spelled out differences with AOSP. I realize that's a missing target, but as a potential user it's interesting to know how it's going to be different than stock Android (beyond what the "focus" is).
dvduval 7y ago
Would this be something Huawei might get into?
- _Ender 7y ago
  Huawei could probably do something similar, however they still can't access the Google Play Store and such, therefore leaving them in a problematic area. For instance, though somewhat substantial, the Amazon store is quite pitiful in comparison to Google Play. Huawei could attempt to make a store but it won't have the world of apps that already exist on the Play Store. This would work in China though, since they don't have the Play Store in the first place.
rplnt 7y ago
What does it matter if you are still running proprietary software with direct memory and CPU access on your network, camera, ... Android can give you privacy and enough security for most people. This can't add much more as long as its running on the same devices. This is a great effort and I support it, but let's not imagine this will make our phones that much more secure.
- yegortimoshenko 7y ago
  For reference, this concern has been addressed here: https://news.ycombinator.com/item?id=20149112 https://news.ycombinator.com/item?id=20149112
- strcat 7y ago
  Open source is a development model and doesn't have magical privacy and security properties. An iPhone is going to remain the best overall option for privacy and security for the near future, especially for users that aren't very technical. That's not really in spite of it being almost entirely proprietary but rather that's something quite orthogonal to it. GrapheneOS aims to provide a much more private and secure option down the road, but it's trying to do that based on merit rather than by claiming that being open source makes it better. Either way, the any ARM SoC is going to be a massively complex set of proprietary hardware / firmware / microcode. An open hardware SoC wouldn't provide inherently better privacy or security, and unlike software you wouldn't even be able to reproduce the build and verify that it matches what it's supposed to be. In reality, that provides very little for software, because sources are full of vulnerabilities and it being open source doesn't magically fix them. A maliciously inserted backdoor designed to be stealthy would be indistinguishable from those, and it's nearly impossible to know how many of the vulnerabilities being fixed in software were intentionally inserted backdoors, if any. A sophisticated attacker in a position to insert a backdoor into hardware or software could just use the existing vulnerabilities, and if they did insert a backdoor how would you distinguish it from one of those? Components with DMA can be contained by IOMMU, and that's the industry standard today. However, you seem to be implying that backdoors are being inserted into non-CPU SoC components, and it's very hard to understand the threat model you're applying to this. Why would there even be a backdoor inserted into an SoC component like the image processor, which is contained by the IOMMU, rather than the CPU? These SoC components aren't third party components. They're on the same die as the CPU and come with it. That doesn't mean they can freely access all memory... but it does mean that supply chain attacks targeting them would generally be able to target the CPU instead. If a hardware component is compromised, an attacker would target the driver and gain code execution in the Linux kernel via an exploit. The Linux kernel is a weak target (monolithic - no internal security boundaries, fully written in a memory unsafe language) and drivers are rarely well hardened against attacks from hardware since developers have a tendency to trust it and to not apply an adversarial model towards it as they do with userspace. They don't need unrestricted DMA access, and proper IOMMU setup keeps them from having that. Having DMA does not mean having full control over all memory. Not having DMA doesn't mean that the component is well isolated. Whether or not the component is on the same die is totally orthogonal to whether it has DMA access. These are common misconceptions, and are being abused by dishonest marketing to trick people. > Android can give you privacy and enough security for most people. Some of that is due to the improvements landed upstream based on the work in this project. > This can't add much more as long as its running on the same devices. I don't agree with that at all. It can't improve the security of firmware directly, but it can certainly improve the isolation of it by auditing and improving IOMMU configuration along with hardening the drivers. It also won't be supporting devices without decent IOMMU support and firmware security updates. The project has also reported various firmware security issues to the relevant companies over the years of the project, so that's an indirect way of improving them. A large portion of the project will also be on app layer projects like https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor usable on the stock OS and other operating systems. Auditor / AttestationServer support the stock OS on a bunch of devices, along with CalyxOS and GrapheneOS. Other apps will generally be more portable, but in this case it has to have a database of the verified boot key fingerprints and other device properties. The verified boot key is the only information included in the signed hardware attestation data that it can use to distinguish between devices which it needs to do in order to show the device model and apply different checks based on the device. That's why devices need to be added to Auditor one-by-one based on users submitting sample attestations with the app.
mlinksva 7y ago
https://grapheneos.org/#roadmap https://grapheneos.org/#roadmap is pretty interesting: > Details on the roadmap of the project will be posted on the site in the near future. In the long term, it aims to move beyond a hardened fork of the Android Open Source Project. Achieving the goals requires moving away from relying the Linux kernel as the core of the OS and foundation of the security model. It needs to move towards a microkernel-based model with a Linux compatibility layer, with many stepping stones leading towards that goal including adopting virtualization-based isolation.
- strcat 7y ago
  Strengthening the security with virtualization is something that's in the early stage of experimentation and research and will be a long-term project. Over the long term though, the goal is moving away from having the Linux kernel completely other than as the native API / ABI for apps. Projects like https://github.com/google/gvisor https://github.com/google/gvisor are very promising in that regard even if they end up playing no part in how this eventually happens for GrapheneOS. A clearer and much more detailed roadmap will be posted soon. The site is still very newly created and barely has any information about the project. Essentially, the goal for the project is for it to be an OS compatible with Android apps, using the Android Open Source Project software stack to run them, but the underlying base can become whatever is most suited to the task. For now, the most practical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too. I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS. The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.
samirm 7y ago
how does this compare with something like microG?
- 0xdeadb00f 7y ago
  It doesn't compare because microG isn't an Android "ROM" - you can't compare the two.
  - black_puppydog 7y ago
    You most certainly can! Microg is a (very welcome!) band-aid for the fact that the android ecosystem is critically dependent on a proprietary piece of software called play services. PMO is a different, libre, OS and ecosystem that doesn't have that problem to begin with since it is truly a Linux (as opposed to AOSP) and truly free (as opposed to android's "can read most code but Google holds all the cards")
    - strcat 7y ago
      There's a far larger app ecosystem for Android without Play Services than any other mobile OS. It's very odd to try to claim that it doesn't have that problem. Android is truly a Linux distribution too, and is truly free software. You can promote your preferred mobile OS without making misleading claims.
xaduha 7y ago
Stock-ish Android that gets updates is good enough for me. I'm looking forward to wider support of U2F over NFC in general though, I don't keep data on the phone itself. You can buy a contactless smartcard for $15 each and install this on it https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F
_Ender 7y ago
"Android compatibility" implies that it's something entirely new. It appears to be an Android fork that simply hasn't done away with compatibility. There are neat ideas and all, but the title implies that it's something that it isn't. Lastly, I wonder how this will do over time considering Fuschia.
- strcat 7y ago
  It's not implied that it's something completely new, although a dozen of the sub-projects are new projects rather than forks of existing ones. The overall project is not simply a fork of the Android Open Source Project with hardening. That's a subset of the work, and a big part of it. I also added a paragraph to the placeholder index page clarifying the longer-term plans with virtualization: https://grapheneos.org/#roadmap https://grapheneos.org/#roadmap. GrapheneOS includes sub-projects including standalone projects like https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor and https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc that are portable to other operating systems. This also applies to a lot of work that's under active development and not yet published as part of the stable releases. It intentionally doesn't stick to the Compatibility Definition Document / Compatibility Test Suite requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them. > Lastly, I wonder how this will do over time considering Fuschia. If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.
  - _Ender 7y ago
    I get that, and the site doesn't imply that it's something new, but I simply found the title of the post to be such. Fair enough though. >If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though. I see.
nerd7473 7y ago
I need to try this, I also need to get a Librem 5, and build my project for it. Anyone know of any good projects for replacing google services with FOSS services that do the same basic things?
danvittegleo 7y ago
For anyone interested in doing their own customizable builds of AOSP for Pixel devices check out: https://github.com/dan-v/rattlesnakeos-stack https://github.com/dan-v/rattlesnakeos-stack. This doesn't have any of the security hardening features of GrapheneOS, but does have some of the same security properties like verified boot, OTA software updates that included updated firmware/drivers, support for remote attestation, etc.
julienfr112 7y ago
Is that like the real thing (graphene) and can do anything but go out of the lab ?
tdxcbkif 7y ago
How does graphene compare to linage os?
techsin101 7y ago
I shouldnt be commenting. But os with new kernel like chrome os would be ideal for security, privacy and performance. Only thing left is open hardware not sure how to go about it.
okanesatoshi 7y ago
Why use utility token? Coin Circle a state of utility token, get a chance to win $500 USD daily contest at https://coincircle.com/l/1RQBJ6CRKU https://coincircle.com/l/1RQBJ6CRKU

Security focused and Android in the same sentence? All I can say is good luck with various firmware, custom services and drivers.

robotbikes 7y ago
From the link- "In the current early stage of the project, GrapheneOS provides production releases for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL. It will support other devices in the future, but devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas."
- Mediterraneo10 7y ago
  Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.
  - jtl999 7y ago
    May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication. I do think more research is needed.
    - letstrynvm 7y ago
      I was pretty amazed when I bought an MR200 lte-capable router that the LTE module actually runs its own personal Android discrete from the router cpu. https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.
      - strcat 7y ago
        The cellular, Wi-Fi / Bluetooth and NFC radios do receive firmware security updates. GrapheneOS isn't going to support devices without proper security support, which includes ongoing maintenance and security engineering / research for the firmware and drivers. Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.
  - strcat 7y ago
    A component being on the same die as the CPU doesn't mean that it isn't isolated. The SoC components in Snapdragon chips have IOMMU isolation. In modern computers, including smartphones, there are many components inside and outside SoC with memory access. A component being on the SoC is orthogonal to whether it has direct memory access. Direct memory access is supposed to be contained properly by an IOMMU, and that's the case for most of the components in the devices targeted by GrapheneOS. It's one of many kinds of hardware / firmware security properties that's going to play a substantial role in researching and choosing devices as targets. Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.
  - temptemptemp111 7y ago
    Yep!
deleted 7y ago
[deleted]
huahe 7y ago
maybe take a look at /e/ https://e.foundation/ https://e.foundation/
- 0xdeadb00f 7y ago
  /e/ is not as "un-googled" as they claim to be: https://ewwlo.xyz/evil https://ewwlo.xyz/evil https://infosec-handbook.eu/blog/e-foundation-first-look/ https://infosec-handbook.eu/blog/e-foundation-first-look/
skrowl 7y ago
Found the Apple zealot! Seriously though, I hear Apple is super great on privacy now as long as you take their word for it and not their track record of being a member of PRISM https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29 https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%... , etc
- strcat 7y ago
  Every US company has to comply with lawful US government orders if they're going to continue operating. I highly recommend reading carefully through the details on the page you linked. It doesn't only apply to a few companies. It's very difficult to fight the government even in cases where it's arguably unconstitutional, etc. You have to assume that all US companies are going to comply with US warrants to obtain information, including when those warrants come from a secret court with a gag order. There were consequences to the US passing draconian surveillance laws like the Patriot Act and the updates to it. Companies / organizations and individuals based in the US are subject to those laws. Many other countries have similar or even more oppressive laws when it comes to these things. A company being based in for example France doesn't mean that the same kind of things don't apply. If you don't want data to be subject to warrants requesting the information from companies, you need to either avoid having your data there or make sure it's encrypted with a key that the company doesn't have. End-to-end encryption is important. The companies could also have the data exposed by a malicious insider or a data breach. Many countries will happily demand the key from you and then treat you as a criminal for not turning it over but that doesn't work for mass surveillance.
strcat 7y ago
> Security focused and Android in the same sentence? The whole point behind it is working on a new mobile OS, while providing Android app compatibility by using the Android Open Source Project. As the page states, the long-term goal is to turn AOSP into an application layer while moving away from entirely depending on Linux for low-level security since it's a huge liability / weakness. It already isn't 'Android' since it makes changes deviating from what's required to be Android (the Compatibility Definition Document and Compatibility Test Suite). The goal is practical compatibility with Android applications rather than conforming to what's requiring to be Android. > All I can say is good luck with various firmware, custom services and drivers. Hardware, firmware and drivers aren't an OS specific issue beyond drivers being tied to Linux. There's barely any content on the site yet, but it does cover how important it's going to be to make careful choices about which hardware to support in the device support section. It talks about how much of the privacy and security is tied to hardware capabilities and security support.

neilv 7y ago

A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).

robotbikes 7y ago
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 the existing Debian/GNU Linux ecosystem.
- strcat 7y ago
  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 one thing to simply integrate Xen or KVM for toy examples and quite another to more meaningfully integrate it in an invisible way that preserves the existing functionality rather than being useful only as a proof of concept for research or presentations.
  - pjmlp 7y ago
    That is how ChromeOS runs the new Linux sandbox, implemented in Rust. Check the Google IO 2019 talk about Linux support on ChromeOS.
duxup 7y ago
I always wondered what the backstory was there, but the internet is one of those places where if I heard to the real story I don't know if I'd know enough to belive it.

ignoramous 7y ago

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 and there's hope, given his exploits in the past, that he'd be able to steer this non-profit to heights where industry leaders building SilentCircle [5] and CyanogenMod failed. Sure will be following the project from afar and routing for its success. Good luck Daniel. [0] https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodbye/ https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodby... [1] https://news.ycombinator.com/item?id=9551937#9552769 https://news.ycombinator.com/item?id=9551937#9552769 [2] https://news.ycombinator.com/item?id=17289536 https://news.ycombinator.com/item?id=17289536 [3] https://news.ycombinator.com/user?id=strcat https://news.ycombinator.com/user?id=strcat [4] https://news.ycombinator.com/item?id=19501643#19559969 https://news.ycombinator.com/item?id=19501643#19559969 [5] https://news.ycombinator.com/item?id=12047219 https://news.ycombinator.com/item?id=12047219

CaptainBern 7y ago
He's also the author of Termite[0]. Pretty impressive how many projects he's been involved with. [0] https://github.com/thestinger/termite https://github.com/thestinger/termite
- strcat 7y ago
  Termite has been officially maintained by https://github.com/jelly https://github.com/jelly for quite a while now though.
brson 7y ago
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 exceptionally skilled developer. Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code. And from what I recall he was in high school at the time. Amazing. I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone. It is totally fair to say that Rust would not be what it is today, both technically and socially, without him. I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS. Good luck, Daniel. (edited to remove some Rust cheerleading)

letstrynvm 7y ago

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/ 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.

yegortimoshenko 7y ago
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.
- letstrynvm 7y ago
  I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.
  - yegortimoshenko 7y ago
    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.
    - letstrynvm 7y ago
      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/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.

racuna 7y ago

Also, https://postmarketos.org/ https://postmarketos.org/ is a good project too.

neilv 7y ago
PostmarketOS seems the most promising effort for a truly open and affordable handheld OS with mainline kernel and other good practices. And there's also a useful incremental path for evolution, that starts with a familiar GNU/Linux and moves gradually towards handheld tweaks (UI, power, devices, apps). It's important to be upfront that PostmarketOS is not yet viable as a daily driver, or people will feel they wasted their time looking at it. What it really needs is programmers, like the earlier Linux ones, who will power through the pain of getting things working well, and stick with it for months, as a labor of love.
- Dunedan 7y ago
  PostmarketOS reminds me a lot about the approach Openmoko (https://en.wikipedia.org/wiki/Openmoko https://en.wikipedia.org/wiki/Openmoko) took way back over a decade ago, except that they did have to build the hardware as well.
  - neilv 7y ago
    There've been several such prominent open source handheld projects in the last 20 years. PostmarketOS seems the most viable, IMHO, because it emphasizes the old Linux (and GNU) principles of getting working on lots of available hardware, with true open source, mainlined. (Separately, it also potentially builds on a wealth of GNU/Linux stuff that there's no good reason shouldn't have a lot of commonality between desktop and handheld.)
Funes- 7y ago
PostmarketOS in tandem with the Pinephone[0] should be a great choice in the future. [0]: https://www.pine64.org/pinephone/ https://www.pine64.org/pinephone/.

huahe 7y ago

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 http://slash-r-slash-rust.github.io/archived/2u1dme.html do you have a comment

dang 7y ago
Please don't use HN to promote personal attacks. It damages the community, regardless of how badly someone might have behaved in another context. We detached this comment from https://news.ycombinator.com/item?id=20149702 https://news.ycombinator.com/item?id=20149702 and marked it off-topic.

ThinkBeat 7y ago

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?

astazangasta 7y ago
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?
- opencl 7y ago
  If you have a phone with T-Mobile spyware then it almost certainly also has a locked bootloader with no official unlock method. What are you expecting people developing alternate OSes to do about that? 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.
  - skrowl 7y ago
    To clarify, some of the phones you can buy directly from T-Mobile can also be bought "unlocked" in the open market. In general, if you want any hope of unlocking your phone (either for use on other carriers or unlocking the bootloader) then you should NOT buy from the carriers' online or brick & mortar stores.
- gibspaulding 7y ago
  Unfortunately all you can really do is pick up a different phone. Luckily finding an old unlocked Nexus 5 or OnePlus One on ebay is pretty easy and relatively cheap.
- kevin_thibedeau 7y ago
  Stop buying telco subsidized phones.

markstos 7y ago

I can see what the focus is, but I couldn't find a page that clearly spelled out differences with AOSP. I realize that's a missing target, but as a potential user it's interesting to know how it's going to be different than stock Android (beyond what the "focus" is).

dvduval 7y ago

Would this be something Huawei might get into?

_Ender 7y ago
Huawei could probably do something similar, however they still can't access the Google Play Store and such, therefore leaving them in a problematic area. For instance, though somewhat substantial, the Amazon store is quite pitiful in comparison to Google Play. Huawei could attempt to make a store but it won't have the world of apps that already exist on the Play Store. This would work in China though, since they don't have the Play Store in the first place.

rplnt 7y ago

What does it matter if you are still running proprietary software with direct memory and CPU access on your network, camera, ... Android can give you privacy and enough security for most people. This can't add much more as long as its running on the same devices. This is a great effort and I support it, but let's not imagine this will make our phones that much more secure.

yegortimoshenko 7y ago
For reference, this concern has been addressed here: https://news.ycombinator.com/item?id=20149112 https://news.ycombinator.com/item?id=20149112
strcat 7y ago
Open source is a development model and doesn't have magical privacy and security properties. An iPhone is going to remain the best overall option for privacy and security for the near future, especially for users that aren't very technical. That's not really in spite of it being almost entirely proprietary but rather that's something quite orthogonal to it. GrapheneOS aims to provide a much more private and secure option down the road, but it's trying to do that based on merit rather than by claiming that being open source makes it better. Either way, the any ARM SoC is going to be a massively complex set of proprietary hardware / firmware / microcode. An open hardware SoC wouldn't provide inherently better privacy or security, and unlike software you wouldn't even be able to reproduce the build and verify that it matches what it's supposed to be. In reality, that provides very little for software, because sources are full of vulnerabilities and it being open source doesn't magically fix them. A maliciously inserted backdoor designed to be stealthy would be indistinguishable from those, and it's nearly impossible to know how many of the vulnerabilities being fixed in software were intentionally inserted backdoors, if any. A sophisticated attacker in a position to insert a backdoor into hardware or software could just use the existing vulnerabilities, and if they did insert a backdoor how would you distinguish it from one of those? Components with DMA can be contained by IOMMU, and that's the industry standard today. However, you seem to be implying that backdoors are being inserted into non-CPU SoC components, and it's very hard to understand the threat model you're applying to this. Why would there even be a backdoor inserted into an SoC component like the image processor, which is contained by the IOMMU, rather than the CPU? These SoC components aren't third party components. They're on the same die as the CPU and come with it. That doesn't mean they can freely access all memory... but it does mean that supply chain attacks targeting them would generally be able to target the CPU instead. If a hardware component is compromised, an attacker would target the driver and gain code execution in the Linux kernel via an exploit. The Linux kernel is a weak target (monolithic - no internal security boundaries, fully written in a memory unsafe language) and drivers are rarely well hardened against attacks from hardware since developers have a tendency to trust it and to not apply an adversarial model towards it as they do with userspace. They don't need unrestricted DMA access, and proper IOMMU setup keeps them from having that. Having DMA does not mean having full control over all memory. Not having DMA doesn't mean that the component is well isolated. Whether or not the component is on the same die is totally orthogonal to whether it has DMA access. These are common misconceptions, and are being abused by dishonest marketing to trick people. > Android can give you privacy and enough security for most people. Some of that is due to the improvements landed upstream based on the work in this project. > This can't add much more as long as its running on the same devices. I don't agree with that at all. It can't improve the security of firmware directly, but it can certainly improve the isolation of it by auditing and improving IOMMU configuration along with hardening the drivers. It also won't be supporting devices without decent IOMMU support and firmware security updates. The project has also reported various firmware security issues to the relevant companies over the years of the project, so that's an indirect way of improving them. A large portion of the project will also be on app layer projects like https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor usable on the stock OS and other operating systems. Auditor / AttestationServer support the stock OS on a bunch of devices, along with CalyxOS and GrapheneOS. Other apps will generally be more portable, but in this case it has to have a database of the verified boot key fingerprints and other device properties. The verified boot key is the only information included in the signed hardware attestation data that it can use to distinguish between devices which it needs to do in order to show the device model and apply different checks based on the device. That's why devices need to be added to Auditor one-by-one based on users submitting sample attestations with the app.

mlinksva 7y ago

https://grapheneos.org/#roadmap https://grapheneos.org/#roadmap is pretty interesting: > Details on the roadmap of the project will be posted on the site in the near future. In the long term, it aims to move beyond a hardened fork of the Android Open Source Project. Achieving the goals requires moving away from relying the Linux kernel as the core of the OS and foundation of the security model. It needs to move towards a microkernel-based model with a Linux compatibility layer, with many stepping stones leading towards that goal including adopting virtualization-based isolation.

strcat 7y ago
Strengthening the security with virtualization is something that's in the early stage of experimentation and research and will be a long-term project. Over the long term though, the goal is moving away from having the Linux kernel completely other than as the native API / ABI for apps. Projects like https://github.com/google/gvisor https://github.com/google/gvisor are very promising in that regard even if they end up playing no part in how this eventually happens for GrapheneOS. A clearer and much more detailed roadmap will be posted soon. The site is still very newly created and barely has any information about the project. Essentially, the goal for the project is for it to be an OS compatible with Android apps, using the Android Open Source Project software stack to run them, but the underlying base can become whatever is most suited to the task. For now, the most practical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too. I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS. The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.

samirm 7y ago

how does this compare with something like microG?

0xdeadb00f 7y ago
It doesn't compare because microG isn't an Android "ROM" - you can't compare the two.
- black_puppydog 7y ago
  You most certainly can! Microg is a (very welcome!) band-aid for the fact that the android ecosystem is critically dependent on a proprietary piece of software called play services. PMO is a different, libre, OS and ecosystem that doesn't have that problem to begin with since it is truly a Linux (as opposed to AOSP) and truly free (as opposed to android's "can read most code but Google holds all the cards")
  - strcat 7y ago
    There's a far larger app ecosystem for Android without Play Services than any other mobile OS. It's very odd to try to claim that it doesn't have that problem. Android is truly a Linux distribution too, and is truly free software. You can promote your preferred mobile OS without making misleading claims.

xaduha 7y ago

Stock-ish Android that gets updates is good enough for me. I'm looking forward to wider support of U2F over NFC in general though, I don't keep data on the phone itself. You can buy a contactless smartcard for $15 each and install this on it https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F

_Ender 7y ago

"Android compatibility" implies that it's something entirely new. It appears to be an Android fork that simply hasn't done away with compatibility. There are neat ideas and all, but the title implies that it's something that it isn't. Lastly, I wonder how this will do over time considering Fuschia.

strcat 7y ago
It's not implied that it's something completely new, although a dozen of the sub-projects are new projects rather than forks of existing ones. The overall project is not simply a fork of the Android Open Source Project with hardening. That's a subset of the work, and a big part of it. I also added a paragraph to the placeholder index page clarifying the longer-term plans with virtualization: https://grapheneos.org/#roadmap https://grapheneos.org/#roadmap. GrapheneOS includes sub-projects including standalone projects like https://github.com/GrapheneOS/Auditor https://github.com/GrapheneOS/Auditor and https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc that are portable to other operating systems. This also applies to a lot of work that's under active development and not yet published as part of the stable releases. It intentionally doesn't stick to the Compatibility Definition Document / Compatibility Test Suite requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them. > Lastly, I wonder how this will do over time considering Fuschia. If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.
- _Ender 7y ago
  I get that, and the site doesn't imply that it's something new, but I simply found the title of the post to be such. Fair enough though. >If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though. I see.

nerd7473 7y ago

I need to try this, I also need to get a Librem 5, and build my project for it. Anyone know of any good projects for replacing google services with FOSS services that do the same basic things?

danvittegleo 7y ago

For anyone interested in doing their own customizable builds of AOSP for Pixel devices check out: https://github.com/dan-v/rattlesnakeos-stack https://github.com/dan-v/rattlesnakeos-stack. This doesn't have any of the security hardening features of GrapheneOS, but does have some of the same security properties like verified boot, OTA software updates that included updated firmware/drivers, support for remote attestation, etc.

julienfr112 7y ago

Is that like the real thing (graphene) and can do anything but go out of the lab ?

tdxcbkif 7y ago

How does graphene compare to linage os?

techsin101 7y ago

I shouldnt be commenting. But os with new kernel like chrome os would be ideal for security, privacy and performance. Only thing left is open hardware not sure how to go about it.

okanesatoshi 7y ago

Why use utility token? Coin Circle a state of utility token, get a chance to win $500 USD daily contest at https://coincircle.com/l/1RQBJ6CRKU https://coincircle.com/l/1RQBJ6CRKU