From 73223bfda89aee0da0c9d542fdc90bff89d7d34a Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Sun, 6 Dec 2020 12:27:24 -0500 Subject: [PATCH] use explicit sections on the main page --- static/index.html | 284 +++++++++++++++++++++++----------------------- 1 file changed, 142 insertions(+), 142 deletions(-) diff --git a/static/index.html b/static/index.html index 17d5f0bb..783e68bc 100644 --- a/static/index.html +++ b/static/index.html @@ -118,165 +118,165 @@ href="https://attestation.app/tutorial">tutorial. These also support other operating systems.

-

- No Google apps or services -

+
+

No Google apps or services

-

GrapheneOS will never include either Google Play services or another implementation - of Google services like microG. Those are not part of the Android Open Source Project - and are not required for baseline Android compatibility. Apps designed to run on - Android rather than only Android with bundled Google apps and services already work on - GrapheneOS, so a huge number of both open and closed source apps are already available - for it.

+

GrapheneOS will never include either Google Play services or another implementation + of Google services like microG. Those are not part of the Android Open Source Project + and are not required for baseline Android compatibility. Apps designed to run on + Android rather than only Android with bundled Google apps and services already work on + GrapheneOS, so a huge number of both open and closed source apps are already available + for it.

-

AOSP APIs not tied to Google but that are typically provided via Play services will - continue to be implemented using open source providers like the Seedvault backup app. - Text-to-speech, voice-to-text, non-GPS-based location services, geocoding, - accessibility services, etc. are examples of other open Android APIs where we need to - develop/bundle an implementation based on existing open source projects. GrapheneOS is - not going to be implementing these via a Google service compatibility layer because - these APIs are in no way inherently tied to Google services.

+

AOSP APIs not tied to Google but that are typically provided via Play services will + continue to be implemented using open source providers like the Seedvault backup app. + Text-to-speech, voice-to-text, non-GPS-based location services, geocoding, + accessibility services, etc. are examples of other open Android APIs where we need to + develop/bundle an implementation based on existing open source projects. GrapheneOS is + not going to be implementing these via a Google service compatibility layer because + these APIs are in no way inherently tied to Google services.

-

We're developing support for installing microG as a regular app without any special - privileges. This will allow users to choose to use a partial reimplementation of Play - services in a specific profile. We won't be supporting arbitrary signature spoofing by - microG or any other app since it seriously compromises the OS security model. Guarding - it by a permission isn't enough, both because users don't understand the substantial - impact on the security model and it weakens security for the verified boot threat - model where persistent state such as granted permissions is controlled by an attacker. - Instead, the OS will specifically make microG signed with our microG signing key - appear to other apps as signed with the Google Play services key. It won't bypass any - other signature checks, only a check for Play services, and other apps also won't be - able to pretend to be Play services to intercept FCM messages, obtain Google - credentials, etc. It will not be granted any privileged permissions or other special - capabilities unavailable to a regular untrusted app.

+

We're developing support for installing microG as a regular app without any special + privileges. This will allow users to choose to use a partial reimplementation of Play + services in a specific profile. We won't be supporting arbitrary signature spoofing by + microG or any other app since it seriously compromises the OS security model. Guarding + it by a permission isn't enough, both because users don't understand the substantial + impact on the security model and it weakens security for the verified boot threat + model where persistent state such as granted permissions is controlled by an attacker. + Instead, the OS will specifically make microG signed with our microG signing key + appear to other apps as signed with the Google Play services key. It won't bypass any + other signature checks, only a check for Play services, and other apps also won't be + able to pretend to be Play services to intercept FCM messages, obtain Google + credentials, etc. It will not be granted any privileged permissions or other special + capabilities unavailable to a regular untrusted app.

-

In the longer term, we also plan to offer a more minimal compatibility layer which - pretends that Google services are offline rather than implementing them. Users will - have the choice between no implementation of Play services, microG and this minimal - implementation not implementing Google services. This choice will be available because - we won't be bundling any of this into the OS. Ideally, Google themselves would support - installing the official Play services as a regular Android app, rather than taking the - monopolistic approach of forcing it to be bundled into the OS in a deeply integrated - way with special privileged permissions and capabilities unavailable to other cloud - service providers competing with them.

+

