Apps using the Play Integrity API or
- obsolete
- SafetyNet Attestation API to check the authenticity/integrity of the OS can support
- GrapheneOS by using the standard Android hardware attestation API instead and
- permitting our official release signing keys. Android's
- hardware
- attestation API provides a much stronger form of attestation than the Play
- Integrity API with the ability to whitelist the keys of alternate operating systems.
- It also avoids an unnecessary dependency on Google Play services and Google's
- Play Integrity servers.
-
-
The standard hardware attestation API can be used to verify the authenticity/integrity
- of the hardware, firmware, OS and the app running on it. It provides a verified boot key
- fingerprint for the OS for permitting secure aftermarket operating systems. The app id,
- signing key fingerprint(s) and version code of the app enabling hardware attestation are
- included in the signed public key certificate for the generated key. This enables the
- app's service to make sure the app is genuine and unmodified along with chaining trust
- through the OS to the app which can sign messages with the attested hardware keystore
- key to prove they come from their app running on top of a verified OS, firmware and
- hardware. The only practical way to bypass hardware attestation is through exploiting
- the hardware keystore to obtain attestation signing keys, which is protected against by
- the ability to revoke keys that are being misused. Play Integrity API strong integrity
- level is directly based on the hardware key attestation API, but apps using it directly
- can support aftermarket operating systems, check the hardware attested OS patch level
- and other provided information. The hardware attestation API also supports pinning-based
- security instead of only root-based security where keys can be leaked and used to fake
- attestations. Apps can use pinning to establish a much higher security pairing with a
- specific device to obtain fresh attestations with a very high level security based on
- the security of the device's own hardware keystore rather than the overall ecosystem.
- Hardware attestation also doesn't require using any Google service beyond regularly
- fetching the list of revoked keys for root-based attestation. The app's service doesn't
- have to go down or start permitting anything if the Google services becomes unavailable
- or blocks the app from using it for one reason or another. Using hardware attestation is
- therefore more reliable and lower risk for apps.
-
-
Devices have been required to ship with hardware attestation support since Android
- 8. You can use hardware attestation on devices running Android 8 or later when the
- ro.product.first_api_level system property isn't set to 25 or below,
- which indicates they launched with Android 8 or later with hardware attestation
- support as a mandatory feature. On older devices, you can continue using the Play
- Integrity API. Some low quality devices shipped broken implementations of hardware
- attestation despite the requirement to have it working for CDD/CTS certification and
- the Play Integrity API currently still passes on those devices wrongly claiming them
- to be CTS certified. If you don't want to fail on those devices, then you can start
- with hardware attestation and fall back to the Play Integrity API or do both and
- accept either passing as success.
-
-
Google provides a key
- attestation library with examples. Our MIT
- / Apache 2 licensed Auditor app can be used as a reference implementation for
- verifying hardware-based attestations. There are some subtleties in the verification
- process such as making sure only the 2nd certificate in the chain (the one signing the
- certificate for the key generated by your app) has an attestation extension to prevent
- making a fake attestation by extending the chain. You can reuse our code and simply
- omit support for an app generated attestation signing key (attest key) and the other
- pinning support.
-
-
After verifying the signature of the attestation certificate chain and extracting
- the attestation metadata, you can enforce that verifiedBootState is
- either Verified or SelfSigned. For the
- SelfSigned case, you can check that verifiedBootKey matches
- one of the official GrapheneOS verified boot keys. These are the base16-encoded
- verified boot key fingerprints for the official GrapheneOS releases:
The verifiedBootKey field is binary data so you either need to encode
- it as base16 to compare with these or convert these to binary. An easy approach is
- storing the permitted key fingerprints in a set and enforcing that the verified boot
- key is in the permitted set when verifiedBootState is
- SelfSigned.
-
-
GrapheneOS regularly adds support for new devices so you should have a process for
- regularly adding the new verified boot key fingerprints from this page.
-
-
The hardware attestation API also provides other useful information signed by the
- hardware including the OS patch level, in a way that even an attacker exploiting the
- OS after boot to gain root cannot trivially bypass. It's a better feature than the
- Play Integrity API which has to be designed for the lowest common denominator.
-
-
GrapheneOS users are strongly encouraged to share this documentation with app
- developers enforcing only being able to use the stock OS. Send an email to the
- developers and leave a review of the app with a link to this information. Share it
- with other users and create pressure to support GrapheneOS rather than locking users
- into the stock OS without a valid security reason. GrapheneOS not only upholds the
- app security model but substantially reinforces it, so it cannot be justified with
- reasoning based on security, anti-fraud, etc.
TK-App (German health insurance app which uses it for fingerprint login)
-
IO (Italian government app which uses it for the digital wallet feature)
-
-
-
In addition to leaving feedback for these apps on the Play Store, file support
- requests and leave feedback on third party review sites. Ask them to stop banning
- GrapheneOS and explain that it's a much more secure OS than what they permit which
- does not lose any of the standard security model. Explain that they can use the
- hardware key attestation API to verify that a device is running GrapheneOS to permit
- it alongside an OS licensing Google apps as they do with the Play Integrity API
- already. Make sure to push back against false claims that it has something to do
- with compatibility or security issues. The only reason they aren't permitting it is
- because we do not license Google Mobile Services (GMS) and these apps are enforcing
- Google's business interests rather than security.
This is a detailed list of the public GrapheneOS servers.
-
-
We use hardened local machines for building and signing rather than servers outside
- our physical control, so information on that infrastructure is outside the scope of this
- page but may be provided in the future elsewhere.
These are the static file servers for GrapheneOS releases and our app
- repository. These are used by the releases page and web installer along with the
- System Updater and App Store (app repository client) within the OS.
These are the default servers used by GrapheneOS for connectivity checks,
- secure network time, attestation key provisioning and Predicted Satellite Data
- Service (PSDS). These either serve empty responses or provide reverse proxies to
- other services.
broadcom.psds.grapheneos.org - HTTPS Broadcom PSDS data cache
-
samsung.psds.grapheneos.org - HTTPS Samsung PSDS data cache
-
qualcomm.psds.grapheneos.org - HTTPS Qualcomm PSDS data cache
-
remoteprovisioning.grapheneos.org - HTTPS reverse proxy to remoteprovisioning.google.com
-
widevineprovisioning.grapheneos.org - HTTPS reverse proxy for Widevine provisioning
-
time.grapheneos.org - HTTPS time server with millisecond precision X-Time header
-
supl.grapheneos.org - TLS reverse proxy to supl.google.com
-
nominatim.grapheneos.org - HTTPS reverse proxy to nominatim.openstreetmap.org, which will become our own instance of Nominatim instead of a proxy
-
gs-loc.apple.grapheneos.org - HTTPS reverse proxy to Apple's network location service, which will remain an option after we have our own location service
-
update.vanadium.app - HTTPS reverse proxy to update.googleapis.com for Chromium component updates (will be hosted directly in the future)
-
dl.vanadium.app - HTTPS reverse proxy to CDNs for Chromium component updates (will be hosted directly in the future)
This server primarily runs the synapse Matrix server with PostgreSQL behind an
- nginx web server. It also runs the mjolnir bot for moderation and matterbridge is
- used to implement a bridge between Matrix, IRC and Telegram.
The Positon location service is a proprietary and highly privacy invasive service
- created by developers tied to /e/OS with their funding. There's a deliberate effort to
- hide that it's tied to them in order to convince other projects to adopt it, as opposed
- to using the similar service they host for /e/OS itself. Using the service requires
- uploading sensitive location data to obtain location estimates, similar to the Apple and
- Google location services. As with the Apple and Google services, it's a centralized
- proprietary service with fully proprietary data. Unlike those services, the people
- behind it have a history of publishing notoriously insecure software such as the /e/OS
- operating system itself which massively rolls back standard security, lags years behind
- on security updates and covers all of that up. They blatantly scam their users with
- false privacy/security claims for /e/OS, and nothing different should be expected from a
- location service from the same group of people. Multiple people involved in it are also
- actively participating in harassment targeting privacy/security researchers and
- engineers including but not limited to GrapheneOS team members.
-
-
The people behind the Positon location service have repeatedly talked about the
- importance they see in centralizing the whole open source community around using their
- service while locking out alternatives to it through proprietary data. They have spread
- fear, uncertainty and doubt about making services using open mapping data through
- claiming that it's a privacy hazard for people to have access to maps of Wi-Fi networks
- publicly broadcasting their SSID despite that data already being available through many
- commercial providers including publicly queryable databases such as Wigle. Anyone can
- drive around building these maps and many companies have already built them, with the
- data available for sale, as Positon shows with them obtaining access to it. The real
- privacy hazard is sending your location in real time to a service, particularly a poorly
- secured one from people known to cover up and downplay vulnerabilities. Positon has been
- built to grab as much market share as possible early on before actual open options can
- emerge and gather the necessary data.
-
-
The people involved in Positon have only ever cared about their careers, power and
- influence. They've consistently been on a side against real privacy and security, but
- rather focused on monetizing people's demand for it and grabbing as much market share as
- they can as quickly as they can with endless false marketing and attacks on projects
- like GrapheneOS. They see GrapheneOS as a huge threat to them due to us striving to
- bring people real privacy and security at no cost, which is far easier to obtain and
- use. This invalidates the business model of their companies like Murena. They
- consistently use their non-profits mainly as a way to earn money and promote their
- for-profit initiatives.
-
-
The service claims to be free of charge, but a core goal is turning it into a way to
- get data from users to build their own database that's largely not going to be available
- for use by others. Using it is helping them build a future business at the expense of
- user privacy, little different from the Apple and Google services. This is not what the
- open source community needs from a location service. The claims of no strings attached
- and the implication that it's open are nonsense. Storing as little data as possible
- would mean using local database for the region, not a network-based service. They're
- opposed to doing a local service well rather than it being their long term goal. They
- explicitly aim to lock out other alternatives and deter local location detection via
- Wi-Fi.
This article covers implementing server traffic shaping on Linux with CAKE. The aim
- is to provide fair usage of bandwidth between clients and consistently low latency
- for dedicated and virtual servers provided by companies like OVH and others.
-
-
Traffic shaping is generally discussed in the context of a router shaping traffic
- for a local network with assorted clients connected. It also has a lot to offer on a
- server where you don't control the network. If you control your own infrastructure
- from the server to the ISP, you probably want to do this on the routers instead.
-
-
This article was motivated by the serious lack of up-to-date information on this
- topic elsewhere. It's very easy to implement on modern Linux kernels and the results
- are impressive from extremely simple test cases to heavily loaded servers.
A server will generally be provisioned with a specific amount of bandwidth
- enforced by a router in close proximity. This router acts as the bottleneck and
- ends up being in charge of most of the queuing and congestion decisions. Unless
- that's under your control, the best you can hope for is that the router is
- configured to use fq_codel as the queuing discipline (qdisc) to
- provide fair queuing between streams and low latency by preventing a substantial
- backlog of data.
-
-
Unfortunately, the Linux kernel still defaults to pfifo_fast
- instead of the much saner fq_codel algorithm. This is changed by a
- configuration file shipped with systemd, so most distributions using
- systemd as init end up with a sane default. Debian removes that configuration and
- doesn't set a sane default itself, and is widely used. Many server providers like
- OVH do not appear to consistently use modern queue disciplines like
- fq_codel within their networks, particularly at artificial
- bottlenecks implementing rate limiting based on product tiers.
-
-
If the bottleneck doesn't use fair queuing, division of bandwidth across
- streams is very arbitrary and latency suffers under congestion. These issues are
- often referred to as bufferbloat, and fq_codel is quite good at
- resolving it.
-
-
The fq_codel algorithm is far from perfect. It has issues with
- hash collisions and more importantly only does fair queuing between streams.
- Buffer bloat also isn't the only relevant issue. Clients with multiple connections
- receive more bandwidth and a client can open a large number of connections to
- maximize their bandwidth usage at the expense of others. Fair queuing is important
- beyond as a solution to bufferbloat and there's more to fair queuing than doing it
- only based on streams.
-
-
Traditionally, web browsers open a bunch of HTTP/1.1 connections to each server
- which ends up giving them an unfair amount of bandwidth. HTTP/2 is much friendlier
- since it uses a single connection to each server for the entire browser. Download
- managers take this to the extreme and intentionally use many connections to bypass
- server limits and game the division of resources between clients.
Linux 4.19 and later makes it easy to solve all of these problems. The CAKE
- queuing discipline provides sophisticated fair queuing based on destination and
- source addresses with finer-grained fairness for individual streams.
-
-
Unfortunately, simply enabling it as your queuing discipline isn't enough
- since it's highly unlikely that your server is the network bottleneck. You need to
- configure it with a bandwidth limit based on the provisioned bandwidth to move the
- bottleneck under your control where you can control how traffic is queued.
We've used an 100mbit OVH server for as a test platform for a case where
- clients can easily max out the server bandwidth on their own. As a very simple
- example, consider 2 clients with more than 100mbit of bandwidth each downloading a
- large file. These are (rounded) real world results with CAKE:
-
-
-
client A with 1 connection gets 50mbit
-
client B with 10 connections gets 5mbit each adding up to 50mbit
-
-
-
CAKE with flows instead of the default triple-isolate to
- mimic fq_codel at a bottleneck:
-
-
-
client A with 1 connection gets 9mbit
-
client B with 10 connections gets 9mbit each adding up to 90mbit
-
-
-
The situation without traffic shaping is a mess. Latency takes a serious hit
- that's very noticeable via SSH. Bandwidth is consistently allocated very unevenly
- and ends up fluctuating substantially between test runs. The connections tend to
- settle near a rate, often significantly lower or higher than the fair 9mbit
- amount. It's generally something like this, but the range varies a lot:
-
-
-
client A with 1 connection gets ~6mbit to ~14mbit
-
client B with 10 connections gets ~6mbit to ~14mbit each adding up to ~86mbit
- to ~94mbit
-
-
-
CAKE continues working as expected with a far higher number of connections. It
- technically has a higher CPU cost than fq_codel, but that's much more
- of a concern for low end router hardware. It hardly matters on a server, even one
- that's under heavy CPU load. The improvement in user experience is substantial and
- it's very noticeable in web page load speeds when a server is under load.
For a server with 2000mbit of bandwidth provisioned, you could start by trying
- it with 99.75% of the provisioned bandwidth:
-
-
tc qdisc replace dev eth0 root cake bandwidth 1995mbit besteffort
-
-
On a server, setting it to use 100% of the provisioned bandwidth may work fine
- in practice. Unlike a local network connected to a consumer ISP, you shouldn't
- need to sacrifice anywhere close to the typically recommended 5-10% of your
- bandwidth for traffic shaping.
-
-
This also sets besteffort for the common case where the server
- doesn't have appropriate Quality of Service markings set up via Diffserv. Fair
- scheduling is already great at providing low latency by cycling through the hosts
- and streams without needing this kind of configuration. The defaults for Diffserv
- traffic classes like real-time video are set up to yield substantial bandwidth in
- exchange for lower latency. It's easy to set this up wrong and it usually won't
- make much sense on a server. You might want to set up marking low priority traffic
- like system updates, but it will already get a tiny share of the overall traffic
- on a loaded server due to fair scheduling between hosts and streams.
-
-
You can use the tc -s qdisc command to monitor CAKE:
-
-
tc -s qdisc show dev eth0
-
-
If you want to keep an eye on how it changes over time:
-
-
watch -n 1 tc -s qdisc show dev eth0
-
-
This is very helpful for figuring out if you've successfully moved the
- bottleneck to the server. If the bandwidth is being fully used, it should
- consistently have a backlog of data where it's applying the queuing discipline.
- The backlog shouldn't be draining to near zero under full bandwidth usage as that
- indicates the bottleneck is the server application itself or a different network
- bottleneck.
-
-
If you use systemd-network, you can add a CAKE configuration section to the
- network configuration file instead of manually running the tc command
- with a Type=oneshot service on boot:
The Linux kernel can be tuned to more quickly propagate TCP backpressure up to
- applications while still maximizing bandwidth usage. This is incredibly useful for
- interactive applications aiming to send the freshest possible copy of data and for
- protocols like HTTP/2 multiplexing streams/messages with different priorities over
- the same TCP connection. This can also substantially reduce memory usage for TCP
- by reducing buffer sizes closer to the optimal amount for maximizing bandwidth
- use without wasting memory. The downside to quicker backpressure propagation is
- increased CPU usage from additional system calls and context switches.
-
-
The Linux kernel automatically adjusts the size of the write queue to maximize
- bandwidth usage. The write queue is divided into unacknowledged bytes (TCP window
- size) and unsent bytes. As acknowledgements of transmitted data are received, it
- frees up space for the application to queue more data. The queue of unsent bytes
- provides the leeway needed to wake the application and obtain more data. This can
- be reduced using net.ipv4.tcp_notsent_lowat to reduce the default and
- the TCP_NOTSENT_LOWAT socket option to override it per-socket.
-
-
A reasonable choice for internet-based workloads concerned about latency and
- particularly prioritization within TCP connections but unwilling to sacrifice
- throughput is 128kiB. To configure this, set the following in
- /etc/sysctl.d/local.conf or another sysctl configuration file and
- load it with sysctl --system:
-
-
net.ipv4.tcp_notsent_lowat = 131072
-
-
Using values as low as 16384 can make sense to further improve latency and
- prioritization. However, it's more likely to negatively impact throughput and will
- further increase CPU usage. Use at least 128k or the default of not limiting the
- automatic unsent buffer size unless you're going to do substantial testing to make
- sure there's not a negative impact for the workload.
-
-
If you decide to use tcp_notsent_lowat, be aware that newer Linux
- kernels (Linux 5.0+ with a further improvement for Linux 5.10+) are recommended to
- substantially reduce system calls / context switches by not triggering the
- application to provide more data until over half the unsent byte buffer is
- empty.
By default, CAKE splits General Segmentation Offload (GSO) super-packets to
- reduce latency at the expense of CPU efficiency and throughput. This can create a
- bottleneck at high link speeds. We've had to disable this on the 2Gbit GrapheneOS
- update servers.
Ideally, data centers would deploy CAKE throughout their networks with the
- default triple-isolate flow isolation. This may mean they need to use
- more powerful hardware for routing. If the natural bottlenecks used CAKE, setting
- up traffic shaping on the server wouldn't be necessary. This doesn't seem likely
- any time soon. Deploying fq_codel is much more realistic and tackles
- buffer bloat but not the issue of fairness between hosts rather than only
- streams.
The ads.txt specification
- provides a way to list the authorized sellers of ads for a domain. The
- app-ads.txt specification
- extends this to cover apps tied to the domain. As a domain owner, this is a valuable
- way to crack down on fraudulent usage of your domain including by adware.
-
-
For domains without any third party advertising including those without any ads at
- all, you should serve both /ads.txt and /app-ads.txt from a
- web server with the placeholder record defined by the specification:
The placeholder record formally disallows buying and selling ads on behalf of the
- domain including for any subdomains. This prevents fraudulently buying / selling ads
- for your domain anywhere that ads.txt / app-ads.txt are enforced.
-
-
It's in the interest of most ad tech companies to enforce these standards due to
- losses from ad fraud so adoption is increasingly widespread.
-
-
Browser extension malware injecting ads into sites is very common and this is a way
- for sites to hurt those malware developers where it hurts: their pocketbook.
-
-
These standards have a limited scope and were primarily created to address the cost
- of ad fraud for the advertising industry, but they do offer value for domain owners to
- protect their reputation and discourage adware.
GrapheneOS is an open source project supported via donations from individuals,
- companies and other organizations. Donations are used for paying developers,
- purchasing hardware (workstations, test devices, debugging cables/boards, etc.),
- paying for infrastructure (domains, virtual/dedicated servers) and paying legal
- fees.
-
-
The multiple ways to donate are listed in the sections on this page.
GrapheneOS can be sponsored with recurring or one-time donations via credit
- cards through GitHub
- Sponsors. There are standard tiers from $5 to $5,000 or you can donate a custom
- amount.
You can donate to the non-profit GrapheneOS Foundation via local bank transfers
- to our Wise account in the EU/SEPA, UK, US, Australia, New Zealand, Canada,
- Hungary and Turkey.
PayPal charges a base fee of 30 cents and 2.9% of the donation amount within
- Canada. There's an additional 0.8% fee for donations from the US and 1% for other
- countries. Currency conversion adds an additional 4% fee as opposed to the usual
- PayPal conversion fee of 3%.
If you have a Canadian bank account, you can send Canadian dollar donations to
- the non-profit GrapheneOS Foundation via Interac e-Transfer to
- contact@grapheneos.org. The email address has Interac e-Transfer
- Autodeposit support enabled so no security question is necessary. If your bank
- doesn't support Autodeposit, set the answer to the security question to
- GrapheneOS.
CopperheadOS was renamed to GrapheneOS in 2019. It was temporarily known as the
- Android Hardening project in 2018 before a permanent name had been chosen. For more
- details on why the project was renamed, see our history page.
- For the historical release notes of the original CopperheadOS, see
- our legacy changelog page. The
- /r/CopperheadOS subreddit was
- historically the central hub of the community along with a bridged IRC/Matrix channel
- that's no longer available.
-
-
GrapheneOS is the continuation of the original open source project by the original
- development team. Our source code repositories have been used
- since CopperheadOS transitioned to being directly based on the Android Open Source
- Project in 2015. The prior repositories predate the CopperheadOS branding and were
- also owned by us. It can be confirmed that our repositories are the original ones from
- the GitHub network graphs showing the forks over the years.
We own the historical CopperheadOS source code, documentation and accounts tied
- to the open source project. Our legacy Twitter account still needs to be returned
- to us so that it can be renamed and made into an archive.
-
-
Copperhead has no valid claim over the ownership of the source code. It was not
- developed for them. They were involved as a sponsor for the work and had
- permission to sell products based on it, similar to companies selling devices with
- GrapheneOS. We've learned a lot of lessons from what happened and are being very
- careful to avoid being strongly associated with any particular company in the
- future.
The new product branded as CopperheadOS is closed source and not associated with
- the original project. They took our project's previous name and copied our legacy
- source code and documentation. Attribution to us has been stripped away and they
- pretend to be the ones who created it.
-
-
They've essentially stolen the identity of our open source project and have
- invested substantial resources into misrepresenting GrapheneOS as being a new
- project. They've built a business based on taking credit for research and
- development not done by them. Substantial damage has been done to GrapheneOS
- through an organized campaign of misinformation and harassment.
The new CopperheadOS is a shadow of the historical GrapheneOS code. They've
- continued copying portions of our newer generation code but haven't developed any
- significant privacy or security improvements on their own. It's a poor imitation
- of the original. It has a fraction of the privacy and security improvements and
- lacks a team with an understanding of how they work. It often doesn't receive
- timely security updates. It has made serious mistakes compromising user privacy
- and security.
-
-
CopperheadOS is a paid product and has license enforcement compromising user
- privacy and security through tracking devices to implement DRM. They use the
- outrageous business model of charging users for security updates rather than
- simply selling them the software or devices with it.
-
-
GrapheneOS devices can be purchased from a bunch of different companies,
- organizations and individuals. Many of these offer customer support. Unlike
- CopperheadOS, it's still open source software and you aren't being charged to
- simply get the OS updates. Anyone can sell devices with GrapheneOS without
- permission from the project due the open source licensing. Many of these sellers
- voluntarily contribute back to the project.
-
-
GrapheneOS is far more actively developed than the new CopperheadOS and has
- substantially more resources available, including significantly more funding.
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 company ended up holding back the open source project and taking far
- more from it than was provided to it.
-
-
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 disproven 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.
-
-
GrapheneOS now has multiple full-time and part-time developers supported by
- donations and multiple companies collaborating with the project.
-
-
GrapheneOS Foundation was created as a non-profit organization in Canada in March
- 2023 to handle the intake and distribution of donations.
These are the old changelogs for production releases of GrapheneOS. See the current
- releases changelog for more recent releases.
-
-
The release notes before the Nougat 2016.12.06.05.21.23 release should be taken
- with a grain of salt since we weren't really publishing them yet so it wasn't being
- done very carefully.
-
-
GrapheneOS started in 2014 based on Android KitKat but we only started keeping more
- user friendly changelogs late in the Marshmallow era.
-
-
The Nexus 9 maintenance branch is not included. It split off when the other devices
- moved to nougat-mr2-release and continued after the other devices moved to Oreo-based
- releases. It may be included here in the future but we wanted to avoid confusion.
-
-
Since Pixels, there are separate release channels including the public Stable and
- Beta channels. Each Stable release made it through the Beta channel and our internal
- Testing channel. The Nexus 5X and 6P moved to the current update system with release
- channels with the Oreo-based 2017.09.24.15.
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.102 to 3.18.103
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.103 to 3.18.104
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.104 to 3.18.105
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.126 to 4.4.127
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.127 to 4.4.128
-
Nexus 5X, Nexus 6P: fix ro.control_privapp_permissions=enforce setup (works fine on Pixels already)
-
use Cloudflare DNS as the default fallback: Cloudflare DNS has a better privacy policy than Google Public DNS and has DNS-over-TLS and DNS-over-HTTPS so it won't be a downgrade when Android ships one of them
-
tethering: use Cloudflare DNS servers as the default fallbacks
-
NetworkDiagnostics: switch to Cloudflare DNS
-
SettingsLib: use Cloudflare DNS servers as hints
-
Chromium: update from 65.0.3325.109 to 66.0.3359.106
Chromium: disable showing popular sites by default
-
Chromium: disable article suggestions feature by default (not supported by us and wastes UI space)
-
Chromium: fix the default value displayed for the hyperlink auditing flag
-
Chromium: update to 65.0.3325.109
-
Updater: add support for testing streaming updates (not in a useful way yet)
-
SELinux policy: fix overly noisy app_data_file execute auditallow for third party apps (untrusted_app rather than untrusted_base_app) where it's still permitted
-
Pixel 2 XL: kernel: fix upstream bug in lge_battery module breaking fast charging with a monolithic kernel build (found by @nathanchance)
-
Launcher3: stop disabling icon normalization
-
Launcher3: stop wrapping legacy icons into adaptive icons
-
base frameworks: use round adaptive icon mask and parse round icons
2018-03-01 security patch level including recommended updates
-
2018-03-05 security patch level including recommended updates
-
2018-03 Pixel/Nexus functional updates
-
Pixel 2, Pixel 2 XL: increase rollback index to 3 for 2018-03-05 patch level
-
Settings: update_engine downgrade attack we reported is now fixed upstream, remove from extra security patches field
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.119 to 4.4.120
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.97 to 3.18.98
-
Pixel 2, Pixel 2 XL: kernel: enable KPTI (already enabled for the Pixel and Pixel XL in AOSP, Google disabled it for the Pixel 2 and Pixel 2 XL since it's not crucial on the Snapdragon 835 but it's still useful hardening and fixes a known way to leak system registers)
Pixel, Pixel XL, Pixel 2, Pixel 2 XL: drop unused google_camera_app SELinux domain: Google Camera isn't available in a useful way so exposing the Hexagon DSP tech stack as attack surface via Google Camera is unnecessary. HDR+ is provided via the Pixel Visual Core to compatible apps already on the Pixel 2 and Pixel 2 XL.
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.116 to 4.4.117
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.117 to 4.4.118
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.118 to 4.4.119
-
Pixel 2, Pixel 2 XL: kernel: backport "staging: android: ashmem: Fix possible deadlock in ashmem_ioctl" fix for "staging: android: ashmem: Fix a race condition in pin ioctls" commit in 4.4.118
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.95 to 3.18.96
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.96 to 3.18.97
-
include Stk package for all devices, not just the Pixel and Pixel XL
Pixel, Pixel XL: kernel: reduce one DEBUG_SG check to a warning for now
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.93 to 3.18.94
-
Pixel, Pixel XL: kernel: cherry-pick stable kernel commits from 3.18.94 to 3.18.95
-
Pixel 2, Pixel 2 XL: kernel: cherry-pick stable kernel commits from 4.4.115 to 4.4.116
-
Pixel 2, Pixel 2 XL: kernel: Revert "ANDROID: Revert "arm64: move ELF_ET_DYN_BASE to 4GB / 4MB"" (spotted by @nathanchance)
-
lower pid_max to 1/4 of the default to guarantee a 4x higher max_map_count is theoretically safe despite the kernel being broken (not enough memory on real devices to matter but still)
Settings: sort applications in sensors and clipboard background permission toggle lists (@rascarlo noticed the sorting code in the location/audio lists was missing for these)
-
Updater: add generated icons
-
Updater: bump version
-
PDF Viewer: replace launcher icon
-
PDF Viewer: bump version
-
Camera app: properly handle INFO_SUPPORTED_HARDWARE_LEVEL_3 (enables support for Zero-Shutter-Lag on the Nexus 5X, Nexus 6P, Pixel, Pixel XL, Pixel 2 and Pixel 2 XL)
set the default for the background audio recording toggle to allowed for the time being
-
-
-
Blocking background audio recording by default ended up hitting far more app
- compatibility issues than expected. The goal is still to disable it by
- default but we need to whitelist Phone services and figure out if anything can
- be done to improve compatibility with apps like Signal and WhatsApp.
Updater: reduce update check rate to every 4 hours from 1
-
Updater: reduce retry rate to every 4 minutes from 1
-
DeskClock: fix broken upstream fix in Android 8.1 to match our fix for Android 8.0
-
Nexus 5X: update stock update-binary to OPM1.171019.011
-
stop disabling brotli compression for legacy format over-the-air updates
-
replace global toggle for background clipboard access with a per-app toggle (still disabled by default)
-
add toggle for background audio recording (now disabled by default)
-
-
-
Apps can still start recording audio in the foreground and continue in the
- background even with background audio recording disabled. This will end up
- being mitigated in the future but it isn't fully implemented yet.
update android-prepare-vendor to the latest revision
-
migrate from Android 8.0 to Android 8.1 (MR1)
-
Settings: stop marking KRACK fixes as extra security patches since Google included the fixes in AOSP
-
kernel (Pixel, Pixel XL): add fixes for GCC builds until time is available to migrate to using Clang like Google
-
Launcher3: revert broken upstream commit
-
overhaul exec spawning to work with the new spawning infrastructure
-
overhaul SELinux policy changes to cope with Treble ABI compatibility layer
-
temporarily switch to official WebView build (63.0.3239.83) due to temporary lack of published Chromium sources with API 27 WebView support
-
set up the slightly hardened Clang / LLVM toolchain for mr1
-
-
-
Known upstream issues for Android 8.1:
-
-
Settings app wrongly displays the SELinux status as Permissive because SELinux prevents Settings from reading the SELinux enforce mode
-
Pixel verified boot fingerprint display has been fixed but the fingerprint is not yet meaningful (verified boot does continue to work and automatically enforces that the key doesn't change, it's only a fingerprint display issue)
-
android-prepare-vendor may not work properly without manual intervention
Net Monitor: update to v1.2 from v1.1.4 (fixes the major issues of missing connections when it was running in the background and wrongly attributing connections to apps with shared uids like assigning all system uid connections to atfwd)
-
enable LOCAL_DEX_PREOPT for apks in vendor.img again
-
SELinux policy: allow vendor apps to execute vendor_framework_file for dexpreopt to avoid needing /data/dalvik-cache
-
backport wpa_supplicant security fixes for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087 and CVE-2017-13088 (CVE-2017-13084 is not applicable) to Oreo's current post-2.6 revision
Contacts: remove no-op help & feedback menu entries
-
keyboard: rebranding
-
fix logging for denials of background clipboard access
-
Updater (Pixel, Pixel XL): always wait for reboot after completing an update
-
Updater (Pixel, Pixel XL): switch to new system update icon for notification
-
Updater (Nexus 5X, Nexus 6P): add makeshift legacy update system support (This update client was designed to run on top of the update_engine A/B update system and file-based encryption. It can't offer the same user experience and robustness elsewhere. However, due to some recent changes it's possible to hack in support for the legacy recovery-based update system. It will handle edge cases like a normal reboot after an update is downloaded strangely but the basics can work.)
-
Updater (Nexus 5X, Nexus 6P): use legacy update server
-
Nexus 5X, Nexus 6P: replace LegacyUpdater with Updater
-
Chromium: update to 61.0.3163.98 from 61.0.3163.81
keyboard: disable personalized suggestions by default
-
Updater (Pixel, Pixel XL): use the standard update settings intent
-
Nexus 5X, Nexus 6P: port to oreo
-
LegacyUpdater (Nexus 5X, Nexus 6P): use the standard update settings intent
-
Settings: use standard update settings mechanism
-
Nexus 5X, Nexus 6P: vendor: remove system partition bytecode packages until they work properly (loses transparent WiFi / LTE switching on both and Qualcomm time service on 5X)
-
wpa_supplicant: enable WiFi scanning MAC randomization for non-Qualcomm WiFi devices again (Qualcomm WiFi devices already have a better implementation in firmware)
-
DeskClock: drop targetSdkVersion to 25 since Google released it as targeting 26 without handling the breaking changes
Pixel, Pixel XL: build nanotool, libion and libminui from source instead of extracting with android-prepare-vendor
-
Pixel, Pixel XL: avoid stripping out PixelThemeOverlay from vendor but don't enable it by default (AOSP keyboard doesn't support the theme like Gboard)
libc: add back dynamic object size checking support without actually wiring it up to any system calls yet
-
use permanent fingerprint lockout immediately
-
Updater (Pixel, Pixel XL): reject any serialno constraint for stable / beta (serialno constraint is only for alternate update channels not exposed as standard update channel choices)
Settings: do not allow disabling Chromium (it's very common for people to disable it without realizing Chromium provides the WebView to other apps)
-
Settings: do not allow disabling the main keyboard (it's not obvious that disabling it after installing another keyboard is a very bad idea. Other keyboards rarely support Direct Boot and won't work for entering the password, forcing recovery by plugging in a physical keyboard)
-
Updater (Pixel, Pixel XL): replace the notification channel to move away from deprecated APIs
Chromium: update to 61.0.3163.81 from 60.0.3112.116
-
Chromium: backport support for the Android Oreo WebView
-
Chromium: bump MonochromePublic targetSdkVersion to 26 to match the internal Monochrome metadata (needed to provide the WebView on Oreo among other things)
-
remove Google WebView since our hardened Chromium builds provide the WebView again
-
remove Google WebView from the WebView provider whitelist
-
PDF Viewer: adopt targetSandboxVersion 2 to use the much stronger instant app style sandbox for the app itself (rendering already happened in the stronger WebView sandbox)
-
Updater (Pixel, Pixel XL): migrate to Build.getSerial() API for enforcing update zip serialno constraints in anticipation of it becoming mandatory
-
grant Updater app on Pixel and Pixel XL Phone permissions for Build.getSerial()
-
leave deprecated Build.SERIAL field set to UNKNOWN (only support fetching the serial number via the new Build.getSerial() requiring the READ_PHONE_STATE permission)
move to Android Oreo OPR6.170623.013 the base OS (tip of oreo-r6-release branch)
-
port of many of our features to Android Oreo (8.0), requiring many changes to the implementations (details not listed here)
-
android-prepare-vendor port to Android Oreo / Treble and new vendor files
-
add missing ro.hardware.egl property
-
stop clobbering stock audio_effects.conf
-
temporarily bundle and whitelist the AOSP WebView until Android Oreo support is pushed to Chromium
-
add ambient capability support to exec-based spawning
-
use exec-based spawning for com.android.bluetooth now that there's ambient capability support
-
fix upstream issue with replacing the fingerprint of the boot image
-
handle -ftrapv like the signed integer sanitizer options (signed-integer-overflow, integer, undefined) by not passing -fwrapv
-
build new Clang toolchain
-
switch back to using speed mode for dexpreopt globally rather than only for certain core code
-
Launcher3: disable icon normalization for now as most icons aren't prepared for it
-
disable aapt2 for LatinIME (the keyboard) to work around a known aapt2 bug
-
increase padding from 16 to 32 bytes for the new AES_256_HEH filename encryption mode to match our increase from 4 to 32 bytes for the old AES_256_CTS mode (content is still encrypted with AES_256_XTS)
-
Contacts: remove no-op help and feedback option
-
Contacts: make add account message neutral about service choice
-
Settings: add back extra security patch level field
-
Settings: add back bootloader version field
-
Settings: add back verified boot status field
-
Settings: add back anti-theft protection status field
-
Updater (Pixel, Pixel XL): add support for battery not low job scheduling
-
remove shared relro support again
-
Launcher3: work around keyboard not being hidden
-
ExactCalculator: revert to the old Apache2 icon from before Google went out of the way to regress it in AOSP
-
Contacts: remove logo meant for the Google app based on this
-
recovery: rebranding
-
script: remove minutes/seconds from generated BUILD_NUMBER
-
temporarily bundle and whitelist the latest Google WebView until support for providing the WebView on Android Oreo is in Chromium
-
bionic: replace brk/sbrk/__bionic_brk with stubs again
-
Updater (Pixel, Pixel XL): move to new APIs provided at API level 26
-
Updater (Pixel, Pixel XL): add a notification channel
-
Updater (Pixel, Pixel XL): increase targetSdkVersion to 26
-
stop disabling unprivileged ptrace by default for compatibility with the new crash dump system
-
kernel (Pixel, Pixel XL): stop enabling ptrace_scope by default for compatibility with the new crash dump system
roll back non-firewall network hardening too for the time being in case it's the source of carrier compatibility issues
-
add toggle for disabling native code debugging support (toggles kernel.yama.ptrace_scope between 0 and 2, with more restrictions coming later)
-
replace SELinux policy in vendor.img with our policy
-
sepolicy: remove permissions tied to the Dalvik / ART JIT compiler again
-
sepolicy: remove app_data_file execute for priv_app again
-
sepolicy: add back fine-grained policy for /proc/vmstat
-
sepolicy: disallow text relocations for API 26+
-
sqlite: enable shift, signed-integer-overflow and object-size sanitizers in trapping mode again
-
make some function pointer tables read-only again
-
PDF Viewer: update targetSdkVersion to 26
-
PDF Viewer: update pdf.js to 1.8.188
-
fix undefined out-of-bounds accesses in sched.h again
-
switch pthread_atfork handler to mmap again
-
add memory protection for pthread_atfork handlers again
-
add memory protection for at_quick_exit handlers again
-
clean up string formatting in libc again
-
increase pthread stack size to 8MiB on 64-bit again
-
add XOR mangling mitigation for thread local destructors again
-
avoid some variable length arrays again
-
make __stack_chk_guard read-only at runtime again
-
replace pthread_attr junk filling pattern again
-
add explicit_memset and fix explicit_bzero with it again
-
add a proper issetugid implementation again
-
add back hardened malloc with assorted changes and integration
-
temporarily disable junk on free for init
-
whitelist getrandom system call for media seccomp sandboxes since hardened malloc triggers regular calls to it
-
Updater (Pixel, Pixel XL): get payload offset from new streaming metadata
-
zero sensitive data (512 byte hardware generated random seed) with explicit_memset in init again
-
tighten up mount permissions again
-
use blocking getrandom to prevent urandom fallback to prevent arc4random abort before urandom is available and to guarantee high quality early boot entropy
Chromium (including the WebView): update to 60.0.3112.107 from 60.0.3112.97
-
kernel (Nexus 5X, Nexus 6P, Pixel, Pixel XL): use kernel command-line as early boot entropy since it has the serial number and bootloader stage timings
-
Updater (Pixel, Pixel XL): open updater settings when the notification is touched
add CNEService for the Nexus 5X and Nexus 6P to bring them in line with the Pixel and Pixel XL
-
Pixel, Pixel XL: add CarrierConfig vendor.xml other than the Verizon entries from stock, resolving remaining non-Sprint / non-Verizon carrier compatibility issues (VoLTE / VoWiFi now work where supported, other than on Verizon where it requires proprietary apps / remote admin backdoor)
-
fix upstream bug in the permissions review activity (toggles only worked for new permissions, not previously granted / rejected ones)
replace default device policy manager maximum password length with 64 (was 16), which recently started to override the limit in Settings
-
Pixel, Pixel XL: include com.qualcomm.timeservice app to sync the hardware clock on time changes (via android-prepare-vendor)
-
only disable ART --abort-on-hard-verifier-error for the Nexus 5X and 6P, not Pixel phones where SoC support is less horrifying
-
PDF Viewer: preserve number picker state after being killed (from Tommy-Geenexus)
-
backport fix for NFC quick tile initialization from AOSP master
-
backported assorted memory corruption and other bug fixes
-
enable PERMISSIONS_REVIEW_REQUIRED to enforce user review of dangerous permissions pre-launch for apps targeting API levels less than 23 (pre-6.x)
-
Chromium (including the WebView): update to 59.0.3071.125
-
Chromium: build MonochromePublic instead of ChromeModernPublic
-
remove standalone Chromium WebView
-
switch WebView provider from com.android.webview to org.chromium.chrome
-
Chromium: build full Monochrome library for 64-bit and WebView-only library for 32-bit instead of vice versa, and set 64-bit as the preferred ABI to spawn all Chromium and WebView renderers as 64-bit as was the case before we used Monochrome (unlike stock Android)
kernel (Pixel, Pixel XL): add more __ro_after_init (partially from PaX)
-
kernel (Pixel, Pixel XL): randomize lower bits of the argument block like PaX
-
kernel (Pixel, Pixel XL): properly account for stack randomization in mmap base
-
kernel (Pixel, Pixel XL): determine stack entropy based on mmap entropy (11 → 16 bits for 32-bit processes, 18 → 24 bits for 64-bit processes) - note: arm64 4-level page tables could improve this significantly on 64-bit, but they aren't usable yet
-
kernel (Pixel, Pixel XL): move ET_DYN base lower in the address space
-
kernel (Pixel, Pixel XL): fix qcacld-2.0 buffer read overflows in userdebug builds caught by CONFIG_FORTIFY_SOURCE
-
update F-Droid privileged extension to 0.2.5
-
revert workaround for upstream race between camera services and flashlight quick tile (no longer needed)
worked around upstream Pico TTS bugs by building it as 32-bit
-
updated Chromium and Chromium WebView to 55.0.2883.45 (switched from Stable channel → Beta channel for now so that WebView can be built from source again)
replaced several uses of strlen on untrusted binary data without a guaranteed NUL terminator
-
updated Chromium WebView to 54.0.2840.68
-
updated Chromium to 54.0.2840.68
-
set Chromium release channel to "stable" to disable StrictMode and fix the version information
-
added a field to Settings → About device listing vulnerability fixes not included in the latest Android patch level (does not include those without ids, and it's incomplete)
-
added back preloadResources to work around upstream bugs causing CtsWidgetTestCases to fail (100ms app start latency cost)
switch ART from profile-based AOT compilation to full compilation since JIT profiling is disabled (verify-profile changed to interpret-only, speed-profile changed to speed)
-
initial Nexus 6P Nougat support
-
reverted upstream commits disabling dm-verity for the Nexus 5X and Nexus 6P vendor partition in AOSP (Nexus 9 not impacted)
- 
- 
- 
- 
- 
- 
- 
-