For some user, /e/ is more approachable (Friendly and colorful UI)

I could not get my mother to use GrapheneOS, /e/ is a lot simpler.

Still miles better than to use a Default ROM from most OEM.

(/e/ used to be heavily based on an outdated version of LineageOS for microG. I'm not sure what the current state is after I settled on second-hand pixel with graphene)

So all apps with premium subscription you can only handle through in-app purchase, usually won't work.

I've heard that some banking apps are not working correctly either as not "secured" enough device, in my personal experience, they all worked, it's really a case-by-case logics here.

For the upgrade, OTA upgrade around every month, and it has always worked smoothly

This is usually not a good sign.

I'd prefer to have an OS provider that does one thing well.

https://eylenburg.github.io/android_comparison.htm is a fairly complete comparison. One of GrapheneOS' biggest features is that they sandbox Google services (if you choose to install them), whereas e/OS gives them privileged access by default (via microG). Calling it a "degoogled" OS while microG uses Google's proprietary blobs is... a choice.

The GrapheneOS developers are very sceptical of e/OS (https://xcancel.com/GrapheneOS/search?f=tweets&q=e/os), but you should obviously take biases into account here. Murena's CEO occasionally participates too: https://xcancel.com/gael_duval/search?f=tweets&q=grapheneos

(That said, yes, I don't quite trust their VPN or app store, since it's unclear who's running it - in the latter's case, I imagine that's also a legal matter.)

You can do this on any other android device using an app like Orbot or Tor VPN beta

But currently AOSP is very much open. That's also what the GrapheneOS devs say and why they want to continue using Android. Until it becomes clear that they will completely stop releasing the source code under a free software license i dont see why one should not use Android.

>it is impossible to maintain features that complex on a browser

While Chromium is complex, it is modularized which does make it possible for teams to maintain features.

Source?

I appreciate the vibes where this is coming from, but does it really? I think that assumes that everyone that works on this would work on a true open source OS otherwise, and that if they did, that would result in us breaking free from Android where we otherwise wouldn't. I'm not confident about either of those assumptions.

Meanwhile I'll keep complaining to orgs that don't allow me to work through their website, and tell them that their app won't work on my phone.

There are zero OSes that are 1/ open source 2/ appropriate for phones 3/ with good hardware support. There's absolutely nothing. Running Ubuntu Touch isn't a viable option. Neither is postmarket, librem, tizen, they're all terrible. Security wise, for something as critically important in our lives as a smartphone, I am also not trusting any new pet project that won't be stable for 10 years.

Sure, you might be a poweruser that doesn't care about your phone burning its battery in your pocket after 1 hour because you know how to SSH on it from your watch and put it in sleep, but that's not a viable option. Leaving Android is suicide. A large part of its critical underpinnings are already into the kernel anyways, just disabled. (although a distro running binder could be a fun project). APIs are reverse engineerable generally speaking, except for the server part of play services. But then, if your issue is "my bank won't let me access their app without play services attesting me", I have great news, you won't even have an app for it on your new OS anyways, so it will not work by default. There's already not enough people working on GrapheneOS _or_ on mainstream linux OSes, what makes you think the sitation won't be ten times worse for your custom made mobile OS ?

>We should focus our efforts on truly open platforms.

Android is one, and that can never be taken away. Google pulls the plug ? cool, you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community. Hell, for all the shit that Google is doing, they're still constrained by having to work with other vendors: the system privileged notification receiver is swappable at build time, the recent app signing/verification system also is, because Samsung wouldn't let them control it all.

8 of the 10 top smartphone manufacturers are Chinese, there's no going back from that.

To what?

Which is in my opinion a fairly reasonable take.

But given the current situation, I would assume that the companies providing WebUSB tools like installers would also spend a few moments to create e.g. a Python script that would do the same thing but locally. So that anyone unwilling to use WebUSB within their browser can have a vetted and transparent way to get the same thing done.

I know the versions differ by model, so perhaps your model was not as well supported.