Salta al contenuto principale


We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS (grapheneos.org/faq#future-devi…) and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.
in reply to GrapheneOS

I hope a good candidate is found a a deal struck.

It would be important that a device partnered with another OEM also allows unlocking the bootloader for people who want to flash it themselves.

in reply to GrapheneOS

I am sick of all of this monopolistic abuse of power and the ones intended to stop this dont care or let themselves get bribed......
in reply to GrapheneOS

In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early.
in reply to GrapheneOS

We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release.
in reply to GrapheneOS

Due to AOSP no longer having device support, we need to build it ourselves. We can start from the Android 15 QPR2 device support, remove the outdated code and update the configurations. We have tooling to automate generating device support setups which will need major expansions.
in reply to GrapheneOS

Since our port to Android 16 is going to be delayed by a week or more, we're in the process of backporting the Android 16 firmware/drivers released on June 10 to the previous releases. This is not something we can do in general so we still need to port to Android 16 this month.
in reply to GrapheneOS

Despite our lead developer who has done 90% of the ports for several years being conscripted into an army, we were still able to complete the initial port to Android 16 in under 2 days, but without device support. Our extensive preparation in April and especially May paid off.
in reply to GrapheneOS

It's important to get an experimental release out quickly to begin extensive public testing. There are usually many issues found in testing. For a yearly release, we usually get out an experimental release in a day, an Alpha channel release in 2 days and need 4-6 more releases.
in reply to GrapheneOS

Google has released a statement claiming AOSP is not being discontinued. This should be taken with a grain of salt, especially considering that they made similar public statements recently followed by discontinuing significant parts of AOSP on June 10.

x.com/seangchau/status/1933029…

Gianmarco Gargiulo reshared this.

in reply to GrapheneOS

Google is in the process of likely having the company broken up due to losing an antitrust lawsuit from the US government and being in the process of losing several more. There's a high chance of Google losing control of Android in the next couple years.

nytimes.com/2025/04/21/technol…

Andreas Bulling reshared this.

in reply to GrapheneOS

The leaked information we received in April 2025 indicates that the reasoning they're making substantial cuts to Android is primarily cutting costs, perhaps in anticipation of it being split from Google. The courts should investigate Google's recent changes and cuts to Android.
in reply to GrapheneOS

Google has been accelerating their crackdown on alternate mobile hardware and software with the Play Integrity API combined with laying off many people working on Android and cutting parts of the project. They disallow their OEM partners from competing so others cannot take over.
in reply to GrapheneOS

It's no wonder that Android and Chrome engineers at Google are leaking tons of information when the company is in an extraction mode trying to get as much out of each as possible prior to Google being broken up. Regulatory action needs to move faster and take this into account.
in reply to GrapheneOS

A successful mobile OS will need near perfect iOS or Android app compatibility. For Android, compatibility means a solid fork of AOSP even if it's only used within a VM on a more modern microkernel-based OS. Google made an open platform, unlike Apple, and could not prevent this.
in reply to GrapheneOS

For years, Google has been using extraordinarily anti-competitive Google Mobile Services (GMS) licensing agreements with OEMs to disallow competition. To further prevent competition, they made the Play Integrity API where apps devs are convinced to check for valid GMS licensing.
in reply to GrapheneOS

If the Pixel 10 does meet our requirements, we'll support it, but it will take significantly more time and effort to develop support for it. At the end of the year, Qualcomm should finally release a new SoC providing hardware memory tagging. If they do, we can shift focus to it.
in reply to GrapheneOS

Once an OEM offering the service of making custom devices has a platform based on a new Qualcomm Snapdragon SoC with hardware memory tagging support, we can do a crowdfunding campaign to raise the money needed to have them build a device for us. We have talked with a couple OEMs.
in reply to GrapheneOS

The baseline will be several million dollars, which can be spread out across the cost of preordered devices. This is the cost of making a modern, secure device with a secure element and the other requirements we have for one instead of a low-end device with outdated hardware.
in reply to GrapheneOS

There will be a cost of a million or more dollars per year of additional support. Providing 7 years of proper support like Pixels would be very expensive. We definitely wouldn't be releasing a new device every year as the overlapping costs for all of it would be ridiculous.
in reply to GrapheneOS

On a side note, 5 years of upgrade after the first unit sells will be mandatory in EU due to a new law that will come into force in a week (20 june 2025)
energy-efficient-products.ec.e…

[EDIT : It's after the *first* unit sells for upgrades, it's the spare parts that must be available 7 years after the *last* unit sells]

Questa voce è stata modificata (2 mesi fa)
in reply to GrapheneOS

will devices that were once promised 7 years of support lining up with Google still be getting 7 years of support? Such as the Pixel 9 Pro XL for example. Or, is that in jeopardy?
in reply to GrapheneOS

on one side a GrapheneOS device would be a cool opportunity.
On the other, such a device could be a juicy target for a (hw) supply chain attack.
in reply to w00p

@w00p Agreed, so we would continue supporting new Pixels as long as they met our requirements. However, we need an alternative in case they stop meeting our requirements. Pixels were the official Android Open Source Project reference devices until June 10 when Android 16 was released. They are no longer the reference devices. Therefore, we see it as them no longer being committed to continuing to provide first class non-stock OS support. Perhaps they will provide it but they made it harder.
@w00p
in reply to GrapheneOS

@w00p It will be much harder to add Pixel 10 support after what they've done with Android 16. We can still do it if the Pixel 10 still has first class alternate OS support itself. However, it will take a lot more time especially to provide first class production quality support with nothing missing. It's also a very bad sign about how things will go in the future. We lack confidence that we can support future Pixels. Other OEMs don't make devices meeting our requirements, so we need our own.
@w00p
in reply to GrapheneOS

kudos to your work. Not easy to adapt to such an abrupt change, even more when a key member of the team is away
in reply to GrapheneOS

What does all of this mean for future support of current Pixels? I just bought a Pixel 9a, and while I would love to buy one of your own devices when they're available, I may not be able to afford it.
in reply to Kavus

@Kavus We plan to support them for their whole lifetime. It just may take us longer than expected to do some of the major quarterly and yearly version ports.

Our initial port to Android 16 is done. We should have experimental releases out already. Unfortunately, AOSP dropping device support means we need to build it ourselves. We haven't even started on most of it yet due to making the initial port. We have the kernels ported with initial tested but not the other device support code yet.

in reply to GrapheneOS

Thank you so much. You are the reason I still feel safe using a smartphone.
in reply to GrapheneOS

with that in mind, do you have plans for a reasonable repairability? Like it doesn't have to be modular/upgradable device, but at least don't require a heat gun to remove the screen and don't glue in the battery (just to name two examples). I think that would really add value.
in reply to GrapheneOS

don't forget to use same Sony sensors as Pixel cameras then 😀
in reply to GrapheneOS

finally, this is what i've been wanting. A GrapheneOS mobile device🎈🎉🙏🏽
in reply to GrapheneOS

Let's be realistic, only about 2000 people sponsor the project on GitHub. Even if somehow every 100th out of a 200,000-user base wants to pre-order a phone, which will likely cost at least $2000, that could bring in $4 million, which is unlikely to be enough for development. At the same time, none of the OEM developers will agree to safely produce and supply phones with GOS, because NSA will very convincingly ask them not to.
in reply to flashbackdealer

@flashbackdealer GitHub is a tiny portion of the donations we receive. We receive most donations via cryptocurrency. We have a couple million dollars saved but don't plan on spending that paying for the costs of making a device. It's for OS development.
in reply to GrapheneOS

We need to accept this and look for legal avenues, which is also very unlikely, given that there are no updates regarding Play Integrity too.
in reply to GrapheneOS

It's a shame that Fairphones lack the level of security needed for GrapheneOS. Would it even be a feasible idea that GOS could work with Fairphone to make a secure device?
in reply to Ted

@tedstechtips It's not feasible for Fairphone to make a device meeting our requirements any time soon. It's very feasible for several other OEMs to do it in 2026. We're talking to a major one. They would already likely be close to doing it but seem willing to specifically consider our requirements and make sure it happens. We're working on making it official.
@Ted
in reply to GrapheneOS

Why don't you support the Pinephone's, except removing all the proprietary malware (thus making privacy actually remotely possible), instead of adding as much as possible?
in reply to GNU/翠星石

@Suiseiseki Pinephones have absolutely atrocious privacy and security at a hardware, firmware and software level. They use highly outdated and insecure hardware components which lack proper firmware updates, security protections and have much worse isolation rather than better. The cellular radio is an outdated Qualcomm cellular modem on another chip running a whole outdated proprietary fork of Android, connected to the main CPU via very high attack surface USB. It's representative of the rest.
in reply to GrapheneOS

@Suiseiseki Pinephones are closed source hardware with closed source firmware. However, it's very outdated and far lower security hardware and firmware with lack of proper firmware updates. It's primarily used to run a much less private and secure software stack on top. It's unable to protect users from far more basic attacks. It's the opposite of what we want to build with GrapheneOS. It does not avoid closed source hardware or code. It's making huge sacrifices but is still closed source.
in reply to GrapheneOS

@Suiseiseki There's a misconception that the Pinephone is open hardware, but that's not the case. The hardware components are just as closed source with firmware that's just as closed source. It is not progress but rather taking things in the wrong direction. That isn't what we want from GrapheneOS hardware. We want a device meeting the requirements we have listed at grapheneos.org/faq#future-devi…. We want to at least have close to competitive security with Pixels and iPhones, not dramatically worse.
in reply to GrapheneOS

>Pinephones have absolutely atrocious privacy and security
All demon rectangles have atrocious privacy and security, no matter how updated the proprietary malware is.

>hardware, firmware and software level.
The Pinephones come with no firmware - they have only proprietary hardware and proprietary software.

>highly outdated and insecure hardware components which lack proper firmware updates
Yes, you can update the proprietary malware and spyware, but that simply makes security worse, not better.

>is an outdated Qualcomm cellular modem on another chip running a whole outdated proprietary fork of Android
Last time I checked it was a custom proprietary RTOS and not Android.

If it was Android, that would be a matter of GPLv2 enforcement to resolve that issue.

Unlike any other modem, there is a free software userspace for that modem, which clearly can possibly have security, but as for the modem, the only possible way to possibly have security would be to finish the job and replace the remaining proprietary malware with free software.

>connected to the main CPU via very high attack surface USB
USB devices do not have DMA, thus it's a lower attack surface than a device that has the modem turn on and then start the main SoC and only then decide to turn on IOMMU (or not).

IOMMU is unfortunately inherently flawed as last time I checked IOMMU's only implement page-level filtering and many attacks have been found against it.

It is possible via software means and hard work to make a USB stack very attack resistant, but you're always screwed with DMA if the modem can decide to not enable IOMMU.

>Pinephones are closed source hardware with closed source firmware.
Obviously the hardware is proprietary like all hardware.

The bootloader is free software and you can run only free software on the SoC and when it comes to proprietary software loading, that's only for the Wi-Fi+Bluetooth combo card connected via USB (but I would just disable it via the physical switch as it's garbage).

