upvote
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
reply
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
reply
Waydroid can't run nearly as many Android apps as AOSP on bare metal or especially GrapheneOS with the compatibility features it provides. It's an approach with far more limited compatibility.

Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.

We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.

reply
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
reply
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
reply
Sure, but what could graphene do in the meantime? It's either make it work for the moment or stop those apps from working today.

I'd like to see them lay more ground work for web apps but it's a tough spot and the easiest choice at the moment is to continue with AOSP.

reply
I don't want to see more groundwork for web apps. GrapheneOS is meant to be secure, which means running trusted apps on-device. My messages are less secure if they permanently are stored on a server.
reply
I mean we privacy nerds all love webapps but the reality is the people actually in charge of S&P500 companies hate them. They really, REALLY want to fingerprint your device and use it as a verification and tracking mechanism.

Until that changes, webapps aren't going to sell.

Even Google tried multiple things to "sell" the idea of webapps (e.g. Polymer project) in 2011-2015 and failed.

Funny enough, Wechat kinda succeeded at webapps in China because there's a strong user preference to stay inside one monolithic "everything app".

reply
I find, as a user primarily of free and open source software, it’s really the opposite: native FOSS apps have minimal tracking and analytics that defaults to off or is easily disabled, while most free and open source webapps are behind Cloudflare, blocking access to them until I turn off my VPN and disable the anti‐fingerprinting features in my browser.
reply
It's not ideal, but in the case a hard fork happens, they could implement the same APIs and most apps will probably continue to work. Similar to how microG is a replacement for Play Services and still works for most apps (not as well as sandboxed Google Play of course).

Above that, not much would change for a few years anyway, because apps still target ancient Android versions.

reply
Yes, but there is no alternative other than giving up. Starting a new OS from scratch with zero apps is a much worse starting point compared to a platform where 99.9% of apps work (minus those relying on Play Integrity with strong integrity) which may have its rug pulled in the future. The race here is about getting to a big enough market share that GrapheneOS cannot just be ignored as completely niche but has to be treated as a small but not insignificant minority.
reply
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.

Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.

I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.

Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.

And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.

reply
I think graphene could maintain a hard fork with manufacturer support (Motorola). At least for a while. Long term viability is an open question.
reply
They could for a while but what's the point if it's not sustainable? Google is not going to turn around and make it more open again.

With every Android release you will build up more feature base to replicate. Unless you cut all ties and drive a separate ecosystem but good luck getting enough developers to buy into that.

reply
Well, someone is clearly giving Graphene money, and quite a lot of it, as per TFA:

> We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.

reply
And the US might grow a government with a spine and take Android away from Google. It's all hypothetical.
reply
[flagged]
reply
We've collaborated with many Google engineers working on Android. Many of their engineers, security researchers and even people in management positions follow us on social media. One person who describes themselves as an AOSP engineer on Hacker News doesn't reflect what their overall engineering team thinks about GrapheneOS. This person likely also finds the security engineers at Google complaining about the same things and pushing for improvements annoying too.
reply
They basically have opposite goals to Google so I don't imagine there will every be good feelings there. There shouldn't be.

Yes Google wants android to be secure, but the problem is that to be truly secure it should be secure from Google too. And they don't want that. They want it to be their personal datamine and walled garden. Just like Apple with ios.

reply
One AOSP engineer.

Google is the one making bad actions, which it makes sense to complain about. They moved to building in private so forks don't get features as they come and more recently they stopped providing certain source code in a timely manner.

reply
deleted
reply
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
reply
There is no alternative.

Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.

reply
Remember when we thought IE's monopoly could never be broken? Or windows?

Anything can and will go down. Nothing is forever.

reply
IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long.

Windows still has the vast majority share of desktop.

reply
Chrome is the outlier there. It didn't come with any desktop OS and still got near 100% market share, even before Android contributed to that. How? It's worth studying.
reply
The made the best browser on the planet in Google's Bell Labs era and then they used it as leverage during their "do evil" era.
reply
Well, the web was already designed to be compatible with multiple browsers, so that's one element there.
reply
Yes but that's my point. Monopolies don't last. We have other ones now yes. But that's because the earlier ones died.

And yes we still have windows as the major desktop OS but don't forget, in the 90s/early 2000s windows was equivalent to computing.

These days the desktop OS is much less relevant than it was and many people don't even own a laptop or desktop anymore. They just do everything on their phone. And Microsoft totally and completely lost that race.

reply
> There is no alternative.

There have been several projects like Ubuntu Touch to create an open Linux for smartphones.

That would be an open alternative.

Android is not open.

