[neilv]

A very condensed version of the messy CopperheadOS implosion is: 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).

[strcat]

The Android Open Source Project is the only viable starting point. I don't know what else you would suggest. It has solid privacy and security as a baseline already, unlike other mobile or desktop Linux-based operating systems. There's also a huge amount of public security research targeting it for both offensive and defensive work. Moving to the desktop Linux stack would drastically set back both privacy and security. It would take a decade of work by dozens of programmers just to catch up, and the goal of the project is advancing the status quo rather than trying to play catch up to it for years. The goal is not creating a new ecosystem for applications and convincing developers to target it, especially if it would be for no particular reason. It needs an existing application ecosystem, so Android app compatibility is of utmost importance.

Having a massive monolithic kernel at the core of the operating system written entirely in a memory unsafe language is obviously a huge problem, and will need to be addressed over the long term. It's an increasingly blatant weakness, and the enormous amount of ongoing work that has gone into userspace doesn't translate well to the kernel. Developing increasingly more sophisticated mitigations helps a bit, but it can't solve the fundamental issues with the choice of language, architecture or development process. Linux ultimately isn't a viable choice for creating a system with decent security. However, Linux compatibility is part of Android compatibility and is essential. That means the Linux kernel either has to be kept around in virtual machines or replaced with a compatibility layer on top of a microkernel. https://github.com/google/gvisor is an existing project which could be ported to arm64, expanded as needed and adjusted to run on top of another kernel but it doesn't need to be the starting point. It's usually a good idea to start from an existing base like this and try to land everything needed upstream though, rather than burning far more resources starting from scratch and losing out on the shared benefits from collaboration with a larger community.

Using virtualization is a nearer term goal, with a compatibility layer as a much longer term aspiration. There's not much written about the roadmap on the linked page, but this stuff is actually mentioned, and I'd recommend checking it out before wrongly assuming that the goal is simply having a hardened fork of AOSP. There has already been substantial work on experimenting with integrating virtualization for app containment, although containing user profiles would be another approach and potentially more useful.

[nickpsecurity]

That's what OK Labs did before GD bought them:

https://web.archive.org/web/20111130031013/http://www.ok-lab...

CompSci folks have been doing it, too. Here's a paper describing the design style:

https://os.inf.tu-dresden.de/papers_ps/nizza.pdf

Genode OS Framework is only one I know building something like this in FOSS. The rest, esp used in phones, were commercial. One might port Android to something like it or seL4 with dynamic, resource management. Rewrite drivers or anything that's moved to kernel mode for performance in safe language or lots of verification tooling thrown at it.

[eeZah7Ux]

> Linux ultimately isn't a viable choice for creating a system with decent security.

Stop spreading FUD. In this conversation we are talking about phones filled with bloatware that spies on the user in every instant and you nitpick about memory safety in the kernel.

[strcat]

I'm not spreading FUD, and the conversation isn't about what you claim. Talking about the lack of basic security on existing operating systems based on monolithic kernels written in memory unsafe languages is hardly nitpicking. It's the kind of stuff that GrapheneOS is all about... which is what this entire is about.

[duxup]

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.

[neilv]

Edit: Voluntarily replaced with...

I had summarized public information and questions from as the implosion was happening, trying to be impartial and not voice my guesses as to what actually went on, and concluded that everyone should be given the benefit of the doubt, given all the unknowns.

But that impartiality could be upsetting to one of the parties (by bringing up things that, say, a good guy maybe can't talk about), and maybe this isn't the time, as people are recovering and moving forward.

At the same time, HN people might need to know some lessons from this noteworthy incident in development and privacy&security, since it should inform how we think about how other projects and startups can fail.

For example: a prominent security product can suddenly be compromised (e.g., in the sense of trusted security update mechanism broken, or a change in who controls updates), or a business partner can force out you and your intentions/stewardship of the product that you think depends on you being in the loop to not be evil, or a different business partner can delete very important keys, or (vaguely) this is another way it can be difficult to reconcile privacy&security goals with business ones.

These failures might be things we briefly consider as hypotheticals when planning or evaluating, but they do happen, in real life, on prominent efforts.

[strcat]

The open source project was started before Copperhead existed and long before it was incorporated. The project was never directly owned or controlled by the company, as that was an explicit condition of the collaboration with the company. GrapheneOS is the continuation of that original project, but a lot has been learned and it will never become associated with another company or organization to the same extent. The purpose and values behind the project were eroded by the association with a company focused on a business model. It was a problematic relationship long before you heard about it and eventually Copperhead betrayed the project. You can see for yourself that they made a bunch of ultimatums and threats trying to take over the project and end the independence from the company. They failed at doing that, but they succeeded at hijacking all of the infrastructure and preventing it from ever pushing out another update to the existing installs. The OS was never compromised, but it lost all of the infrastructure and resources supporting it so it has taken a long time to even get some basics back up and running. Most of the initial focus after the disaster was on standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor. It took a long time to get things back up and running, and it has definitely been massively set back both not only in terms of the development work but also in many other ways. It has still managed to continue onwards and while the OS itself hasn't been fully restored, there's a bunch of useful standalone work that's far better than anything the project offered in the past.

You're substantially misrepresenting the events that occurred based on a very incomplete account of the events that you've seen. People seeing your comment are going to end up with an incorrect understanding, just as you did. You're stating your assumptions and misconceptions about what happened as if they're facts. It's a very incorrect account of a very small part of the story. This game of broken telephone where people misinform themselves and then propagate variations of that to many other people is a poor way of spreading knowledge.

[duxup]

I don't think he's representing or misrepresenting much at all. Most of his comment (like mine) talks about what we don't know and asks questions, and like mine admits it would be hard to know anything even if we were told what "really" happened.

>It was a problematic relationship long before you heard about it

Probably day 1 as it sounds like there was a fundamental conflict with the business and non business entities, I don't get what anyone thought such an arrangement would really do that would be positive. Hopefully everyone learned from their experience, can do some good work now, and can avoid such things in the future.

[strcat]

The business wasn't supposed to be entirely based around my open source project. It was a security consulting company.

[duxup]

Agreed. It is so strange how it just sort of "happened" generally I don't think such things usually just happen out of nowhere, so half the story I think would how everyone came together to work together and then end up in a situation that was as apocalyptic as far as how it played out for the project.

[robotbikes]

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]

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]

That is how ChromeOS runs the new Linux sandbox, implemented in Rust.

Check the Google IO 2019 talk about Linux support on ChromeOS.