>It's primarily used to run a much less private and secure software stack on top.
If the user doesn't run proprietary malware on their computer, they're quite secure.

You should not teach users to think they're safe just because there is sandboxing and permissions management, when the most degeneratey proprietary spyware and malware is running!

>It does not avoid closed source hardware or code.
Hmm, if you go and disable the modem and Wi-Fi card via the physical switches, it appears that everything can run with free software?

There might be some software on the usb controller I guess (but an update for that is never offered), but that doesn't have DMA - yes, that should be made free software.

>at least have close to competitive security with Pixels and iPhones
It's peak comedy thinking Pixel's and iPhone's are secure - imagine trusting the biggest malware and spyware experts on the planet!

The very first step of security is to first run 100% free software and then you actually have a chance of securing something - if there is any proprietary software, your security falls to pieces.

in reply to GNU/翠星石

@Suiseiseki Decent phones have far better security than laptop/desktop class hardware which is also closed source hardware and firmware, but with far worse hardware, firmware and software security. Providing good security depends on hardware-based security features so those aren't separate things.

Pinephones have a huge amount of proprietary firmware running on the hardware. They have proprietary firmware for Wi-Fi, Bluetooth, cellular, the SSD, the main SSD and other components. You're wrong.

in reply to GrapheneOS

@Suiseiseki Librem 5 also has a huge amount of proprietary firmware despite the false marketing claiming otherwise. Firmware being stored on the chips rather than being loaded by the OS at each boot doesn't mean it stops existing. It is still there and is still closed source firmware running on a whole bunch of the components. Not being aware of the firmware running the radios, SSD, battery, touchscreen, SoC and other components doesn't mean the firmware isn't there. It is there and running.
in reply to GrapheneOS

@Suiseiseki Not patching privacy and security vulnerabilities does not make you better off. It assures your lack of privacy and security. You're concerned about theoretical backdoors with no evidence existing of them rather than the front door being left open through having unpatched critical security vulnerabilities which are publicly known.

Pinephone has an outdated Qualcomm baseband running an outdated baseband RTOS on a Quectel chip running an outdated, closed source fork of Android.

in reply to GrapheneOS

@Suiseiseki The modem used by the Pinephone was made for Windows. The company cut corners and didn't make real Windows drivers but instead put an extra CPU on the radio chip next to the baseband which is used to run their own fork of Android with the Qualcomm drivers and services. That provides an interface to the main OS via USB for using the radio without actually having proper drivers and services for it.

Pinephone SoC has a closed source early boot chain prior to the open source one.

in reply to GrapheneOS

@Suiseiseki Your claim that the Pinephone baseband has a uniquely open source userspace available is completely wrong. The baseband is entirely closed source firmware regardless of what you do. Pinephones have an extra CPU running a closed source fork of Android next to the baseband which doesn't exist on a normal phone. That is what people have figured out how to replace since the company making the radio completely failed at basic security and therefore it's easy to take over that extra OS.
in reply to GrapheneOS

@Suiseiseki It's also trivial for an attacker with temporary access to the phone to take over both the baseband and the main SoC, for similar reasons. There's no attempt at providing any kind of security against an attacker obtaining an After First Unlock state phone where the encryption passphrase was entered. There's no secure element so only users with their phone powered down with a strong encryption passphrase will have their data safe from attacks. Many OSes for it don't even have that.
in reply to GrapheneOS

