Replying to you here in hopes you see this question.

I'm one of those people who is affected by PWM on OLED screens. I tried a Pixel 9 Pro XL and it didn't work for me. Have a Razr 2024 which mostly works and that's thanks to some custom PWM settings from Motorola.

Will Graphene OS have these custom PWM mitigation settings on 2027 Motorolas?

We want to support cheaper devices too but flagships will be the first ones meeting all of our update and security features requirements. Providing hardware memory tagging (MTE) and a good enough secure element with the modern AOSP APIs are the main requirements for hardware security features.

Snapdragon 8 Elite Gen 5 is the only current Snapdragon SoC with hardware memory tagging since even the slightly lower end Snapdragon 8 Gen 5 didn't provide it due to being developed a bit earlier despite being launched later. They tried to provide it for both but didn't get it fully working in time. The next generation makes major secure element improvements. We potentially could have supported a Snapdragon 8 Elite Gen 5 with a secure element from another company but there wasn't enough time and the next generation is a lot better in multiple ways. There's still a large amount of porting and integration work remaining to do.

Pretty much the same story. I am hoping my iPhone 12 lasts until I retire and I won't need to carry a smartphone anymore.

We need the devices to meet our requirements so that's the main limitation. The current generation Snapdragon 8 Elite Gen 5 is the only one providing hardware memory tagging (MTE). Even the slightly lower end Snapdragon 8 Gen 5 doesn't support MTE. The next generation flagship SoC has improvements needed to meet our requirements. There's still going to be a lot of porting and integration work. We'll be the first ones using MTE for the whole kernel and OS as we are on Pixels so there's going to be a lot to deal with for it. For Pixels, Google did do testing for MTE across the OS internally but even on Pixels it isn't perfectly supported and we have to fix a lot of memory corruption bugs it finds in both the kernel and userspace.

I would bet that what Motorola can change without trouble on the lower end is more restricted, too. Generally low end models use more parts that are old, off the shelf, and/or shared with several other models to keep costs low, and so major changes can quickly balloon costs.

Bandcamp or buying CDs and ripping them, it doesn't take that long and each CD is a fire-and-forget task.

I'm using syncthing to avoid the chore of having to copy them into my SD card

For discovering new music, I listen to my old college radio station. About once a month they play something good that makes me do a deep dive. I use Pianobar while I work, and creating a station based on a new (to me) artist tends to give me more to explore. I also use music-map.com from time to time.

As for acquiring music, I use Bandcamp. If they aren't on there, I'm not above finding it via file sharing.

I have a bunch of python scripts that help me rename all my files once I get their tags sorted out. For that I mostly use AudioRanger because it's so simple and I only process one album at a time.

From there, I use Syncthing. But I'm thinking about replacing it with rsync and just kick it off manually when I want to update everything about once a month.

Not him but I can as well throw in my setup.

For playback, I mainly use Navidrome.

For autotagging and importing (moving files), Beets.

For tagging edge cases, MusicBrainz Picard as the GUI and the Python tagging lib underneath it (mutagen iirc) with an LLM inside the pi cli agent for automation.

For format conversion and copying to portable devices, ffmpeg in custom bash scripts managed by an LLM.

The Flip and Fold are. I see them available on the Motorola US store page.

New tablet support is very compelling! The Pixel tablet hardware is... passable... but Graphene on something more refined would be amazing! Especially something with a keyboard cover available (no idea if Motorola does this).

How is the crease on the flip? On some of the foldables like the samsung's, the crease is pretty noticeable and for me it bothers my OCD a little bit. I love the idea of a foldable though

I hope flipping devices sell well enough to continue being released because I think they are the best solution for the small phone people.

I've never really tried a flip but it does sound cool.

Graphene passes basic integrity, so most of them work. There is a list here:

https://privsec.dev/posts/android/banking-applications-compa...

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent.

Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.

Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.

GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.

Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.

Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.

I haven't tried using Wade Droid on a phone, but on a fedora desktop it is a little bit rough. It takes a lot of finagling to get anything that requires Google services running, and that is a surprisingly huge amount of apps that people want

I had to replace a credit card yesterday. Part of the default flow involves the call center sending a notification to your app. When I told them my android version was too old, it took them twenty minutes to find out they could instead send a text message. That text message sends you to a photo-and-id verification service, but that's another issue.

Soon, there won't even be an alternative flow. There are a lot of places where there already isn't.