In the longer term, we also plan to offer a more minimal compatibility layer which + pretends that Google services are offline rather than implementing them. Users will + have the choice between no implementation of Play services, microG and this minimal + implementation not implementing Google services. This choice will be available because + we won't be bundling any of this into the OS. Ideally, Google themselves would support + installing the official Play services as a regular Android app, rather than taking the + monopolistic approach of forcing it to be bundled into the OS in a deeply integrated + way with special privileged permissions and capabilities unavailable to other cloud + service providers competing with them.

+
-

- History -

+
+

History

-

GrapheneOS was founded by Daniel Micay in late 2014. It started as a solo project - incorporating his previous open source privacy/security work. The project initially - created a port of OpenBSD malloc to Android's Bionic libc and a port of the PaX kernel - patches to the kernels for the supported devices. It quickly expanded to having a - large set of homegrown privacy and security improvements, particularly low-level - hardening work on the compiler toolchain and Bionic. Work began on landing code - upstream in AOSP and other upstream projects. A substantial portion of these early - changes were either successfully landed upstream or heavily influenced the upstream - changes which replaced them. The project was able to move very quickly in these days - because there was so much low hanging fruit to address and it wasn't yet trying to - produce a highly robust, production quality OS.

+

GrapheneOS was founded by Daniel Micay in late 2014. It started as a solo project + incorporating his previous open source privacy/security work. The project initially + created a port of OpenBSD malloc to Android's Bionic libc and a port of the PaX kernel + patches to the kernels for the supported devices. It quickly expanded to having a + large set of homegrown privacy and security improvements, particularly low-level + hardening work on the compiler toolchain and Bionic. Work began on landing code + upstream in AOSP and other upstream projects. A substantial portion of these early + changes were either successfully landed upstream or heavily influenced the upstream + changes which replaced them. The project was able to move very quickly in these days + because there was so much low hanging fruit to address and it wasn't yet trying to + produce a highly robust, production quality OS.

-

In late 2015, a company was incorporated which became the primary sponsor of the - project. GrapheneOS was previously known as CopperheadOS while it was sponsored by - this company. The intention was to use the company to build a business around - GrapheneOS selling support, contract work and customized proprietary variants of the - OS. The company was supposed to serve the needs of the open source project, rather - than vice versa. It was explicitly agreed that GrapheneOS would remain independently - owned and controlled by Daniel Micay. This company failed to live up the promises and - is no longer associated in any way with GrapheneOS. The fact that the company was - accidentally founded as 'Coppperhead Limited' was just the beginning of a multi-year - trainwreck holding back and poisoning a successful open source project it ended up - leeching off rather than supporting.

+

In late 2015, a company was incorporated which became the primary sponsor of the + project. GrapheneOS was previously known as CopperheadOS while it was sponsored by + this company. The intention was to use the company to build a business around + GrapheneOS selling support, contract work and customized proprietary variants of the + OS. The company was supposed to serve the needs of the open source project, rather + than vice versa. It was explicitly agreed that GrapheneOS would remain independently + owned and controlled by Daniel Micay. This company failed to live up the promises and + is no longer associated in any way with GrapheneOS. The fact that the company was + accidentally founded as 'Coppperhead Limited' was just the beginning of a multi-year + trainwreck holding back and poisoning a successful open source project it ended up + leeching off rather than supporting.

-

In 2018, the company was hijacked by the CEO who attempted to take over the project - through coercion, but they were rebuked. They seized the infrastructure and stole the - donations, but the project successfully moved on without them and has been fully - revived. Since then, they've taken to fraudulently claiming ownership and authorship - of our work, which has no basis in fact. They've tried to retroactively change the - terms of their involvement and rewrite the history of the project. These claims are - easily falsified through the public record and by people involved with the open source - project and the former sponsor. This former sponsor has engaged in a campaign of - misinformation and harassment of contributors to the project. Be aware that they are - actively trying to sabotage GrapheneOS and are engaging in many forms of attacks - against the project, the developers, contributors and supporters. Meanwhile, they - continue profiting from our open source work which they falsely claim as their own - creation.

+