@Suiseiseki You're completely wrong about the status of the Pinephone's firmware. The components including the SoC are filled with proprietary firmware. Not having updates for it or not loading it from the OS doesn't mean it doesn't exist. Loading an open source boot chain from the closed source early boot chain doesn't mean there isn't one. Even Snapdragon has an open source UEFI implementation based on a fork of EDK2. You simply believe that what you don't see in the OS does not exist. Nope.
in reply to GrapheneOS

@Suiseiseki Having firmware stored on components or hard-wired in a way that it can't be updated is not more open and is less transparent rather than more transparent. It does not somehow mean there isn't firmware on those components. The reality is that Pinephones are closed source hardware with closed source firmware, just like mainstream phones. Unlike mainstream phones, they have far worse hardware, firmware and software security throughout. Software being open doesn't make it secure.
in reply to GrapheneOS

>Decent phones have far better security than laptop/desktop class hardware
No they do not. Demon rectangles are specifically designed to be spying devices and be vulnerable to outside hijacking and are designed to always spy.

Has GrapheneOS managed to find and fix any of the modem backdoors built into any of the supported devices?

There is ALWAYS a modem backdoor, as that is what demon rectangles are for.

Replicant devices have modem's without DMA, attached over USB, which has allowed fixing the modem SoC backdoor; redmine.replicant.us/projects/…

>which is also closed source hardware and firmware
On my GNUbooted computers, I run 100% free software.

All hardware is always 100% proprietary.

The question is if the hardware contains malicious circuits and if those circuits can be bypassed or made ineffective.

>Providing good security depends on hardware-based security features so those aren't separate things.
If all you run is free software that serves you, you do not need virtual machines - as the software serves you.

If you concern is that software getting exploited externally - maybe SELinux would be a good idea - as that tends to scream as soon as an attack is attempted (and on a real computer you can actually see the dmesg log and actually do something about it, as you have a proper screen and a proper keyboard and you can physically yank out the UTP cable).

>Pinephones have a huge amount of proprietary firmware running on the hardware.
Yes, you can run proprietary software on microprocessors - news at 11.

>They have proprietary firmware for Wi-Fi, Bluetooth
Yes, I pointed out that there's proprietary software for the Wi-Fi+Bluetooth card that is garbage and you're best of disabling with the hardware switch (which you actually can reliably disable).

Maybe that card would be useful with free peripheral software.

>cellular
Yes, all celluar modem's either contain a malicious circuit (some GSM ones and ealier), or malicious software - the modem used in the pinephone is no different - it just does not have DMA to the SoC.