Nothing is stopping you. You're free to use a desktop web app that either doesn't work or is terribly slow or has limited features on a mobile web browser. I'd love it if all apps were PWAs but that is not the case.

The websites don't have feature parity with the apps these days. Things like being able to deposit a cheque aren't available among other things.

> What's stopping me from using a browser to log in to my bank?

The "security module" they require you to install on your computer. In the past, when browsers had plugins, this was a browser plugin; nowadays, it's an always-on service (running as root) which exposes a local HTTP server which the bank site connects to to validate your computer. For an example from a major bank in this country (the same "security module" is used by several banks in this country), https://seg.bb.com.br/home.html is the diagnostic page for that "security module" (the FAQ page there has links to the installers).

Some banks are app only and/or build MFA functionality into their apps.

In many countries, all major local banks require their phone app as the second factor to log in to the browser version of their online banking. Sometimes functionality is removed from the browser version and made available only in the phone app.

The bank itself. They want to see where are you, what you do and snoop on anything they can about you. Having a spywa^W sorry, bank app is the best way to do that.

Source: my bank which recently 'upgraded' a browser version to a glorified SPA which even renders as a vertical oriented app on a landscape 4K monitor.

The bank website typically needs the app to enable two factor authentication in a lot of places.

For eg. There's no browser based alternative to make UPI payments that i know of.

The 2FA code you need to get from the phone app to log in on a desktop. It isn't 2005 any more.

Well, it's kinda hard to scan a QR code displayed on your screen when the camera is attached to its back (semi-joking)

Not true, if you install play services you can run 99.9% of apps, i can even run all the italian apps from yhe goverment. You are still using google but its running as user service and you can even revoke most of the permissions including location.

Running their sandboxed Play, I can run everything. The only thing I notice in the US is some banking apps (stupidly, idiotically, moronically) force 2FA on every login instead of trusting biometric entirely like they do on stock OS.

Using BMW digital keys seem to be a problem because of the lack of google wallet support (supposed to also be an issue on Lineage).

Anyone getting BMW digital keys to work on Graphine OS?

A lot of it is security theater plus lazy (as in "doing the minimum amount of work possible") compliance with regulations

But they care a ton about security theater. Advanced device integrity? That sounds secure to me!

I should make a chip called Super Security Sauce Silicon, and make cards with them, and market them to phone vendors so their customers won't need the card, and market them to banks so their customers will be secure. It performs Dual_EC_DRBG with my keys.

yea i straight up am not downloading apps anymore if i can help it. virtually zero companies put apps out to provide a better experience, they just do it to get telemetry data. which is why all these banking apps are just their website in some wrapper lol

You can run wasm components in tauri apps, and tauri supports building for android.

I haven't figured out how to make them talk with each other though. I imagine that's the place where I'd notice this lack of support.

I wonder if practices will change any of there's ever a device that ships with GOS. Right now, many companies are happy to shrug off GOS, because they don't support "modified devices".

If any of the Motorola devices have GOS as a pre-installed option, now the companies don't have the excuse that the device is modified.

I'm guessing the companies will continue to be difficult, but it'll be amusing to watch, at least.

Yep. Had to change banks because of my old one suddenly dropping grapheme support by adding stupid attestation mechanics.

They surely must have gotten feedback from me and others because the next update it worked again. But I and probably others where already a lost customer.

What is the point of apps for these things in particular? I understand that some banks require an app for 2FA, but I don't see why anyone would want some invasive healthcare app on their phone.

90% of those apps do work on GrapheneOS. A growing number are adopting the Play Integrity API but a growing number with it already implemented are choosing to also permit GrapheneOS.

90% of banking apps work on GrapheneOS.

https://privsec.dev/posts/android/banking-applications-compa...

Stop parroting this. It’s not true.

Diminishingly few apps do not work, and it’s down to them.

Traditional desktop Linux heavily involves big tech companies including IBM (Red Hat). AOSP has a massive amount of non-Google companies and individuals working on operating systems based on it. It would survive without Google.

You're misinformed about security preview patches. It has nothing to do with Google being hostile. Additionally, our security preview releases have regularly included patches for components not specific to Android such as wpa_supplicant prior to those being publicly disclosed by the upstream projects.

I believe the timely security patch issue will be resolved with the Motorola phones due to the OEM partnership.

Long term in the future, surely the open source community forks AOSP itself and maintains it. The worst option would be giving up and trying to focus on Linux (desktop) imo.

