grapheneos

Exclusive access to QPR1 and QPR3 releases gives Pixels an unfair advantage over other Android OEMs. They get an extra 2 major updates per year. Introducing new APIs for third party app developers as part of these updates means third party apps will now run best on the Pixel OS. Google apps already run best on the Pixel OS due to many exclusive features. It's Google's standard overall approach to propping up parts of their business with their monopolies in other markets. It's not legal.

Pixels used to have far better updates than any other Android devices but they stopped improving it years ago. It should have kept improving because it's not at all adequate. They need to be able to release OS updates more than once per month and it shouldn't take months for patches to make it into the OS. It currently takes them at least around 2 months to get even the most urgent patches into the OS. They could fix emergency calls being broken if the patch was made around 3 weeks before an OS release, but that's about as quick as they can go. It's not at all adequate for security and is a complete joke compared to Chromium's release cycle. They can get an emergency Chrome update released within a couple days. They should at least be able to do it for the Pixel OS in a week.

GrapheneOS is often around 4 to 6 months ahead on merging Linux kernel LTS releases. We used to handle this ourselves but switched to the Android GKI LTS branch maintained by Greg KH. Unfortunately, it was often struggling to keep up even before the absolutely massive increase in Linux kernel security patches this year. AI models have rapidly accelerated vulnerability discovery and it's an ongoing crisis for the Linux kernel. We want to be on the latest LTS revision within days and want to be using the latest LTS branch within months of it being released. We're not at all happy with how Android is handling things and plan to fix that ourselves. We'll get things back to how they should be.

We also ship all the AOSP userspace patches months before Pixels due to shipping all of the security preview patches as soon as possible. There are sometimes minor regressions but we find and fix them ourselves downstream. The security preview system has a terrible design especially considering that frontier AI models can reverse engineer the patches. There should at least only be a source embargo for around 24 to 72 hours rather than pretending as if it can work with the patches available 2 to 6 months in advance.

QPR1 and QPR3 are now Pixel exclusive since Android 16. That means the new APIs for app developers added in Android 17 QPR1 are Pixel exclusive until Android 17 QPR2. There hasn't been a case of new APIs for apps not being open source or not being available to every OEM since Android Honeycomb (3.x).

It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.

GrapheneOS does block SO_BINDTODEVICE when VPN lockdown mode is enabled. It doesn't yet block apps in profiles not using a VPN in lockdown mode from using a VPN in another profile due to compatibility concerns but we can likely block it.

We've previously emailed them with no result. This time around we got a reply about this specific account targeting us but it isn't resolved. We don't have much optimism about getting the many past threads with personal attacks based around fabricated stories and harassment content addressed without doing more than asking via email.

We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.

The past several weeks of our replies were wrongly flagged. None of our posts were in any way inappropriate and it's entirely appropriate to ask for help getting it undone. On the other hand, you're repeatedly making personal attacks on our team, engaging in doxxing and spreading harassment content. You're directly pointing people to Kiwi Farms harassment content with blatant libel and doxxing. There have been years of this harassment on Hacker News without it being addressed by the moderators. We're not going to be tolerating it anymore. Hacker News actively engages in moderation and therefore has no excuse to be permitting this harassment and leaving up years of it across many threads.

> I am not sure why all your comments are flagged

The past couple weeks of our replies were maliciously flagged. We've made a post about it on social media as we've had to do before when this happens. This happens very regularly to posts by GrapheneOS or posts which simply support GrapheneOS. There are a bunch of malicious accounts which show up to each thread about GrapheneOS to make personal attacks towards our team, baselessly claim it's a honey pot, promote non-hardened products reducing privacy/security compared to AOSP and to make a bunch of disingenuous attacks towards it. The attacks towards our team often involve fabricated stories about us and harassment content. There's an account active in many of these recent threads making disingenuous replies and spreading Kiwi Farms harassment content in their profile:

https://archive.ph/JAunG

That account should clearly be banned rather than a subset of their posts getting flagged. The same applies to several other blatant ones.

See https://news.ycombinator.com/item?id=49672677.

This is the email we received:

    Hello

    Check: https://news.ycombinator.com/item?id=49096839

    Please upvote/comment/share/mitigate

We passed it along to our developer working on solving VPN leaks. We didn't feel it was necessary to reply to a post linking to a public article. The article was shared with us by our users before we checked out emails.

We have a bunch of internally discovered VPN leaks which are already being worked on and this was added to that workload. We've already shipped a bunch of fixes and will ship more soon. We plan to eventually overhaul the whole system to prevent leaks in a much more systemic way.

Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.

See https://news.ycombinator.com/item?id=49672677.

Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.

See https://news.ycombinator.com/item?id=49672677.