There is free software available for the modem userspace as it seems the modem software isn't digitally handcuffed, which means it should be possible to write free software for the modem that isn't malware and you'll be good provided there isn't malicious circuits (but that doesn't solve the problem of location spying via the mobile network).

You can actually disable the modem via a hardware switch, unlike on modern demon rectangles when the modem never switches off (as far as I can tell, iphones actually reserve the bottom 10% of the battery or so when the device hits "0%" battery, so apple can keep spying on the location and listening no matter what).

>the SSD, the main SSD
Wrong - there is no SSD.

The A64 supports raw eMMC; files.pine64.org/doc/datasheet… and it looks like there's a free driver in Linux for it, thus I don't see why they would add a eMCC controller; wiki.pine64.org/wiki/PinePhone…

Yes, microsd cards run proprietary software, but there is no reason why they can't run free software. Usual SDIO and bit-banging SPI doesn't have DMA either.

There is also a power management chip that could run software; wiki.pine64.org/wiki/PinePhone… which should be free.

Other than that, it doesn't seem there's any other software and it seems possible to replace the propriety software in the device - but good luck doing that with google's device.

The pinephone's hardware seem to be a hell of a lot better documented than google's devices huh?

in reply to GNU/翠星石

@Suiseiseki Connecting a modem via USB exposes an enormous amount of attack surface to the modem via the kernel's USB stack and drivers. That's far less secure than having an IOMMU isolated modem with DMA using a typical approach. The Pinephone's modem is far less secure against attacks and missing important patches. No need for a backdoor. Since the isolation is far worse, it's easier to take over the OS from it.

Replicant has atrocious security and non-existent protection from this, not more.

in reply to GrapheneOS

@Suiseiseki Your claims about the Pinephone modem firmware are extraordinarily false. The extra CPU it has running a closed source and outdated fork of Android does not exist on a normal, sane modem. Replacing that is not replacing a component which exists on normal devices. That is not the baseband's userspace, it's an extra OS for running drivers/services made for Linux/Android so that a Windows OS can use the modem without having drivers/services written for it. It does not normally exist.
in reply to GrapheneOS

@Suiseiseki The OS that's normally directly using the baseband is the one running on the main SoC. Having that extra OS is highly unusual and a massive security problem. Connecting it via USB is also a massive security problem. These things greatly reduce security. It does not make the baseband any more open. People are not running any open source software on the Pinephone's baseband through replacing an OS running on an extra CPU on the radio chip. That is not a "modem userspace" as you claim.
in reply to GrapheneOS

@Suiseiseki Your claim about the overall Pinephone hardware and firmware are extraordinarily false. You're doing false marketing for what is in reality a closed source platform with closed source hardware and firmware. Your claim to support open source is quite dubious when in reality you promote closed source hardware and firmware with false claims of openness. Your claim to care about privacy and security while promoting highly insecure hardware, firmware and software doesn't check out at all.
in reply to GrapheneOS

@Suiseiseki No amount of posting more of your huge amounts of false claims, fabrications and inaccurate assumptions about how things work is going to change this. What you are promoting has atrocious privacy and security. It is closed source hardware and firmware masquerading as being open when it isn't. Doing false marketing about the atrocious level of privacy and security it provides only makes it worse. It's an insecure device and is not safe to use as a general purpose networked computer.
in reply to Trash Panda

@raccoon @Suiseiseki read this: grapheneos.social/@GrapheneOS/….


@frej Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.

in reply to GrapheneOS

We need to be realistic. Info about microkernel based OS was for at least 5 years. So far there is no roadmap. This is very ambitious with limited team Event almighty google went with linux for android. With limited resources OS from scratch will take decade. Plus who is going to do software audits to keep it secure? Linux is not perfect but it is audited and is secure enough to run server infrastructure.
in reply to /dev/null

@dev0null GrapheneOS is already a Linux distribution and it's one of the biggest problems we have with security. Hardening it is already a major focus for us and will have to become and increasingly big one over time, even if it's contained within virtual machines for most of the OS.

There are so many memory corruption bugs in the Linux kernel deploying hardware memory tagging for it to protect against attacks has ended up uncovering a lot of core Linux kernel bugs. It will not be solved.

in reply to GrapheneOS

@dev0null The Linux kernel is not well audited/reviewed. It has atrocious security at an architectural and implementation level. It has hundreds of serious memory corruption bugs being found every month. You should take a look at the subset of the vulnerabilities which are assigned CVEs by the Linux kernel project. There are an enormous number of them and that's just the subset which have received a fix which was backported to the stable/longterm kernels. It's a demonstration of how bad it is.
in reply to GrapheneOS

I though moving graphene as a virtual os for isolation, security and app compatibility and using another host os to run graphene virtual machines is the plan. For the host you proposed microkernel-based OS instead of linux. I thought it might be more feasible with limited resources to use linux. Anyhow, I'm 100% on your side and hope you'll succeed
in reply to /dev/null

@dev0null We will be using the AOSP-based GrapheneOS to run the AOSP-based GrapheneOS in VMs in the medium term. We can put tons of work into this and make it into a very good feature for isolating apps or groups of apps much better with high usability. It will be a huge set of features to develop. We will try to do it in a way that's minimally invasive by having it almost entirely implemented in an app and other standalone components without many changes in the base OS required for it.
in reply to GrapheneOS

@dev0null The way it would work is proxying the stuff the app or group of apps does through an outer app. Android's standard Terminal app for running desktop Linux as a demo for virtualization is an existing example of this.

We're just saying that in the long term we would want to replace the OS underneath everything with a more secure one based on a microkernel. That would be a far future thing to do after we already had increasingly custom hardware, etc. It's many years away, not a couple.

in reply to GrapheneOS

@dev0null QubesOS is essentially an example of what we're talking about but we want to build something more usable and based around running Android apps. It's also only part of how we're approaching security. We still want to greatly harden the OS and apps, but alongside isolating groups of them from each other with virtualization instead of the essentially hopeless Linux kernel security architecture/implementation. We'll do what we can to secure Linux but there's a limit to that.
in reply to GrapheneOS

@dev0null We've quite successfully blocked real world exploits by forensic data extraction companies which are primarily based on Linux kernel exploits. That's primarily done through the generic memory corruption exploit mitigations we've added/improved and especially our USB-C port control feature. Our earlier software USB accessory blocking while locked worked well against them but the newer hardware-based feature we made is much better. However, there's no way to do this with apps.
in reply to GrapheneOS

@dev0null Defending the Linux kernel against applications is essentially hopeless in the long term. We can make it much harder and defeat real world exploits not specialized for GrapheneOS but it's pretty much a lost cause. We cannot make it an extremely strong barrier. A stronger sandbox not permitting any file access, etc. can be used to run specialized code but for apps, they require too much functionality from the kernel. We need virtualization for it.

The Linux network stack is also scary.

in reply to /dev/null

SELinux is in linux kernel, virtualization as well. If waydroid is insecure I would rather focus effort on making it secure or creating another project.
in reply to /dev/null

@dev0null SELinux is not something which is simply on or off. Using it properly requires designing the overall userspace OS around it and heavily integrating it. It's hardly used by distributions like Fedora and it's an entirely different kind of thing from what's deployed in AOSP.

Running AOSP with the security model destroyed on top of a far less secure userspace OS is an anti-privacy and anti-security approach. It is the opposite of progress. What problem do you think that's solving?

in reply to GrapheneOS

@dev0null GrapheneOS exists to build a more private and secure OS, not a far less private and secure one. Moving to the desktop Linux software stack would be an enormous regression, not progress.

We already have hardware accelerated virtualization on GrapheneOS for all of the devices we support. We're already going to be using that as an improved sandbox better than what the Linux kernel can provide.

Why would we have interest in using an extraordinarily insecure approach on a less secure OS?

in reply to GrapheneOS

@dev0null Using hardware-based virtualization in a similar way to QubesOS is how we're going to be working around the insecure architecture and implementation of the Linux kernel in the medium term. In the much longer term, we want to take the virtualization-based approach we build and move it on top of a more secure OS. Hardware-based virtualization is already the present and building out functionality based on it is entirely doable. We have a whole lot to do so hire more people to cover more.
in reply to GrapheneOS

@dev0null We are going to be using AOSP regardless because we need broad compatibility with mainstream apps. We therefore need to have a privacy/security hardened fork of AOSP. Why should we have both a privacy/security hardened fork of AOSP and then also a much less private/secure OS to run that on top of via virtual machines? It makes more sense to use the same AOSP-based OS both for app compatibiltiy and the rest of the OS. The only reason we have to move to something else is avoiding Linux.
in reply to GrapheneOS

Would this be a good opportunity to make something that competes with Linux?

I find myself getting annoyed at the smartphone way of doing things these days. But supposedly Linux (and desktops in general) are much less secure.

Would it be possible to make a desktop OS that meets your standards?

in reply to zaire the bored genderfuck

@soop No, absolutely not. Waydroid is an extraordinarily insecure project implemented in a highly incorrect way. It discards the basic Android app sandbox and security model. It's far less secure running Android apps via Waydroid than running them on an AOSP-based OS. They disable SELinux and basic parts of the Android security model. This is done to run the apps on top of much less secure operating systems. Waydroid also doesn't keep up with OS updates and is missing basic security patches.
in reply to zaire the bored genderfuck

@soop It is very far off. Waydroid is using namespaces to make a half working Android environment without the security model intact to run it on top of a much less secure operating system. It's making things far less secure rather than more secure. It's not a proper way of doing things in the first place and from our perspective is a complete dead end. The right approach is running a proper AOSP environment with the security environment intact on top of a more secure OS, not the opposite.
in reply to 🌸 lily 🏳️‍⚧️ θΔ ⋐ & ∞

@tauon Waydroid is an extraordinarily insecure project implemented in a highly incorrect way. It discards the basic Android app sandbox and security model. It's far less secure running Android apps via Waydroid than running them on an AOSP-based OS. They disable SELinux and basic parts of the Android security model. This is done to run the apps on top of much less secure operating systems. Waydroid also doesn't keep up with OS updates and is missing basic security patches.
in reply to GrapheneOS

@tauon Hey @Liberux, I would be really interested in your take on this regarding Waydroid security specifically given you're working on a phone using it for cross-compatibility.
in reply to Natasha Nox 🇺🇦🇵🇸

@Natanox @tauon @Liberux Anything using Waydroid is running Android apps without the basic app sandbox. They have unpatched privacy and security vulnerabilities but are introducing a massive amount of severe vulnerabilities themselves through disabling most of the security model. Running all of that on top of a much less secure base OS without basic industry standard security features and hardening only makes things worse. That's the opposite of a privacy and security centric product.
in reply to GrapheneOS

@Natanox @tauon @Liberux Far less secure hardware, firmware and software not doing the bare minimum to protect user privacy and security is the opposite of what we want to build. What we want to build in the long term with far more resources than we have today is a much more secure OS built on a secure base rather than a very poorly secured monolithic kernel. Linux kernel is by far the worst part of Android's security despite all the effort it puts into hardening it and attack surface reduction.
in reply to GrapheneOS

@Natanox @tauon @Liberux We don't want to go from Android to something worse. We want to integrate virtualization-based security able to provide far better security than the Linux kernel for sandboxing applications and drivers. In the longer term, we want to move to a more secure base underneath those virtual machines. Moving to the far less private/secure desktop Linux software stack isn't what we want and Waydroid is a drastically less secure way to run Android apps than the status quo.
in reply to GrapheneOS

@Liberux I should've asked that question above without Graphene in the mentions, sorry. Could've known they'd immediately start to ramble. 🫠

So, what's your security concepts regarding Waydroid?

in reply to Natasha Nox 🇺🇦🇵🇸

@Natanox @Liberux Why are you posting replies to us if you don't want us replying? You can send them a direct message not involving us.
in reply to GrapheneOS

*sigh* because you pointed something out that's simultaneously in the context of smartphones, and I wanted *their* opinion on this. Instead you began talking about yourself again for some reason. I thought we could all have a civilized, interesting discussion about it. Next time I'll screencap your argument to make extra sure you're not part of the discussion anymore if that's more of your style, now please stop before this turns into yet another drama.
Questa voce è stata modificata (3 mesi fa)
in reply to GrapheneOS

I'm curious, what language would you use to build the new OS you describe? Rust seems like the obvious answer but I'm curious what your thinking is.
in reply to GrapheneOS

I can't help feeling that Android being detached from Google would be a double-edged sword.
On one hand, there'd be loads more freedom of innovation but on the other hand, surely it'd be massively underfunded/understaffed and struggle to operate.
I'm not close enough to it to know for sure either way so maybe I'm completely wrong.
in reply to GrapheneOS

What does it mean that AOSP no longer has device support?
Questa voce è stata modificata (3 mesi fa)
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@MurmeltHier Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.
in reply to GrapheneOS

@MurmeltHier Our hardware requirements are listed at grapheneos.org/faq#future-devi…. These are not going to be greatly watered down in order to support existing devices. The only devices currently meeting these requirements are Pixels. There are OEMs like Samsung providing the security features but without proper non-stock OS support. Getting both the security features we need combined with proper non-stock OS support is going to require an OEM partnership. It's going to cost a lot of money.
in reply to GrapheneOS

Not sure what is worse, that nearly nobody else builds phones with the security measures you require, or that the single company that does is locking things out
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@martin Our hardware requirements are listed at grapheneos.org/faq#future-devi…. These are not going to be greatly watered down in order to support existing devices. The only devices currently meeting these requirements are Pixels. There are OEMs like Samsung providing the security features but without proper non-stock OS support. Getting both the security features we need combined with proper non-stock OS support is going to require an OEM partnership. It's going to cost a lot of money.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@martin Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.
in reply to GrapheneOS

LB: Google really are a shower of cunts.

It's a shame there isn't a push to ensure that every single device can have its bootloader unlocked, to pave the way for a kind of mobile Linux. The fact that the vast, vast majority of computer hardware can run Linux, but still runs Windows or macOS tells me that the number of people who would take advantage of an unlockable bootloader would be tiny. But the option would be there for those who wanted it.

in reply to GrapheneOS

@martin Fairphones do not have proper OS updates from day one. They don't receive anything close to the long term support of iPhones or Pixels. Delivering an OS update multiple years late is not actually providing multiple years of support compared to a company delivering it on time. An OS release which comes out June 2025 being shipped August 2026 is not providing more than a year of extra support compared to a company releasing it on launch day. That is how they present support numbers though.
in reply to GrapheneOS

If you come up with a good solution I'll kickstart the shit out of it.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@Mik3y Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.
in reply to GrapheneOS

@Mik3y Our hardware requirements are listed at grapheneos.org/faq#future-devi…. These are not going to be greatly watered down in order to support existing devices. The only devices currently meeting these requirements are Pixels. There are OEMs like Samsung providing the security features but without proper non-stock OS support. Getting both the security features we need combined with proper non-stock OS support is going to require an OEM partnership. It's going to cost a lot of money.
in reply to GrapheneOS

I am only generally good with understanding technology and tried installing graphene OS on a pixel but it was really above my head. If grapheneos were on a phone by default that would be stellar
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@kraftnix @zyx @MurmeltHier Samsung devices are still closest to meeting our requirements and they would be the best company to build a GrapheneOS phone but we don't think that's on the table due to not having a high enough scale for them to want to do it. We would need to work with a smaller OEM like Nothing offering the option to have custom phone variants produced. It will cost millions of dollars, especially since paying for each year of support is expensive. Doing it right isn't cheap.
in reply to GrapheneOS

@kraftnix @zyx @MurmeltHier Currently, only Tensor and flagship MediaTek/Exynos SoC platforms provide support for hardware memory tagging (MTE) but Snapdragon is much better than MediaTek at overall security and support. Due to Qualcomm having custom cores/cache, it's harder for them to add MTE than SoC platforms using standard Cortex cores where MTE is a standard feature. We consider MTE mandatory and this is one of the main barriers to paying an OEM to make a device for us right now.
in reply to GrapheneOS

@kraftnix @zyx @MurmeltHier We need Snapdragon to add support for MTE. They're potentially doing it later this year. If they do that, we're going to have more good options. We want either a Snapdragon-based or Exynos-based device. Snapdragon would provide much better CPU/GPU performance than Exynos and Pixels. Snapdragon also includes a secure element in the flagship SoC so that makes things a lot easier, instead of needing to add a secure element and set up pairing with the main SoC.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@WiFiHugger @Miaourt They can do it. Look at Redox OS. However, people will expect app compatibility. Therefore, a more modern platform like that will need to be paired with running virtual machines with a fork of AOSP for mainstream application compatibility. Our long term plan is taking the current GrapheneOS and putting it on top of a fork of a new base. We would continue having the current project but we'd also have a fork of another OS running underneath instead of the Linux kernel.
in reply to GrapheneOS

@WiFiHugger @Miaourt That is a very long term plan. Implementing full hardware support for a new OS is a massive task, as is building the new OS in the first place.
in reply to GrapheneOS

Nothing or Punkt come to mind as interesting options to work with. Any word on the companies you've been in talks with thus far? Obviously nothing is confirmed at this point but some ideas on the potential group you may work with would be interesting.
in reply to GrapheneOS

does that mean newer generations of pixels are not going to run grapheneOS?
in reply to 𝙎𝙩𝙤𝙢𝙖𝙩𝙖 ☄

@Stomata We don't know if newer Pixels will meet our requirements. Google is doing extreme cost cutting of anything they don't realize is bringing them revenue and they likely don't realize this brings them revenue.
in reply to GrapheneOS

@zyx @MurmeltHier Samsung will never do it, the scale as you mentioned, and the money they make from the spyware and surveillance they preinstall from their apps. It will never happen.

I think the market could be larger than just current Graphene users if the phone would include some of the features manufacturers are ignoring, like:
- smaller phones
- headphone jack
- SD card

But it will be expensive... I do think there would be enough interest to make it possible though.

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@WiFiHugger Yes, there's a market for it and we're confident that we can raise the money once. We're less confident in our ability to continue raising the money to release new generations regularly. We would need to space it out enough, which would mean paying for longer support to provide leeway to not release as many devices.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@Suiseiseki @WiFiHugger @Miaourt The Linux kernel has a fully monolithic design where all of the code including drivers, filesystems and everything else run with full privileges and access to everything. It's comparable to running the entirety of userspace inside of a single process. Many people complain about systemd merging tons of code into a poorly secured PID 1 process but the Linux kernel is a far more extreme version of it running at a higher privilege level with far more attack surface.
in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt In reality, the systemd PID 1 is not particularly monolithic compared to the Linux kernel design and has little attack surface by comparison. Every single driver needed for your hardware including drivers for obscure USB peripherals plugged into the computer runs with maximum privileges as part of a single kernel that's essentially one application. Every thread created by an application has a corresponding kernel thread with full access to everything.
in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt With the Linux kernel design, processes have their address space split between userspace and the kernel. They do input, output, etc. by switching into the kernel thread for the corresponding userspace thread. That kernel thread has full access to everything. A massive amount of Linux kernel APIs are exposed for use by applications, providing enormous attack surface to applications to attack the kernel. There is zero isolation or sandboxing in the kernel. None.
in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt The main way companies like Cellebrite exploit devices is through vulnerabilities in Linux kernel drivers. They typically exploit bugs in drivers for USB devices such as webcams, DACs, network cards, etc. When you plug one of those into a typical Linux-based system, it automatically loads the driver and uses it. There's also the massive attack surface of the Linux kernel having the entire network stack with TCP, UDP, IP, etc. inside of the kernel with max access.
in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt A bug in an obscure driver, optional TCP feature, etc. usable for code execution provides full control of the Linux kernel and the OS. The reason Linux uses a monolithic kernel design is because having everything in a single address space with access to everything else has lower overhead. It avoids the need to switch between different processes as is done in userspace.

Linux chose ease of development and performance over having good security and reliability.

in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt For the same reason that the Linux kernel has a horrible architecture for security, it's bad for robustness too. Kernel bugs in obscure drivers can trivially take down the whole kernel, corrupt filesystem data, lock up the machine, expose you to remote takeover by attackers, etc.

Due to the Linux kernel being written in C, a large subset of bugs are exploitable vulnerabilities due to lack of memory and type safety. Their coding style / choices also contribute.

in reply to GrapheneOS

@Suiseiseki @WiFiHugger @Miaourt C code is highly prone to unsafety, insecurity and instability due to lack of type and memory safety. The Linux kernel does not have good adoption of techniques to reduce this and uses an extremely performance-focused approach for data structures and locking introducing a huge amount of subtle and often exploitable bugs. Scaling and performance are highly prioritized at the expense of enormous complexity, poor robustness and poor security.
in reply to GrapheneOS

Wouldn't it be less complicated to collaborate with other brands like #FairPhone or #Volla, for example?
in reply to Frej 🇩🇰 🇺🇦 🇵🇸

@frej Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.
in reply to GrapheneOS

@frej Our hardware requirements are listed at grapheneos.org/faq#future-devi…. These are not going to be greatly watered down in order to support existing devices. The only devices currently meeting these requirements are Pixels. There are OEMs like Samsung providing the security features but without proper non-stock OS support. Getting both the security features we need combined with proper non-stock OS support is going to require an OEM partnership. It's going to cost a lot of money.
in reply to GrapheneOS

@frej Working with a company like Fairphone not currently capable of making a secure device meeting our requirements does not provide a path to another viable option with GrapheneOS support. We have to work with an OEM that's capable of providing what we need. The most realistic way to do that is waiting for Snapdragon MTE support and then paying an OEM to make us a Snapdragon device. Snapdragon has the security features we need other than MTE including a built-in secure element (SPU).
in reply to GrapheneOS

@WiFiHugger @Miaourt We're interested in eventually having our own variant of a more modern OS like Redox OS and having the current AOSP-based GrapheneOS within that for app compatibility. That is where we see things going in the long term. It is far away but we're going to be working towards it by using virtualization within the current OS. We can make the inner part of the future OS within the current OS and then in the future the OS underneath the VMs can be migrated to another one.
in reply to GrapheneOS

@WiFiHugger @Miaourt Since we will need the AOSP-based OS within the VMs for app compatibility we will still need to actively develop/maintain it. Therefore, we will not have a huge amount of redundant work. We can continue supporting the AOSP-based OS on bare metal while also introducing a new OS running it only in VMs where most of our work is applicable to both. That's the very long term roadmap for where we want to take GrapheneOS if we succeed at growing it and getting lots of funding.
in reply to GrapheneOS

@WiFiHugger @Miaourt We don't think mainstream devices are going to be running the current era operating systems based on legacy monolithic kernels and OS designs forever. We aren't saying Redox OS is going to be what ends up being widely adopted but it is an example of an OS making major improvements through having a microkernel and writing a lot of the core OS including most of the kernel in a memory safe language. It is at least paving the way for future progress and is valuable for that.
in reply to GrapheneOS

@Mik3y do you mind to elaborate the "atrocious security", because i own one :/
in reply to �

@utf_7 @Mik3y No secure element so disk encryption doesn't work for the majority of users not using a very strong passphrase but rather a typical 6-8 digit PIN along with the other protections missing because of that.

Typically around 1-2 months of delays for backported Android and hardware vendor security patches. Monthly and quarterly updates with many additional patches are skipped entirely. Yearly releases with many more non-backported patches come a year or more late.

@
in reply to FDA approved lychee

Not much to be honest. Google, Samsung and Apple are the only three major manufacturers releasing phones with the security hardware required to safely run GrapheneOS without compromises, and from those, Apple has no support for Android whatsoever, and Samsung permanently disables the safety hardware (Knox) in case the user sideloads another OS.
in reply to GrapheneOS

@utf_7 @Mik3y We're currently super concerned that AOSP has made changes which are going to cause us to take more than a couple days to ship a yearly release without having any early access to the code before launch. Android 16 was released on June 10 and we've completed our initial port to it including our invasive changes like Storage Scopes, Contact Scopes, 2-factor fingerprint unlock, sandboxed Google Play compatibility layer, etc. Our concern is it could take weeks to redo device support.
@
in reply to GrapheneOS

@utf_7 @Mik3y We don't think a year or more of delay for a yearly update is at all acceptable, especially when Fairphone is a Google partner with partner access. They can port to the new monthly, quarterly and yearly updates early. They have early access to the partial monthly backports of patches to older releases. There isn't a good reason for delays. We manage to avoid anything close to those delays without early access and with far more invasive changes we need to port to each new release.
@
in reply to GrapheneOS

@utf_7 @Mik3y Those are the main problems which we consider to be not meeting bare minimum standards. There are additional reasons they aren't meeting our hardware requirements but it's a whole lot less important. They have an SoC platform from 2021 in the Fairphone 5 without ARMv9 security features (PAC, BTI, MTE) we consider mandatory. We wouldn't say a device with those as the only missing features has atrocious security but it wouldn't meet our current requirements for us to use it.
@
in reply to GrapheneOS

@utf_7 @Mik3y does this only apply to the yearly major updates or is this now going to be a problem for every minor Android update going forward?
@
in reply to Infernal_pizza

@Infernal_pizza @utf_7 @Mik3y The biggest issue will be with this Android 16 update because we were not expecting this to actually happen the way it did. We received early notice in April about AOSP dropping device support but didn't know exactly what that meant. It was a factor in us preparing for the port more than we ever have before combined with our lead developer likely being unavailable for the whole port due to being conscripted. That's why we have an initial Android 16 port done now.
in reply to GrapheneOS

@Infernal_pizza @utf_7 @Mik3y There is a whole lot to fix about the port based on testing and code review. Unlike every previous port, we currently have no device support. We will need to rebuild device support with the adevtool approach we use. We'll need to do a lot more than we have for device support in the past. We'll also need to reimplement our USB-C port control feature another way since the component we modified to implement it was dropped from AOSP and modifying it would be harder.
in reply to GrapheneOS

@frej One additional security feature could be using the upstream GPU driver stack (Freedreno), as upstream GPU drivers are generally much more secure than the blobby ones due to better code quality.
in reply to D3fault 🏴‍☠️

A new device effort will cost millions to get something slightly below the same level of what we have now.
in reply to Final

Millions is the broad term. If it’s a ten million dollars then I guess it’s possible to fund rise if hundreds then gonna be tough
in reply to D3fault 🏴‍☠️

Around 10 million for a Snapdragon device with 7 years of support. Each year of support would be around a million dollars or more. This would be the cost of paying an OEM/ODM to create a flagship Snapdragon device for us. We aren't sure if making new devices with newer generations would have any discount based on already paying them for an existing one. Maybe not.
in reply to GrapheneOS

Perhaps we should pause and wait for some time. Given that none of the OEMs provided access to the source code, even though you've been asking for months, the chances that at least one OEM manufacturer you could negotiate with about releasing a smartphone would ultimately agree to produce it are approaching zero. 1/5
in reply to GrapheneOS

Given that we're waiting for a Snapdragon with the MTE support, which at best will only be the latest Elite 2, with an OEM price of $200+, such a device would be incredibly expensive. And if we wait for newer, simpler chips and factor in development and tuning time, it will take at least 3-5 years before release. 2/5
in reply to GrapheneOS

None of the OEMs are willing to accept cryptocurrency payments, and as soon as you start making payments in fiat, intelligence agencies in certain countries will mix traces of terrorist money into your funds, either to simply shut down the project at best or, at worst, land you in prison. Of course, this is just amusing speculation... or maybe not. 3/5
in reply to GrapheneOS

And speculating further, knowing the capabilities of the NSA (we all remember the stories about Cisco equipment) and other intelligence agencies (we all remember pagers), such a tempting target as devices with GOS firmware will 100% face planned supply-chain attacks. They might even collaborate with Qualcomm to introduce special chip modifications specifically for your devices. 4/5
in reply to GrapheneOS

Maybe you should postpone porting Android 16 until the end of the year, until the latest QPR version with all the functionality is released, and then try to port it. And for now, focus on finishing all the planned functionality (network location, per app geo/video/audio spoofing, etc) in version 15? Thank you for all your hard work. 5/5
in reply to GrapheneOS

I don't even have a Pixel, but I was hoping to buy one whenever my iPhone 13 Pro gives up, so this is a big shame.
in reply to Ben

@ben We can continue supporting existing Pixels. We don't know if 10th gen Pixels will meet our requirements.
@Ben
in reply to GrapheneOS

Are there any projects in this same vein with the goal of broad device support that you would endorse?
in reply to zaire the bored genderfuck

@soop There are no similar projects and the projects with broad device support are explicitly anti-security projects massively rolling back privacy/security. They aren't safe to use and are a much worse choice than an iPhone. Non-Pixel devices do not meet the requirements to run GrapheneOS due to lack of security and lack of proper non-stock OS support.
Unknown parent

mastodon - Collegamento all'originale
Martin
@MurmeltHier It's really a shame I mean I understand why GrapheneOS aren't going forward with Fairphone, but man the sustainably and repairability of a Fairphone + the security and fast and long software updates of GrapheneOS would be the killer combo.
Unknown parent

mastodon - Collegamento all'originale
kraftnix

@zyx @MurmeltHier ye so its a non-starter. i don't see samsung ever allowing it, if you ever unlock the bootloader on a samsung you permanently break access to the security key via an e-fuse.

Given it's a non-starter, my original question still stands..

Unknown parent

pleroma - Collegamento all'originale
GNU/翠星石

Why would you write a new kernel when GNU Linux-libre exists? All that kernel would need extra is drivers for such hardware.

Why make a new OS when the GNU OS exists and is 100% free software and is the best?

in reply to GrapheneOS

Is your current perception that a competive device could be produced by a small project (relative to Google) like yourself?
in reply to Laser

@356875ffd729b06eeb4c1d7a70a1f750045d067774d21c0faffe4af2bf96a2e8 It would be produced by an OEM for us based on our requirements. We would be paying them to make it for us and support it long term. We'd be paying for Qualcomm Snapdragon and other licensing through the OEM making it for us. It will be very expensive but this is something which exists and we believe we can obtain the funds for it either by getting them ourselves or by doing crowdfunding with preorders specifically for this.
in reply to GrapheneOS

How much does this matter in practice?

nevent1qqsrcwg6d92ktcqxa4yszerajlv6m4gvgffafa5hfylsjdaqk57a3ecpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcq3qx458tl7h9xcxa66vr4a8pg0h2qz96pnhwnfpcra0le9090uk5t5qxpqqqqqqz4say8e

in reply to Laser

@356875ffd729b06eeb4c1d7a70a1f750045d067774d21c0faffe4af2bf96a2e8 It isn't a very practical concern and applies to essentially everything. Pixels have less threat of real world supply chain attacks happening than custom hardware with a much smaller userbase focused on privacy/security though. The problem with more specialized hardware focused on that is that it's easier to target, especially since as a much smaller organization we would have less oversight over the OEMs and components.
in reply to GrapheneOS

@356875ffd729b06eeb4c1d7a70a1f750045d067774d21c0faffe4af2bf96a2e8 We still plan to support future Pixels after we have our own hardware. There will be advantages to using Pixels. We can gradually build advantages to using our custom hardware but simply keeping up with current era security is a hard problem and the main one we want to tackle. Our ambition is simply having a custom Snapdragon device with all the standard security features. As soon as Snapdragon has MTE, that is straightforward.
in reply to GrapheneOS

We had hoped Pixels would go in a different direction based on the fact they use the open source Trusty OS for the TEE and secure core, OpenTitan as the basis for their secure element, littlekernel for the late stage boot chain, etc. We hoped they would end up like Chromebooks with fully open drivers and more open firmware. Instead, they're cutting non-essential things to save money and have decided all of that is non-essential.
Questa voce è stata modificata (3 mesi fa)
in reply to thepurpose

@7de3def8d21199c5ac7b82735cb3b6fb4837dfbc3cd3130b8ff085d50c384b43 Fairphone's devices have atrocious security and poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most OEMs. We don't think they're capable of building what we need and they haven't shown interest. No secure element means disk encryption doesn't work for most users.
in reply to GrapheneOS

@7de3def8d21199c5ac7b82735cb3b6fb4837dfbc3cd3130b8ff085d50c384b43 Our hardware requirements are listed at grapheneos.org/faq#future-devi…. These are not going to be greatly watered down in order to support existing devices. The only devices currently meeting these requirements are Pixels. There are OEMs like Samsung providing the security features but without proper non-stock OS support.
in reply to GrapheneOS

I know you can't spoil things rn (NDAs and stuff) bit I do hope #Fairphone is one of those manufacturers.

A #Fairphone6 with #GrapheneOS would really be cool because it coincides with the hex rings of carbon atoms that Graphene is made if.

in reply to Chris 👾

@chris @kkarhan Fairphone's devices have atrocious security and very poor long term firmware/software support. They lack proper updates from the start and are missing more of our requirements than a typical Snapdragon Android device. They're further from providing what we need than most Android OEMs. We don't think they're capable of building what we need and they haven't shown an interest. They're partnered Murena who are misleading people about privacy and heavily attacking GrapheneOS.
in reply to Kevin Karhan

@kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to We're talking about their current devices and track record. If they were prioritizing security, they would at least be delivering the partial monthly security backports on time each month and keeping up much better with OS updates. They aren't currently compliant with bare minimum standards being implemented by the EU. There's no secure element at all so disk encryption doesn't work for most users. We expect more than the bare minimum, which they don't do.
in reply to GrapheneOS

@kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to
I'd be curious to read more about this. Currently I'm happily running a (manually installed) /e/OS on a Fairphone 5 and both encryption and security patches look fine.
in reply to Thomas

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to /e/OS is an extraordinarilyh insecure OS which misleads their users about privacy/security patches. You do not have a current Android OS version, which means you only have partial backports to older releases. You do not have the current backports to older Android versions. Check the actual version and patch levels, but note that /e/OS sets a fake value for the Android security patch level. That is not the normal UI and you're being misled about this.
in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to Disk encryption on the Fairphone doesn't work for users without a strong passphrase. It has no secure element to throttle unlock attempts so users with a typical PIN or weak passphrase do not have working encryption. Disk encryption being enabled but trivially bypassed even for a device that's turned off is not real protection of your data. Aside from that, Fairphone does not include crucial protections needed to protect a device that's not off.
in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to If you do have a strong passphrase such as 6 random diceware words, disk encryption will work when the device is in the Before First Unlock state. If you have a random 6-8 digit PIN or similar, you do not have working encryption on a Fairphone.

/e/OS omits a bunch of important security features including verified boot which are needed to protect a locked device in the After First Unlock state. If your device is in that state, it's easily taken over.

in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to A field showing you that no updates are available from /e/OS is meaningless. That doesn't mean you have the current Android OS version or backported privacy/security patches. You should look at the actual patch level and long form OS version. Android 14 was released in October 2023. Android 16 was released this month. There are still partial security backports to Android 13, 14 and 15 on a monthly basis. That doesn't mean you have the current ones.
in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to The standard Android user interface shows a single unified patch level field with "June 5, 2025" for the current patch level. That includes patches for firmware, the kernel, kernel drivers, vendor code (drivers, services, etc.) and the Android Open Source Project's userspace code. What you're showing is simply a UI telling you if you've updated to the most recent version they have available, which is always behind AND has security features disabled.
in reply to GrapheneOS

@kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to
And with that last remark you are talking about the actual FP5 hardware? As the software is (optionally) Murena's /e/OS or (by default) their own vanilla Android. Would GrapheneOS run on a FP5?
Thanks for pointing this out. Currently I don't feel the need to hop OS again, but it's good to know the options.
in reply to Thomas

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to Fairphone 5 does not have basic hardware security features provided. It does not have a secure element providing working disk encryption for the majority of users, regardless of OS choice. It does not have decent protection against remote, local or physical attacks at a hardware, firmware or driver level. /e/OS has extraordinarily poor secure and you're far worse off on security if you use /e/OS on it but it's still not reasonable secure at all.
in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to Fairphone 5 does not meet the most bare minimum hardware, firmware and software security requirements. It certainly doesn't meet the hardware requirements to run GrapheneOS listed at grapheneos.org/faq#future-devi…. Not being able to provide working disk encryption for the majority of users who are not going to set a strong passphrase is only one example of what's missing. We consider that to be part of the bare minimum for any phone with reasonable security.
in reply to GrapheneOS

@thpar @kkarhan @chris @fairphone@lemmy.ml @fairphone@mas.to The OS shipping on the Fairphone 5 is their own fork of Android with Google Mobile Services licensed and integrated into it. There is not really any such thing as "vanilla Android". That's their own operating system based on the combination of AOSP, SoC vendor code, Google Mobile Services, etc. They're responsible for maintaining and updating it. Unlike /e/OS, Fairphone does maintain the standard security model in their OS and does better patching.
in reply to Kevin Karhan

@kkarhan @thpar @chris @fairphone@lemmy.ml @fairphone@mas.to This has some false positives when there are security improvements preventing access to things or blocking exploits, although that's not relevant to either OS officially available for Fairphone. It only checks for a tiny minority of patches which is very relevant. It checks for certain specific things.

It's best to just start by looking at the claimed patch level dates while noting that /e/OS, CalyxOS and LineageOS set an inaccurate main patch level.

Unknown parent

mastodon - Collegamento all'originale
Miaourt 🍰
@WiFiHugger I guess most of the interesting works on AOSP is done in devices trees.
Having android without them is kind of like having Linux without most of its drivers.
Still a working kernel, but, well, nothing to run it on
in reply to GrapheneOS

@Mik3y thank you for the very detailed answer. sad to hear that one have to trade sustainability vs security 🙁
in reply to GrapheneOS

ehem I'll start suggesting what I would want from the Graphene phone, can you add media player buttons on its sides just like Nokia was doing?
in reply to GrapheneOS

I'm specifically going to play the EuroMillions tonight & if I win the jackpot of £208M then I'll be winging a fair bit across to help you & the team out. In fact, if anyone reading this uses GOS and is eligible to do so (& has £2.50 to spare) then we should all play tonight! I benefit 'daily' from all of the GOS teams hard work by using it on my Pixel so thank you 👊
in reply to GrapheneOS

@frej Can you give some information on what you consider "atrocious security"? I'm not a customer (I have a Jolla C2 instead 😉) but I like their approach as a company generally so curious as to what their issues are (Feel free to DM if you'd rather not say openly)
in reply to Stewart X Addison

