Post AvEHpLjDe6tHTOosGu by sxa@fosstodon.org
(DIR) More posts by sxa@fosstodon.org
(DIR) Post #Av3eH6frGt1D91KT20 by GrapheneOS@grapheneos.social
2025-06-12T15:02:06Z
4 likes, 4 repeats
We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS (https://grapheneos.org/faq#future-devices) and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.
(DIR) Post #Av3h4V8FKHBj65Hvkm by Jain@blob.cat
2025-06-12T15:39:16.434339Z
0 likes, 0 repeats
@GrapheneOS :blobcatfrowningbig:
(DIR) Post #Av3hBHyYdgaaJwzdbM by GrapheneOS@grapheneos.social
2025-06-12T15:06:25Z
1 likes, 1 repeats
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.
(DIR) Post #Av3hBO8hisGpR9mpFY by GrapheneOS@grapheneos.social
2025-06-12T15:09:34Z
0 likes, 0 repeats
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.
(DIR) Post #Av3hBTsGOugVDu8mSO by GrapheneOS@grapheneos.social
2025-06-12T15:12:23Z
0 likes, 0 repeats
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.
(DIR) Post #Av3hBa8R7hBcdnkmUy by GrapheneOS@grapheneos.social
2025-06-12T15:16:13Z
0 likes, 0 repeats
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.
(DIR) Post #Av3hBg4l2HoD484vb6 by GrapheneOS@grapheneos.social
2025-06-12T15:20:41Z
1 likes, 1 repeats
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.
(DIR) Post #Av3hBm3YnePrc9Z3Z2 by GrapheneOS@grapheneos.social
2025-06-12T15:22:45Z
0 likes, 0 repeats
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.
(DIR) Post #Av3hBseIHzMg3onTea by GrapheneOS@grapheneos.social
2025-06-12T15:28:59Z
1 likes, 1 repeats
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.https://x.com/seangchau/status/1933029688202703062
(DIR) Post #Av3hByn1SRub6cvX5k by GrapheneOS@grapheneos.social
2025-06-12T15:30:40Z
1 likes, 1 repeats
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.https://www.nytimes.com/2025/04/21/technology/google-search-remedies-hearing.html
(DIR) Post #Av3hC53u8aysYis6Eq by GrapheneOS@grapheneos.social
2025-06-12T15:32:44Z
0 likes, 0 repeats
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.
(DIR) Post #Av3hCBCdJ3WnbX09g0 by GrapheneOS@grapheneos.social
2025-06-12T15:36:05Z
1 likes, 1 repeats
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.
(DIR) Post #Av3hCHKIXTDyb2dMSO by GrapheneOS@grapheneos.social
2025-06-12T15:38:53Z
1 likes, 1 repeats
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.
(DIR) Post #Av3hfWFi7ho9HpQnVw by GrapheneOS@grapheneos.social
2025-06-12T15:42:48Z
1 likes, 1 repeats
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.
(DIR) Post #Av3hx5e9mVQXz0FCJE by GrapheneOS@grapheneos.social
2025-06-12T15:45:43Z
1 likes, 1 repeats
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.
(DIR) Post #Av3iQEDN0MgixCbovo by Suiseiseki@freesoftwareextremist.com
2025-06-12T15:54:23.190358Z
0 likes, 0 repeats
@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?
(DIR) Post #Av3nfB5VPcONN2sWHI by GrapheneOS@grapheneos.social
2025-06-12T15:56:48Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3nfC3PosJYMquMeu by GrapheneOS@grapheneos.social
2025-06-12T15:58:27Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3nfCitKfUWRUJUJ6 by GrapheneOS@grapheneos.social
2025-06-12T15:59:50Z
0 likes, 0 repeats
@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 https://grapheneos.org/faq#future-devices. We want to at least have close to competitive security with Pixels and iPhones, not dramatically worse.
(DIR) Post #Av3nfDDNVJsTy2ZppI by Suiseiseki@freesoftwareextremist.com
2025-06-12T16:53:04.234523Z
0 likes, 0 repeats
@GrapheneOS >Pinephones have absolutely atrocious privacy and securityAll 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 updatesYes, 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 AndroidLast 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 USBUSB 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 iPhonesIt'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.
(DIR) Post #Av3npFjSzz7wfgNFCK by WiFiHugger@mas.to
2025-06-12T15:38:33Z
0 likes, 0 repeats
@GrapheneOS isn't this a good thing though? Android being taken out of Googles control?
(DIR) Post #Av3npGqwpeho9AsjUu by Miaourt@raru.re
2025-06-12T16:13:32Z
0 likes, 0 repeats
@WiFiHugger @GrapheneOS 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
(DIR) Post #Av3npHeZr8P8d66Mr2 by WiFiHugger@mas.to
2025-06-12T16:31:36Z
0 likes, 0 repeats
@Miaourt @GrapheneOS why can't people just make a New Kernel or simply make a new operating system? Why is this so hard?
(DIR) Post #Av3npILpGL00nEKuGW by Suiseiseki@freesoftwareextremist.com
2025-06-12T16:54:51.196852Z
0 likes, 0 repeats
@WiFiHugger @Miaourt @GrapheneOS 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?
(DIR) Post #Av3qbpjmdT8K9CoaDw by GrapheneOS@grapheneos.social
2025-06-12T16:55:53Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qbqsgNrqVh5zCjY by Suiseiseki@freesoftwareextremist.com
2025-06-12T17:26:06.036189Z
1 likes, 0 repeats
@GrapheneOS >Decent phones have far better security than laptop/desktop class hardwareNo 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; https://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor>which is also closed source hardware and firmwareOn 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, BluetoothYes, 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.>cellularYes, 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 SSDWrong - there is no SSD.The A64 supports raw eMMC; https://files.pine64.org/doc/datasheet/pine64/A64_Datasheet_V1.1.pdf 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; https://wiki.pine64.org/wiki/PinePhone_component_list#P.7_NAND/eMMCYes, 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; https://wiki.pine64.org/wiki/PinePhone_component_list#P.6_POWER 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?
(DIR) Post #Av3qbvK7rmAtTMrB44 by GrapheneOS@grapheneos.social
2025-06-12T17:04:35Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qc0qZKa64bR4epM by GrapheneOS@grapheneos.social
2025-06-12T17:06:35Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qc6vOjXWbS9NbBg by GrapheneOS@grapheneos.social
2025-06-12T17:08:14Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qcD2hzGwCQYqWPo by GrapheneOS@grapheneos.social
2025-06-12T17:09:57Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qcIfX4LxpsQ367k by GrapheneOS@grapheneos.social
2025-06-12T17:10:54Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qcOg6j7zOVwMdqy by GrapheneOS@grapheneos.social
2025-06-12T17:12:23Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qcUZaoGLKnTMWX2 by GrapheneOS@grapheneos.social
2025-06-12T17:13:16Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3qqtrtYkaXIpnFXU by Suiseiseki@freesoftwareextremist.com
2025-06-12T17:28:50.592535Z
0 likes, 0 repeats
@GrapheneOS >It's also trivial for an attacker with temporary access to the phoneWith physical access you are gone no matter what.Only a fool would think it's possible to defend against physical access via software means - only physical denial of access will work.
(DIR) Post #Av3rdGgw0Sm3zIjLJw by GrapheneOS@grapheneos.social
2025-06-12T17:28:56Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3rdHunSPSNmaDvZA by GrapheneOS@grapheneos.social
2025-06-12T17:30:28Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3rdJ8euM8hZriVoO by Suiseiseki@freesoftwareextremist.com
2025-06-12T17:37:33.117917Z
0 likes, 0 repeats
@GrapheneOS >Connecting a modem via USB exposes an enormous amount of attack surface to the modem via the kernel's USB stack and drivers.Harden the stack then and prove it is secure with a mathematical proof then.>That's far less secure than having an IOMMU isolated modem with DMA using a typical approach. Having a modem go boot the device up and then decide to enable IOMMU is much less secure.>The Pinephone's modem is far less secure against attacks and missing important patches. No need for a backdoorWhy would you bother with attacks when you just use the backdoor built into each modem?>Since the isolation is far worse, it's easier to take over the OS from it.You would have to actually do an exploit, rather than having the modem trigger a reboot, write to the memory and then go enable IOMMU after.>Replicant has atrocious security and non-existent protection from this, not more.The built-in modem-to-storage backdoor is no longer functional.You can get quite good protection - you just disable the modem software loading library and then the modem does not run.>The extra CPU it has running a closed source and outdated fork of Android does not exist on a normal, sane modem.All modems are insane - an extra CPU or not that runs an extra proprietary program is irrelevant.>Replacing that is not replacing a component which exists on normal devices.But if you replace that with free software, or use free software to make it do nothing, then it doesn't matter.The free software userspace for the modem is available here; `git clone https://github.com/the-modem-distro/pinephone_modem_sdk` - google doesn't have that do they?
(DIR) Post #Av3rdNYKUr3BGdl4Nc by GrapheneOS@grapheneos.social
2025-06-12T17:31:45Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3rdTJf4Isl8swRLk by GrapheneOS@grapheneos.social
2025-06-12T17:33:05Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3rdZHksIvFei60DA by GrapheneOS@grapheneos.social
2025-06-12T17:37:06Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3rlGlhbXIoXim9c8 by Suiseiseki@freesoftwareextremist.com
2025-06-12T17:39:01.998286Z
0 likes, 0 repeats
@GrapheneOS I never made any claims that the pinephone was safe - all I pointed out was that it is actually possible to make it run 100% free software and then it would be possible to have security (but not privacy, as the modem spies on your location).
(DIR) Post #Av3rlz2Z0Cvxql0F0K by sally@freesoftwareextremist.com
2025-06-12T17:38:26.265737Z
2 likes, 0 repeats
@Suiseiseki @GrapheneOS Aw shit, GNU/Suiseiseki is lecturing the security nuts fron GrapheneOS.Graphene is cooked.
(DIR) Post #Av3s5ErsNbq4RNBZ7A by Suiseiseki@freesoftwareextremist.com
2025-06-12T17:42:38.640437Z
0 likes, 0 repeats
@GrapheneOS By the way, firmware is a socketed ROM chip.If you can load it, or it's loaded from a NAND chip, it's software without firmness, no matter what processor it runs on!
(DIR) Post #Av3sXtzR5CkS5POC6i by raccoon@hollow.raccoon.quest
2025-06-12T17:47:49.854Z
0 likes, 0 repeats
@GrapheneOS@grapheneos.social @Suiseiseki@freesoftwareextremist.com What about fairphone? Is that atrocious too?
(DIR) Post #Av3uOyR5NplPB3C0eW by GrapheneOS@grapheneos.social
2025-06-12T16:36:59Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3uOzXVHSUWbFCeIK by GrapheneOS@grapheneos.social
2025-06-12T16:37:32Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3uOzuBv6dhjboleq by GrapheneOS@grapheneos.social
2025-06-12T18:03:47Z
1 likes, 1 repeats
@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.
(DIR) Post #Av3uP0CcoZNuemRUOG by GrapheneOS@grapheneos.social
2025-06-12T18:04:46Z
0 likes, 0 repeats
@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.
(DIR) Post #Av3uP0WTclGReLjLKi by GrapheneOS@grapheneos.social
2025-06-12T18:06:07Z
1 likes, 1 repeats
@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.
(DIR) Post #Av5RIbkQJd5yieln96 by lispi314@udongein.xyz
2025-06-12T20:43:43.285353Z
0 likes, 0 repeats
@GrapheneOS @Suiseiseki > connected to the main CPU via very high attacksurface USB.Ah, so it's not through serial. That's very unfortunate.
(DIR) Post #Av5RIcfUtQkVZfTN6e by Suiseiseki@freesoftwareextremist.com
2025-06-13T11:51:55.555855Z
0 likes, 0 repeats
@lispi314 @GrapheneOS Yes, it is via serial - the Universal Serial Bus (too bad you can't bitbang raw serial over it).A protocol over sufficiently high baud raw serial to exchange audio packets and signalling information would likely have a similar attack surface.
(DIR) Post #AvEHpKCDLKtaikN0Bk by GrapheneOS@grapheneos.social
2025-06-12T17:01:16Z
0 likes, 0 repeats
@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.
(DIR) Post #AvEHpKo94JEkcO7IJM by frej@fosstodon.org
2025-06-12T17:27:57Z
0 likes, 0 repeats
@GrapheneOS Wouldn't it be less complicated to collaborate with other brands like #FairPhone or #Volla, for example?
(DIR) Post #AvEHpLMX0Sk6L2CkuO by GrapheneOS@grapheneos.social
2025-06-12T17:43:36Z
0 likes, 0 repeats
@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.
(DIR) Post #AvEHpLjDe6tHTOosGu by sxa@fosstodon.org
2025-06-17T18:01:19Z
0 likes, 0 repeats
@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)
(DIR) Post #AvEHpMDholHEzx5Dn6 by GrapheneOS@grapheneos.social
2025-06-17T18:15:10Z
0 likes, 0 repeats
@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.
(DIR) Post #AvEHpMSwu5TDlEDOYC by GrapheneOS@grapheneos.social
2025-06-17T18:17:02Z
1 likes, 1 repeats
@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.
(DIR) Post #AvEHpQoij5GJFuQq2a by GrapheneOS@grapheneos.social
2025-06-12T17:43:54Z
0 likes, 0 repeats
@frej Our hardware requirements are listed at https://grapheneos.org/faq#future-devices. 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.
(DIR) Post #AvEHpWuy2lpAB1Oubw by GrapheneOS@grapheneos.social
2025-06-12T17:45:25Z
0 likes, 0 repeats
@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).