Well, if you want a mass market device that runs Linux, you have to meet the market. Otherwise we can start tracking 2525 as the year of Linux on the smartphone. If man is still alive.

Because there are only a few people who actually build this kind of software and if they cant agree how it should look. No projects will have the dev power to come out with a solution.

You can strongly disagree but it doesn’t change the fact that the comment by the OP is objectively true.

Especially in this political climate it’s insane to recommend people switch to a phone OS that can be pwned via hardware or software means in virtually zero time versus something like GOS + a Pixel or an iPhone.

What a colossal disaster. I was a huge Windows Phone fan, so their yearly missteps were quite painful to watch. I was especially annoyed when my first gen WP wasn't going to get an upgrade to WP8. My HTC 7 Pro is still my favourite phone I've ever owned, but after that I finally gave up and switched to Android.

A lot of "non Android Linux distributions" like sailfish os actually use a lot of Android infrastructure to keep working.

Drivers doesn't just mean the kernel. It's the user space binary blobs and services that need to talk to the kernel to enable the hardware.

Other than that there's waydroid, alien dalvik etc.. that run another Android instance in a container.

The thing is a lot of Android applications use safety net/other methods to make sure they only run on. "Approved"/stock hardware.

Android has a proprietary HAL on both ends; the userspace interfaces to drivers are not the same as on "normal" Linux for almost any devices (baseband, video acceleration although this is at least EGL based, cameras, sensors, audio DSP, hardware media codecs, etc.), so by the time you replace every component of the OS, you've just made AOSP without the useful security parts.

> The advantage being, we can manage packages using a regular Linux distro

It's much easier, more plausible, and more logical to sandbox a regular Linux package-managed distro inside of Android, which numerous solutions exist for.

You can't because a lot of apps check that the phone is controlled by Google with Play Integrity.

Google thought about this, don't worry. They learned their lesson after CyanogenMod tried to compete by offering an alternative. Non-Google Android are now dead except in China.

This is exactly where my head goes. There's nothing special about this hardware other than its small form factor. Sure, some desktop apps would likely want a different skin, but thats hardly limiting.

I miss my Windows Phone...

It doesn't. There was a plan, but Microsoft abandoned it.

Cheers, thanks for all the work you do on the project.

There is still a philosophical reason for supporting a version of Linux for mobile devices that is not dependent on Google, but is community-driven, for users with different priorities.

That is not really relevant to the GOS project though, and the fact that GOS is probably the easiest way to get a Play Services-free mobile device kind of drags it into discussions that it doesn't necessarily belong in.

Again, thanks for your work, and I appreciate your team's focus on your goal of the best security possible.

It seems like such a missed opportunity for China to challenge American dominance overseas.

Atomic distributions don't provide the security of verified boot or the far better mandatory app sandbox and permission model on Android. Flatpak is catching up to Android from 15 years ago, but it isn't mandatory. Android continues making backwards incompatible privacy and security improvements via new target SDK versions on a yearly basis with apps forced to adopt it within around a year. It continues moving towards a more private and secure model for apps.

GrapheneOS makes our own major improvements to the permission model, but we cannot enforce apps adopting it and need to design it all to be backwards compatible. We do that for Contact Scopes, Storage Scopes, our Sensors toggle and other features but not everything can be done that way. For our exploit protections, we have toggles to work around apps with memory corruption bugs or bad practices such as dynamic code loading. Android can enforce apps improving in a way we can't do. We're starting from a platform with a mandatory app sandbox and relatively modern exploit protections though. Android also does support using hardware memory tagging or HWASan to test apps even though many developers aren't using those to clean up their memory corruption bugs.

No, it doesn't come anywhere close to the privacy or security provided by AOSP.

You could be dividing up your projects into highly sandboxed environments on Android too. It has support for running multiple hardware accelerated virtual machines running desktop Linux and it wouldn't be that hard to support creating those with NixOS and other distributions instead of only the standard the Debian images provided by Android. That will happen as it gets more mature.

See the explanation at https://news.ycombinator.com/item?id=49364220 for why desktop Linux is nowhere close to AOSP for privacy and security. If you want more details, there's a lot of deeper coverage.

> AOSP is only more "secure" because, on some devices like Pixels, it exploits hardware features typically not found on general purpose computers.

You don't think, say, isolating apps has anything to do with it?

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent.

Hardware-based security features including hardware memory tagging, a high quality secure element providing high quality interfaces for improving security, proper verified boot and more are definitely important too, but they cannot simply be bolted onto an OS. The OS needs to be built around being able to take advantage of these features.

Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.

Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.

GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.

Android is a large Linux operating system family. It's the mainstream form of Linux on personal computers. Android users are Linux users. For privacy and security, using a monolithic kernel written in C is definitely not a good thing. Doing much better than we are today partly requires moving away from so heavily depending on the Linux kernel for security. Android does a lot of Linux kernel hardening with attack surface reduction and exploit protections which are improved by GrapheneOS, but it's not enough. The massive torrent of severe vulnerabilities being discovered in the Linux kernel is going to get worse before it gets better and will remain a problem. Adopting hardware-based virtualization for isolation of apps and OS components including drivers is an important part of our roadmap.

It also has many other advantages including the OS and app ecosystem heavily using memory safe languages from the beginning, which has greatly increased over time. The majority of new code added to the OS has been in memory safe languages for years. Android is replacing Java with Kotlin and C++ with Rust but it was always using a lot of Java and moved to using ahead-of-time compilation for it with Android 5. It then moved to a more complex way of compiling it but GrapheneOS has kept using ahead-of-time compilation.

It has much better adoption of modern exploit protections and far better testing with sanitizers for both the kernel and userspace. It enables us to do even better because most of the memory corruption bugs caught by MTE are resolved. We do still need to resolve more, but it would be far more impractical for us to do it on the desktop.

Android uses SELinux for both whole system MAC and MLS policies with deep OS integration. It uses it for a massive amount of kernel attack surface reduction with allowlists for socket protocols, devices, ioctl commands and other functionality. It's far different from the traditional targeted approach used by desktops or even rare use of whole system SELinux for desktops/servers. It's nearly a completely different thing in practice. The OS has it deeply integrated in userspace for enforcement beyond in the kernel and it's developed around it. It's the main basis for the app sandbox and a lot of other isolation in the OS. OS processes are specifically split up and have IPC set up in a way that they can be contained well with it.

The mandatory app sandbox with yearly backwards incompatible privacy and security improvements as part of new target SDK versions is the most important difference. It's the basis for GrapheneOS being able to do much better. Having the infrastructure it already has available means we can add our features such as Contact Scopes, Storage Scopes and our Sensors toggle on top. We plan to add a lot more, but there are also the yearly improvements we get in the baseline such as how Camera, Microphone and Location have supported one-time grants for years, can only be used while apps are in use once granted (with Location have an extra layer of background opt-in) and precise vs. coarse location.

  > but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.

SteamOS, very similarly to Android, entirely depends on a corporate benefactor leveraging a parallel user space that happily bypasses the "normal" community-supported parts of a typical Linux desktop distro wherever they present an obstacle. It proves that a company with deep pockets could indeed create a new mobile Linux distro (by writing lots of checks and cutting out large chunks of desktop Linux in favor of custom implementations entirely under their control).

> I have read your marketing materials

GrapheneOS is a non-profit open source project. We provide documentation and other information on the project.

> Android is not a Linux distro nor is it directly derived from Linux

Android is a family of Linux distributions. Linux is a kernel without a specific userspace and there are many different choices of libc, shell, init system, command-line utilities and far more. There are even more choices for the high level user interface. Android's userspace is largely specifically written to run on top of the Linux kernel with extensive use of SELinux and other Linux-specific APIs. A lot of the software you're considering to be Linux also runs on FreeBSD and elsewhere. FreeBSD is not Linux and the traditional desktop software stack largely shared with FreeBSD isn't Linux either.

Android Open Source Project uses the upstream Linux LTS branches. The upcoming devices with GrapheneOS support from Motorola use latest Linux 6.18 LTS branch. We plan to port to newer Linux kernel branches throughout the lifetime of the devices. Google already does that for Pixels and it needs to start happening for other devices too.

The upstream Linux LTS branches largely exist for Android with Google contributing a lot of the resources for it. Ubuntu and RHEL make their own LTS branches rather than using the ones from the Linux project. The lifetime for the upstream branches was increased from 2 to 6 years alongside Pixels increasing the support time to 5 years with the Pixel 6. It was decreased from 6 to 2 years because Pixels have been smoothly moving to newer kernel branches in production. It demonstrated the lack of need for the longer LTS branches not only for Android but more broadly. Pixels moved to 7 years of support with the Pixel 8 which wouldn't have been possible sticking to 1 kernel branch without a further lifetime increase.

