Conversation

Notices

1. Embed this notice
   GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:18:05 JST GrapheneOS

   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.

   • :blobcathug: likes this.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:55 JST GrapheneOS

     in reply to

     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

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:56 JST GrapheneOS

     in reply to

     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.

     Cadu Silva :verifiedcat: and Gianmarco Gargiulo repeated this.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:57 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:57 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:58 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:59 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:29:59 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     :blobcathug: (jain@blob.cat)'s status on Friday, 13-Jun-2025 00:39:19 JST :blobcathug:

     in reply to
     @GrapheneOS :blobcatfrowningbig:
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:42:32 JST GrapheneOS

     in reply to

     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.

     Rich Felker repeated this.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:42:33 JST GrapheneOS

     in reply to

     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

     Rich Felker repeated this.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:42:41 JST GrapheneOS

     in reply to

     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.

     Rich Felker repeated this.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:42:47 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 00:54:25 JST 翠星石

     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?
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:54:26 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 00:54:27 JST GrapheneOS

     in reply to

     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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 01:53:07 JST 翠星石

     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.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 01:53:08 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 01:53:09 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 01:53:09 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 01:54:53 JST 翠星石

     in reply to

     • Miaourt ✨
     • News Junkie
     @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?
   • Embed this notice
     News Junkie (wifihugger@mas.to)'s status on Friday, 13-Jun-2025 01:54:58 JST News Junkie

     in reply to

     • Miaourt ✨

     @Miaourt @GrapheneOS why can't people just make a New Kernel or simply make a new operating system? Why is this so hard?

   • Embed this notice
     News Junkie (wifihugger@mas.to)'s status on Friday, 13-Jun-2025 01:54:59 JST News Junkie

     in reply to

     @GrapheneOS isn't this a good thing though? Android being taken out of Googles control?

   • Embed this notice
     Miaourt ✨ (miaourt@raru.re)'s status on Friday, 13-Jun-2025 01:54:59 JST Miaourt ✨

     in reply to

     • News Junkie

     @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

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:26:08 JST 翠星石

     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; https://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor
     
     >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; 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/eMMC
     
     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; 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?
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:26:09 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:28:53 JST 翠星石

     in reply to
     @GrapheneOS >It's also trivial for an attacker with temporary access to the phone
     With 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.
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:28:54 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:28:55 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:28:55 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:28:56 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:28:57 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:37:36 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:37:36 JST 翠星石

     in reply to
     @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 backdoor
     Why 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?
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:37:37 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:39:04 JST 翠星石

     in reply to
     @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).
   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:39:05 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:39:06 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     GrapheneOS (grapheneos@grapheneos.social)'s status on Friday, 13-Jun-2025 02:39:07 JST GrapheneOS

     in reply to

     • 翠星石

     @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.

   • Embed this notice
     𝅙𝅙𝅙𝅙𝅙𝅙𝅙𝅙 (sally@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:39:13 JST 𝅙𝅙𝅙𝅙𝅙𝅙𝅙𝅙

     in reply to

     • 翠星石
     @Suiseiseki @GrapheneOS
     
     Aw shit, GNU/Suiseiseki is lecturing the security nuts fron GrapheneOS.
     
     Graphene is cooked.
     翠星石 likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 02:42:41 JST 翠星石

     in reply to
     @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!
   • Embed this notice
     Gianmarco Gargiulo (gianmarcogg03@mastodon.uno)'s status on Friday, 13-Jun-2025 04:15:07 JST Gianmarco Gargiulo

     in reply to

     • 翠星石
     • Trash Panda

     @raccoon @Suiseiseki @GrapheneOS read this: https://grapheneos.social/@GrapheneOS/114671630177160997.

   • Embed this notice
     Trash Panda (raccoon@hollow.raccoon.quest)'s status on Friday, 13-Jun-2025 04:15:09 JST Trash Panda

     in reply to

     • 翠星石

     @GrapheneOS@grapheneos.social @Suiseiseki@freesoftwareextremist.com
     What about fairphone? Is that atrocious too?

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 13-Jun-2025 20:51:58 JST 翠星石

     in reply to

     • LisPi
     @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.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Friday, 13-Jun-2025 20:51:59 JST LisPi

     in reply to

     • 翠星石
     @GrapheneOS @Suiseiseki > connected to the main CPU via very high attack
     surface USB.
     
     Ah, so it's not through serial. That's very unfortunate.