phasephantasm

(3/3) Google being the single entity stewarding AOSP' development is a worrying truth in some ways the post accurately calls out but it misses the mark in others. In any case, it certainly is not much less idealistic to propose any way of making AOSP more decentralized in development than it is to expect non-AOSP to catch up given the premises of its advantages are either false or a misrepresentation (eg. ignoring that launcher apps exist on Android and going on a weird rant about it, saying AOSP has privacy invasions without proof - note AOSP has no Google services - when the opposite is true, etc). And if only one non-AOSP OS needs or deserves to succeed, what does that say about the importance of decentralization or whatever?

Lastly, a little pet peeve I have is with trying to push forward an idea of what is "commonly accepted" as the definition of "Linux" that completely ignores embedded systems, for a start. If you know, you know, which should be enough said as a response to an undefined common sense invocation. Linux is not GRUB, systemd, glibc, GNU coreutils, freedesktop.org standards and GNOME, nor is it defined by other software being drop-in replacements to those that have been mentioned (in terms or API compatibility or, for GNOME, in terms of being an arbitrary userland program choice). Linux is a kernel which AOSP uses with not really more divergence from upstream than an embedded Linux system that is still considered a Linux system exactly because Linux is not a definition of one OS, despite a hypothetical embedded system also potentially having a vastly different userland to traditional desktop and server Linux OS', maybe programs built using different SDKs than GTK and QT and SDL, a slimmed down kernel to purpose which, similarly to Android, is just built differently rather than significant new code. Every platform, whether mobile, embedded (as per this arbitrary-ish distinction of mine), desktop or server, will feature different drivers, firmware distributions or hardware tooling too, although desktop and server distros typically package and ship everything because why not, I guess.

I would make this comment thread longer and more comprehensive, had another user not done an analysis the size of my ambition which I largely agree with. [1]

[1] https://news.ycombinator.com/item?id=50268748

Edit: I failed to note that AOSP actually runs fine on mainline kernels, and even desktop and server Linux systems use a distro-vendored kernel build, with configuration at the distribution maintainers' discretion, which is only one degree of separation removed from what I indeed talked about.

(2/3) Flatpak is very far from a sufficient sandbox when app developers define their app's permissions, users either need to interact with the `flatpak` CLI, install a third party app or be KDE Plasma users in order to edit app permissions, many permissions are granted superfluously and users who mean to revoke them really have no way of knowing what is necessary for an app's correct operation, nor do apps themselves know since developers clearly will not bother implementing functions to test for a permission having been granted at all (much less in a benign manner) and Flatpak does not have an API apps can query to know about their current permissions game, much less ask for permissions at runtime. If an app had the ability to invoke the `flatpak` CLI to query its own permissions, there goes too an ability to alter them at will. Lots of permissions are obtuse to a user and mean sandbox escapes via specific (or even broad) filesystem access, certain D-Bus accesses, and other permissions including network (where I consider the implied localhost access a risk; Android 17 introduced a local networking permission, for contrast). Flatpak does not solve apps that play audio being inherently allowed to record audio, whether from microphones or arbitrary program's outputs. A lot of its faults are observed even simply by noting what they wish to improve on [0].

There are none of the few implied protections for apps that aren't Flatpak. Who exactly is empowered by not restricting even common apps' reach over your every thing on your computer? Power user use cases are best considered with careful design choices and are not a good excuse to let everything have access to everything by default, or have an insufficient difference be decided by packaging formats like Flatpak, specially when so many developers outright reject it or misuse it and don't perform basic Flathub developer verification (which isn't even developer package signing, just proof of web domain ownership, making more unfathomable the fact so many choose to skip it).

FOSS doesn't mean free of malice or supply chain compromise risk, so acting like programs from any source are worthy of trust just because "of course" doesn't make sense. That is acting like security only matters when you think you aren't immune, for arbitrary reasons. It is simply sensible and effective to not trust programs and isolate them according to principle of least privilege, which handsomely agrees with the fabled UNIX philosophy. Android doesn't sandbox apps because it distrusts them from a "moral judgement" standpoint, contrasting with what the post, in a way, implies. An AOSP OS' primary app store is its trusted app source in the sense it has a little less friction to use than other app sources, but all apps are subject to the sandbox either way, including system apps. There are FOSS apps distributed in various app sources, including Play Store.