> Mobile phones are not "personal computers".

Mobile phones are absolutely personal computers and should be treated as such. Many people use a mobile phone as their main personal computer. In large parts of the world, mobile phones are people's only personal computer.

GrapheneOS can even be hooked up to a monitor, mouse, keyboard, game controller and other accessories. It has a very functional desktop mode. It can also run desktop Linux applications via the hardware accelerated virtualization support. It even has opt-in GPU acceleration via gfxstream. That's all standard functionality from the Android Open Source Project.

> Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable.

There are billions of Android users. Each of those users is a Linux user. Linux is the dominant OS family on personal computers due to Android.

> And I take issue with the notion that a monolithic kernel cannot be secure.

A monolithic kernel written in C with an extreme focus on performance at the cost of having immense complexity is not reasonably secure. Piling on better exploit protections is useful but has a limited impact and those protections don't work as well in the Linux kernel as they do in the much more security-oriented userspace. Everything in the kernel being in the same address space with no isolation for regular code is not a good setup for security and severely hinders the usefulness of many exploit protections.

Further reducing attack surface even more than Android does is possible but is difficult while maintaining app compatibility. Hardware-based virtualization is the most realistic approach to dealing with the insecurity of the Linux kernel to properly protect it from userspace.

Protecting drivers from exploitation largely involves moving most of the code to userspace which is the norm in the mobile world and should expand much further. Bluetooth, Wi-Fi and other code can be largely moved out of the kernel. Moving TCP/IP, filesystems and many other drivers out of the kernel is entirely possible. However, it starts to run up against the Linux kernel having a culture and approach strongly against doing it. The same thing has happened with the attempt to introduce Rust in the Linux kernel with immense resistance and obstruction to simply providing bindings to write non-core drivers in it. There's no current attempt to use Rust in the core kernel and it would be an immensely slow process even if that was happening.

Hundreds of severe vulnerabilities being found per month with only a subset of those getting fixed is not a sustainable approach to making a reasonably secure OS.

> then why arent you guys working on the next kernel for personal and high-performance computing

We're doing initial work on expanding use of hardware-based virtualization to further reduce reliance on the Linux kernel for security. We're also building up our resources to be able to take on much bigger projects. Aside from that, we don't need to be doing things entirely on our own.

A lot of what we want aligns with where AOSP is already headed and many others want the same things. AOSP added hardware-based virtualization with the userspace code written in Rust and a more secure approach to handling it in the kernel (pKVM) without our involvement. AOSP also began to make very limited use of this for OS sandboxing itself. We want to do much more with it and use it for sandboxing apps, which are not things Android is currently working on as far as we know but likely will be in the future.

> you can't compel someone to support your niche platform

You mean, a browser?

well, apparently not even Microsoft had enough capital.

It's almost like the free market only works when we have well-defined and regulated markets. This has been known by Adam Smith and quite logical, yet people expect Google and Apple giga-corporations with monopolies to somehow abide by the laws of selling grains on the market.

Yes, but that is still very confusing to me, because you're not paying other people money so that they just follow incentives without thinking, vision or backbone.

The whole idea of buying something is giving people money for their (assumed correct) judgement, which then leads to desired artifacts downstream.

[flagged]

That's really unfortunate. Revolut has luckily been working well for me but time will tell...

Well.

Lest you forget that modern computing exists because ATT built unix and then threw it out to the public, at speed, as they drove away from it as fast as possible. (Something about being an actual monopoly...).

There is at least one thing, on that list that I can almost assure you will be coming back (in concept and spirt) in the next 5 years. Likely open source, because google tossed it...

Meanwhile it has other very public and open winners: Golang, Kubernetes being two stellar examples of them not dropping something like a hot potato.

Sounds like a cheap way to get my hands on some floppies.

GPL requires providing the source code via a medium customarily used for software interchange. Deliberately making it inconvenient by using a medium no longer customarily used for software interchange is a GPL violation. Google Drive is already an unusual way to distribute software.

Google is already failing to provide the Pixel kernel drivers in the preferred form for modification. Their kernel build system uses Git commands but yet they aren't providing the Git repositories it expects to be there. They had to provide a repo metadata file as a workaround but it's not the same since the revisions of the code aren't set properly in the resulting build.

Google is arguably already violating the GPL. They're deliberately making it inconvenient and are adding deliberate delays through requiring manual handling of the requests.

Greenbar printouts.

Isn't that the point of Google Play Services? To keep their proprietary code separate, in a super-app that doesn't obey the GPL?