@sxa @frej Fairphone lags months behind on shipping critical severity privacy/security patches, lags a year or more behind on shipping current OS versions with more than a partial subset of backported patches, has used publicly available private keys for important things including verified boot whether accidentally or intentionally, doesn't provide working disk encryption for the majority of users due to lack of a secure element and lacks many other basic defenses. Jolla is worse than that.
in reply to GrapheneOS

@sxa @frej We don't think it's acceptable to be lacking working disk encryption for typical users not using a strong passphrase in 2025. If a user sets a random 6 digit PIN, they should at least have working disk encryption against all but very sophisticated attacks. Pixels and iPhones have provided this for years, and have made it secure enough that even sophisticated attackers can't bypass a random 6 digit PIN in practice. Most users are not going to set a very strong passphrase.
in reply to GrapheneOS

@sxa @frej Android Security Bulletins are a monthly set of High and Critical severity privacy/security backports to OLDER Android releases. They're the bare minimum, not a high standard. The full set of patches is part of the latest OS release. There are also device-specific patches beyond these. Pixel Update Bulletins are an example but are largely not actually Pixel specific patches since they mostly use common components like a Mali GPU, Samsung cellular radio, Broadcom Wi-Fi, etc.
in reply to GrapheneOS

@sxa @frej Shipping Android Security Bulletin patches is part of the bare minimum. Fairphone has early access to them and should ship them on the launch day each month. We do not have early access and still ship them on the launch day. We then migrate to the new latest OS release. Fairphone skips the monthly and quarterly releases entirely. They use the initial yearly release with partial backports, as most non-Pixel OEMs do, then move to yearly releases 1 year late, growing longer over time.
in reply to GrapheneOS

@sxa @frej We think shipping the backports on time each month is the bare minimum. Shipping the full set of patches through updating to the new stable OS releases which have already gone through months of public beta testing is what should happen but is currently somehow beyond the capabilities of most non-Pixel Android OEMs. It should still be what happens. Otherwise, it will remain one of the major reasons that Pixels are the only high security alternatives to iPhones which is unfortunate.
in reply to GrapheneOS

@frej Thanks. That all sense and is really useful to know (and to be clear I wasn't suggesting Jolla were especially great in those respects either 😉)