reply
Android is an open source Linux distribution for smartphones. It doesn't have to be used with Google Mobile Services. AOSP is far more private, secure, usable and compatible with a far broader amount of apps. Why wouldn't we use that as the starting point even if the goal was to diverge?
reply
The AOSP is fully open source. What you suggest is a significant step back in terms of privacy and security.
reply
The AOSP does not run modern Android apps, since Google has been replacing the APIs those apps require with closed source versions (that only ship as part of Google Play) for over a decade.
reply
No, that's a widespread misconception. Google Play services is nearly entirely APIs for using Google services. It hasn't replaced AOSP functionality and the AOSP APIs are still there. If you want to avoid Google services then there isn't much that's useful in Play services. Getting developers to not depend as much on Google services such as supporting UnifiedPush in addition to Firebase Cloud Messaging leads to those apps no longer requiring Play services for that functionality.
reply
That is not true. AOSP can run all modern android apps, and google play APIs are provided as alternatives, but not replacements, for AOSP functionality.
reply
deleted
reply
[flagged]
reply
That's a huge downgrade for privacy, security, usability, battery life and compatibility with apps. GrapheneOS is Linux too. Linux doesn't mean glibc and systemd. Linux is unfortunately not a great base for an OS focused on privacy and security but it's the only practical choice at this time. In the long term, it needs to be replaced as the bare metal kernel.
reply
I have it. It's far too slow to be useful, and it's not the hardware's fault. GTK and Libhybris are bad separately and hot garbage together. This problem won't be going away while the hardware is relevant.
reply
Which model of phone from FuriLabs?
reply
Yes RCS is barely a standard worth implementing, let alone the best one. Make SMS/MMS and XMPP work together seamlessly in one app, forget RCS.
reply
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.

It was always meant to be a walled garden. Exactly what an open system shouldn't be.

reply
RCS is important because it provides end-to-end encryption (E2EE) for contacts with Google Messages and iOS. That means having E2EE for the vast majority of smartphone users since Google Messages is the standard GMS Android carrier-based messaging app.

https://news.ycombinator.com/item?id=49593026

reply
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.

People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.

reply
It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide.

I disagree with this somewhat. Apple and Google make these sweeping decisions for their users and in effect promote one tech over another. Adopting RCS and integrating it natively, but shunning open protocols and leaving them for third party apps (with probably worse OS integration) means you are following, not leading.

I would at least consider shifting approaches somewhere down the line. Yes, there are a plethora of open messaging protocols out there, but adopting one for first party integration doesn't prevent the others from being used.

reply
RCS is a modern replacement for SMS/MMS with end-to-end encryption (E2EE) support via MLS. We have SMS/MMS so we need RCS to replace those. Similarly, carrier-based calls are there and should get replaced with a newer standard with E2EE.

RCS is what GMS Android and iOS provide so that's what people need to talk to non-GrapheneOS users.

Which non-carrier-based messaging app or protocol do you think we should include and why? What happens if we decide that's no longer the best one wand want to get rid of it? Apps included in the OS cannot be easily removed but rather only disabled by default for new installs and phased out for new devices. Otherwise, users would have their working setup break.

reply
I agree. The OS maker has a ton of power with the default apps and putting SMS and phone calls as the default communication platform of the OS is contrary to the goals of giving people more privacy.

And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.

reply
> And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.

This makes no sense especially when you’re comparing it against Apple Pay and Google Wallet. They shouldn’t waste resources on something so pointless. The only exception is if they can actually make an NFC capable app that can handle cards.

reply
A FOSS, private, uncensorable way to pay people instantly anywhere with effectively zero fees is not pointless.

Obviously it isn't a direct substitute for Apple pay but it would be more functionality than we have now.

reply
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
reply
Remember Pidgin and Trillium?
reply
I use cheogram daily.
reply
I remember who forced me to consider other options.
reply
A scratch built mobile operating system have zero chances unless it would be straight up adopted by a cellular carrier, or at least blessed by one.

There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.

1: https://en.wikipedia.org/wiki/Mobile_operating_system

reply
They may as well get ready for an eventual hard fork, then?
reply
Have you used GrapheneOS? It's fantastic UX[1] and while probably being one of if not the most secure and private OS available.

[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)

reply
> Graphene is clearly bullish on Android, but I have no idea why.

Their resources are historically better spent hardening vs literally reinventing the wheel.

Multiple variables in that equation have changed - so it could be interesting where we end up.

Someone (else!) may yet arise chasing their stated model without Android, as well.

reply
Perhaps they're hoping to get significant market share before they lose the opportunity for good?
reply