Sometimes I wonder if randos peek in and see this terminology and think we’re all nut cases

There are other kernel 6.1 branches there, e.g. https://android.googlesource.com/kernel/common/+/refs/heads/...

I'm not sure which one the latest update for the Pixel 9a is using, I have an older Pixel 8. When I look at the Settings -> Android Version I can see it's using a build from January 2026 (also 6.1).

Yes I read the whole thread, but it wasn't clear which bits of source code required requesting a tarball.

Well, sounds like you have a rather weird definition of accountability. You do you.

It's quite painful to resolve cognitive dissonance, so I understand the downvotes for your comment.

People are clever enough to reach high level corporate roles, but at the same time they're are too weak to emotionally process the consequences of their "work" on their human cash cows of below-average intelligence.

However with these kind of moral/ethical questions, it's really hard to draw the line.

Is working at Google and thereby facilitating the scamming of my grandmother worse than being an ordinary pickpocket or an lobbyist for big oil?

This doesn't excuse a message that literally reads like call to action.

Plus the Samsung Exynos modems that they were using from Pixel 6-10 (11 switched to Mediatek) had worse power efficiency and performance vs Qualcomm.

So...what's your comment? Opposing Motorola's comment, in that they already buy the best? Supporting, in that their standards haven't dropped?

Except that it's all Android?

I'm not selecting which phone I buy on whether the stock OS comes with lockscreen shortcuts. At best, a software requirement someone might use as a deciding factor is OS support and bootloader unlock. The real differences are in hardware: size, battery life, chipset speed, RAM or other local model enablers, picture quality (this part also depends on good software to be fair), included accessories, satellite connectivity hardware, headphone jack, gimmicks like UWB or FM radio support, whether it's a flip/fold phone, storage space / sdcard support... all hardware differences

I can tell you from first-hand experience that it is true already (Well, it's true for the specific exploit/device pairings I've tried, I've not tried to construct an omni-exploit)

Completely random public example: https://github.com/BuSung-dev/Root-My-Galaxy-Payloads/pull/1... (where GLM 5.2 is credited with the port) (Check out the other PRs in that repo for other similar examples)

If a state actor wants to pwn your phone, they don't need to orchestrate a complex inter-organizational conspiracy to get there.

It would be funny if it actually was intentionally selected, but for DES-like instead of Dual EC reasons, and they're just too embarrassed by Dual EC to admit it.

[flagged]

Since more than a decade that MITM is not a mass event. It is a targeted event for selected users which are scored as having a low chance of discovering anomalous traffic. It first (publicly) started by government authorities sending fake updates to operating systems which then weaken the target machines or straight up RAT them.

Same case here.

>Of course they'll say they couldn't read it if they are after his contacts and network rather than after him.

From what a friend working in a state police cyber crime office says, "Cellebrite can't currently, unless its a Graphene OS user that's far behind on updates"

They also said iOS is equally safe unless you're an update or two behind.

> I ran Graphene without a Sim card for 2 months and as soon as I added a Sim card (with of course, difficult to vet networking) the phone is always hot and the battery life reduced by half. Might be a coincidence but also made me rethink how I feel about Graphene

Strange you're being flagged since it's easy to find many other people on the graphene forums reporting the same (unresolved) problem.

Doesn't mean it's guaranteed to be limited to graphene in scope, but definitely seems to be a prevalent issue for some yet-to-be-determined reason.

Possibly related, does anybody know if graphene is vulnerable to Pegasus?

My 9a running GrapheneOS doesn't get hot and battery life seems no different to other phones I've had the last few years.

You can ask on the forum for troubleshooting. Pixels just have bad performance unfortunately.

https://discuss.grapheneos.org

What Pixel do you have? Modem quality varies and signal strength could play a role. My 9a gets hot in areas with poor reception but is fine at work where I get over a gigabit down.

How many apps have network permission? Did you install anything from the play store at all? As a rule of thumb, the play store and everything on it is spyware.

I had the opposite experience. I was pleasantly surprised by the battery life you can get when your phone isn't full of shitware apps and even when you do install shitware, the OS helps you confine it.

That happened to my pixel running stock android and it was the 5G. As soon as I disabled it the battery lasted longer and the phone was way cooler. After all, I'm totally fine with LTE speeds

Did you check the forums or research for any benign reason that could happen? I've run Graphene on Pixel 9 and 10 and never had such battery issues.