[0] https://blog.sebastianwick.net/posts/flatpak-happenings/

(1/3) Let's estabilish some axioms. Firstly, user experience in non-AOSP and non-iOS mobile OS' is rocky, to be polite, and whoever uses them usually admits such fact wholeheartedly. Secondly, much like Linux isn't an OS, Android isn't either (AOSP is); the post didn't consider AOSP-based OS' as even belonging to the same conceptual box of "there are many of these" (let alone go beyond this), but the same concept is considered a great thing about non-AOSP mobile OS'. Lastly, the post is very idealistic.

The proposition of dreaming about distinct non-AOSP OS' undergoing immense changes in order to catch up to what constitutes a good user experience and actual user empowerment make the entire thing a non-starter since it requires being very idealistic to argue in favor of, specially when you consider that idealistically it is more worthy to further advance AOSP-based projects, whether in terms of OS development, reverse engineering, or taking part in the development of more user-respecting and useful apps.

Non-AOSP Linux OS' do not empower the user in terms of privacy and security because users are not able to restrict resource access from applications at will and with ease, whereas AOSP employs a runtime permission model where the user is asked what access they want to grant to an app, only when it means to access it. This includes ephemeral (time- and focus-based) access where it makes sense (eg. microphone and camera, and location, respectively), as well as granular file and media access for apps using modern APIs, which they are forced to if they want to target higher API levels (newer Android versions) which deprecate older APIs in isolation. API level 34 (Android 14) finalized the introduction of granular file and media access. New AOSP versions progressively employ more privacy and security protections considered in the design of the platform API (nonwithstanding the design of the rest of the OS), and AOSP has solid backwards compatibility because SDK targets are fixed and don't change between releases, to a point apps that target lower API levels can use older AOSP APIs that exist in such API level, which have less solid privacy protections... although even then, the permission model is sovereign.

As such, any app store worth its salt will delist apps that fail to keep up. Today, Google Play Store only lets users download apps targeting API level 34 (Android 14) or lower if a device runs Android 14 or lower. New apps and app updates must target API level 36 (Android 16). Apps targeting even the latest API level are still compatible with many old Android versions, with how far compatibility goes being a developer choice. The aforementioned granular media access APIs remained stable since Android 13, file access APIs for longer, and needed little adaptation going forward since their introduction, yet users got progressively more control over apps in their device.

It appears pretty clear that you are active there too to both inform yourself of your "sworn enemy" (to orchestrate your own attacks) and to denounce the existence of a clearly benign effort, what you just did. Because if it weren't benign, then could you ever point to evidence, for a start? Maybe comments that resort to the same rethoric techniques as yours instead of bringing correct information, and politely so.

It greatly discredits what you say about us, the GrapheneOS community, when not only all you have are ad hominem reactions (against the entirety of the community it seems, as well as against the developers[0]) but you are guilty yourself[0] of what you accuse your enemy of, persecution / harassment.

[0] https://news.ycombinator.com/item?id=47217356

What further evidence is necessary after your own Discord screenshot in your comment I'm replying to? It is quite bizarre how this platform allows this to go on.

It exists for whom wants it and is a recommended app source, that's all. Something not recommended would not be explicitly supported, deciding whether to use it or not is ultimately on the user who will not be warned against something that is supported...

It is not recommended over vastly more sane alternatives like Accrescent and getting apps directly from their respective developers (as signed by them) given you have an update mechanism of your own (or the app embeds one) and a manner of verifying the app's public signing key's provenance as something actually belonging to the developers you got said app from (where the former is a proper app store in construction and the latter is nigh impossible to perform cleanly due to typical developer non-cooperation). Nonetheless, Play Store ranks below these two for a third-party app source as it engages in weird practices like Play App Signing, etc. Users are not advised to get Play Store apps from non-Play Store app sources because Play Store already ranks the furthest behind, meaning nothing is recommended beyond it.