In 2018, the company was hijacked by the CEO who attempted to take over the project + through coercion, but they were rebuked. They seized the infrastructure and stole the + donations, but the project successfully moved on without them and has been fully + revived. Since then, they've taken to fraudulently claiming ownership and authorship + of our work, which has no basis in fact. They've tried to retroactively change the + terms of their involvement and rewrite the history of the project. These claims are + easily falsified through the public record and by people involved with the open source + project and the former sponsor. This former sponsor has engaged in a campaign of + misinformation and harassment of contributors to the project. Be aware that they are + actively trying to sabotage GrapheneOS and are engaging in many forms of attacks + against the project, the developers, contributors and supporters. Meanwhile, they + continue profiting from our open source work which they falsely claim as their own + creation.

-

After splitting from the former sponsor, the project was rebranded to - AndroidHardening and then to GrapheneOS and it has continued down the original path of - being an independent open source project. It will never again be closely tied to any - particular sponsor or company.

+

After splitting from the former sponsor, the project was rebranded to + AndroidHardening and then to GrapheneOS and it has continued down the original path of + being an independent open source project. It will never again be closely tied to any + particular sponsor or company.

+
- + -

- Roadmap -

+
+

Roadmap

-

Details on the roadmap of the project will be posted on the site in the near - future.

-

To get an idea of the near term roadmap, check out the - issue trackers. The vast majority of the - issues filed in the trackers are planned enhancements, with care taken to make sure - all of the issues open in the tracker are concrete and actionable.

-

In the long term, GrapheneOS aims to move beyond a hardened fork of the Android - Open Source Project. Achieving the goals requires moving away from relying on 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.

-

The initial phase for the long-term roadmap of moving away from the current - foundation will be to deploy and integrate a hypervisor like Xen to leverage it for - reinforcing existing security boundaries. Linux would be running inside the virtual - machines at this point, inside and outside of the sandboxes being reinforced. In the - longer term, Linux inside the sandboxes can be replaced with a compatibility layer - like gVisor, which would need to be ported to arm64 and given a new backend alongside - the existing KVM backend. Over the longer term, i.e. many years from now, Linux can - fade away completely and so can the usage of virtualization. The anticipation is that - many other projects are going to be interested in this kind of migration, so it's not - going to be solely a GrapheneOS project, as demonstrated by the current existence of - the gVisor project and various other projects working on virtualization deployments - for mobile. Having a hypervisor with verified boot still intact will also provide a - way to achieve some of the goals based on extensions to Trusted Execution Environment - (TEE) functionality even without having GrapheneOS hardware.

-

Hardware and firmware security are core parts of the project, but it's currently - limited to research and submitting suggestions and bug reports upstream. In the long - term, the project will need to move into the hardware space.

+

Details on the roadmap of the project will be posted on the site in the near + future.

+

To get an idea of the near term roadmap, check out the + issue trackers. The vast majority of the + issues filed in the trackers are planned enhancements, with care taken to make sure + all of the issues open in the tracker are concrete and actionable.

+

In the long term, GrapheneOS aims to move beyond a hardened fork of the Android + Open Source Project. Achieving the goals requires moving away from relying on 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.

+

The initial phase for the long-term roadmap of moving away from the current + foundation will be to deploy and integrate a hypervisor like Xen to leverage it for + reinforcing existing security boundaries. Linux would be running inside the virtual + machines at this point, inside and outside of the sandboxes being reinforced. In the + longer term, Linux inside the sandboxes can be replaced with a compatibility layer + like gVisor, which would need to be ported to arm64 and given a new backend alongside + the existing KVM backend. Over the longer term, i.e. many years from now, Linux can + fade away completely and so can the usage of virtualization. The anticipation is that + many other projects are going to be interested in this kind of migration, so it's not + going to be solely a GrapheneOS project, as demonstrated by the current existence of + the gVisor project and various other projects working on virtualization deployments + for mobile. Having a hypervisor with verified boot still intact will also provide a + way to achieve some of the goals based on extensions to Trusted Execution Environment + (TEE) functionality even without having GrapheneOS hardware.

+

Hardware and firmware security are core parts of the project, but it's currently + limited to research and submitting suggestions and bug reports upstream. In the long + term, the project will need to move into the hardware space.

+
-

- Device support -

+
+

Device support

-

See the FAQ section on device support.

+

See the FAQ section on device support.

+