Security issues considered outside the scope of what they consider a security vulnerability are closed regardless of what they plan to do about the issue. Google primarily uses internal issues to track issues with Android. Public issues and security issues filed by external parties are only used to communicate externally and an internal issue is created for their actual issue tracking.

A security issue being closed means you aren't getting a bounty and it won't be fixed for existing Android releases. It doesn't mean it won't be fixed in a future Android release. They do track VPN leaks as issues internally and regularly ship fixes in new major releases. They unfortunately don't consider those security issues so they don't get prioritized. If they were considered security issues, then they'd likely consider them Low or Moderate severity which means those wouldn't be backported.

Only a large subset of patches for High and Critical severity issues are backported to older releases of Android. Low and Moderate severity issues stopped having patches backported years ago due to volume. High and Critical severity patch backporting is now being scaled down too due to AI accelerated vulnerability discovery. You need the latest yearly or QPR2 release to get full updates.

GrapheneOS has had to fix a bunch of VPN leak issues and we're in the process of fixing more of the issues. We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.

They lag 1-2 months behind the Android Security Bulletins which are months behind when patches can first be shipped by vendors. Verifying their kernels for the FP5 and earlier are end-of-life can be done by looking at the code. It's straightforward to verify they're a year or more behind on major updates and that those are required for full security patches. It's clear from a basic glance at the Android Security Bulletins that Low and Moderate severity patches are not backported. It's harder to demonstrate they don't backport all High and Critical severity patches but it's true and the gap of what's not backported is growing with recent changes. They made an announcement to OEMs about only the most recent 2 major yearly versions getting most High and Critical severity backports along with even those no longer getting a large portion of High and Critical internally found bugs which were found with LLMs.

There's nearly no information available on the working conditions, pay or environmental impact of Fairphones. T2Mobile is the company designing and making Fairphones since the Fairphone 4 and little information is available on them. Fairphone provides a long list of companies involved in the supply chain without more details than their location and website.

Pixels have long term availability of official parts for repairs and also official repairs.

Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.

> might want the option of using a build of grapheneos

An OS without the core features and updates of GrapheneOS clearly isn't GrapheneOS. It's not permitted to refer to it as such.

> That's kind of the whole point of FOSS, right?

No, the point of FOSS is that you can take all of our code and use it for other purposes. Calling an incomplete port to another device GrapheneOS is misleading users. It isn't GrapheneOS and must have a unique name.

RCS already works on GrapheneOS via Google Messages using sandboxed Google Play. We have an ICC authentication toggle for granting the required access to Google Play services. We want to provide our own implementation within our Messaging app to replace Google Messages and then we want to provide an alternate backend not depending on sandboxed Google Play, at least for carriers with their own implementation.

It may take a long time to make a fully standalone implementation and that may not be compatible with most carriers. However, we plan to provide it in the short term through support for using the Google RCS infrastructure. We can have it start out supporting using sandboxed Google Play for RCS activation in the same way Google Messages uses it to replace Google Messages.

GrapheneOS already supports using Google Messages with RCS. Google Messages is essentially the only RCS app for Android and it's the only one supporting end-to-end encryption. There were other apps such as a Samsung one but they died out and are nearly entirely only still around on outdated devices as a legacy app. We don't want people to need to use Google Messages for RCS and plan to add it to our Messaging app.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.

They're incorrect, see https://news.ycombinator.com/item?id=49669964.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

It's not an article but rather release notes for people who already use it. The app is only available to users on GrapheneOS as the default SMS/MMS app (eventually RCS). Our users try out the new version directly instead of looking at static images of it.

A video would be needed rather than screenshots since those wouldn't show the new animations and UI flow.

GrapheneOS users can update to it via the Alpha channel and try it out rather than looking at screenshots. There's still more to improve before it will go to the Beta and Stable channels.

It's the default SMS/MMS app for GrapheneOS and isn't available for use outside GrapheneOS so we aren't trying to promote it as an option.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

An incredibly incomplete port without many of the core security features and decent updates is not GrapheneOS. It isn't possible to bring GrapheneOS to Fairphone devices.

> It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.

Fairphone 5 and earlier have an end-of-life Linux kernel. Fairphone 6 is approaching the same fate. None of their devices keep up with the incomplete security backports to older releases, let alone the full security updates via new major releases. All of their devices are missing important hardware security features which should be standard. They're repeatedly said they don't consider any of this a significant issue and have no plans to significantly change it.

> as far as SMS/MMS can be secure

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS.

> GOS got a big donation

We receive large donations on an ongoing basis.

> or has a volunteer that wants to do messaging

Everyone doing substantial work on the project is paid to do it full time. We hired all the people doing large amounts of high quality volunteer work. We've moved on to a process of filtering candidates based on their CV, an interview process and small test projects.