zlacker

I hope the so-called blobs have been replaced with unprivileged opensource versions.

Otherwise privacy and security would be meaning basically nothing.

>>notora+(OP)
Open source doesn't provide any magical privacy or security. iPhones have solid privacy and security despite being mostly closed source software. iPhones are the next best options for privacy and security in most ways. They have great privacy from apps and aren't awful at privacy from Apple particular if people use Advanced Data Program for iCloud, and they have solid security overall along with some useful settings for it. GrapheneOS of course provides better privacy from the OS services. We provide a full list of default connections made by the OS at https://grapheneos.org/faq#default-connections and none are made by the hardware without the OS prompting it. GrapheneOS also defends better against sophisticated real world attacks, and there's real world evidence for that from leaked capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB (XRY) along with some basic info about remote exploit sellers.

All of the kernel drivers are open source, which would be the case for Snapdragon too.

Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things.

There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help.

If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.

>>strcat+9D
> If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access.

Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.

I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.

I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.

>>haukem+io1
Kernel drivers for all of the main Android hardware platforms are fully open source. It's the userspace libraries/services which tend to have a lot of code that's not open source. At least for Snapdragon, that's shared with OEMs so can be modified and built by them. Snapdragon also shares major parts of the firmware sources with OEMs too. Some parts of the firmware are open source.

>>strcat+9D
What about the blobs mentioned before? Those are closed source binaries running as root with direct access to the hardware, like the baseband modem. It can talk to the internet without any auditing being possible.