Aurora Store is recommendable in exceptional cases, namely when an app can't be downloaded from Google Play due to Play Integrity gating on the app's store listing, but which is known to work (eg. not perform Play Integrity checks itself in the intended manner, etc) after somehow downloaded and installed.

Although as you can verify, this recommended app source ladder is pushed on social media and official chat platform community spaces of GrapheneOS, not the website.

You are an account created 8 hours ago parroting an eerily similar point[0] to an account created one hour ago. I have not even scrolled down all the way.

[0] https://news.ycombinator.com/item?id=49971519

Where do I start. Was anyone ever doxxed or is that an empty accusation? Why do you think PrivacyGuides, banned from GrapheneOS community, would do that for the community they were banned from? Really weird to accuse both (ambiguosly "both", by the way you wrote) groups of that, without evidence no less. Who did they lose support from? Since when are non-Google options not explored?

On that last note, they have been looking for an OEM partner for a long time, and as of the last couple years, were thinking of commissioning an ODM for a supported device. A massive spending of resources but a necessary one since far before that, but that became more pressing two years ago. An OEM partnership is far more favorable, and that is what has been struck with Motorola, who approached GrapheneOS for said partnership and not the other way around.

Ironic, you are being an example of what you project. People come out of the woodwork to say what you do, then respond to comments like mine with "maybe there is a reason for it"... but if you're gonna leave it to "maybe", you should just zip it yourself really.

We are told the OEM in question is not Motorola, and it's likely some benefits of the Mototola partnership aren't yet in effect due to silly bureaucracy. Not sure there is any reason to lie about this.

Embargoed ASB patches started being used in release 2025092500, but I can't find now the message where a Motorola employee (confirmed by a community moderator, spring-onion, in a Side of Burritos interview) first reached out publicly on the GrapheneOS Discord guild about how to obtain further technical guidance than the requirements list in the website which claims to be non-exhaustive, in order to confirm such message's date. Still, GrapheneOS claims (after the partnership announcement March this year) that ASB patches are provided by (effectively) a distinct undisclosed OEM, really meaning an employee is leaking them. Maybe even the person didn't disclose the OEM they work for but they must be associated to one in order to have access to this material.

Accrescent has been quiet for a while, but had claimed in the past they would open the store up for new submissions again soon, it will perhaps happen by the end of the year. Its self-imposed requirements for this are to provide a better developer experience and more common app store features developers (should) expect. They recently announced they will be posting more about the progress made towards such goal, after the big announcements and releases of some months ago.

I'm more worried about the lack of a police to take apps down when it is very clear they should not be there. This is a present problem, presently solvable and that is not acknowledged despite the fact it harms the user.

Perhaps you misunderstood why is criticism voiced in the first place. What you ask for is here, as it has always been:

> https://grapheneos.org/faq#future-devices

A part of the criticism of Fairphone is exactly that they aren't even particularly sustainable or repairable, or ethical, have you read the posts. So there is no choice, not between the two groups you presented as opposing. They aren't even opposing each other as currently Pixels stand as fairly easy to repair and source some genuine parts for via Google's official iFixIt partnership.

An OEM reads the link above and gets the ball rolling as it should, privately, which was what Motorola did after showing up on the public Discord guild with an employee asking for further directions, but being aware of the linked resource already. Obviously GrapheneOS' merit is provably the product and the values it represents, not posts on social media (how could that make sense?). Think of that and how this one-sided criticism of "you should do that to avoid a certain image and get things done" of yours makes no sense either - it didn't scare anyone who would ever: currently only Motorola.

Edit: adding to the last point, the same applies to Fairphone but inversely, where they portray themselves as things they are not (sustainable, specially repairable, ethical, even privacy-respecting). Whereas a takeaway from your comment is that GrapheneOS is good but has a negative image (a false premise, in my opinion), Fairphone puts a lot of *effort* to construct a good image that signals the inverse of what they are. Effort ultimately signals intention.