Graphene is clearly bullish on Android, but I have no idea why. The writing is on the wall, Google is slowly asphyxiating AOSP.
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.
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.
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".
Of course there is. Sent from my daily driver Librem 5.
Disclaimer: It is less secure than GrapheneOS, according to the GrapheneOS threat model.
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
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.
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.
> We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
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.
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.
Anything can and will go down. Nothing is forever.
Windows still has the vast majority share of desktop.
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.
It's a completely different situation here.
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.
I would recommend it as tool for a Linux app designer to use with testing and user improvement. Helps find issue not present on a laptop or desktop. Highlights the difference in solution choices; Python vs Node.js vs Rust.
I'm getting away from Google as far and fast as possible. The sooner the bandaid is pulled the better and more freeing. Google's path with being able to reject those that they don't seem worthy to run on Android, that is a prison.
Personally, I should have root access to the device so that all content which must be archived can be or consumed with another tool; Category Theory. I should have direct access to copying or backing up SMS with ease. Watching the network traffic to know what is actually going through.
Security is also being able for one to learn about the actual operations and test and validate them.
So say you use a USB device to host the kernel boot image which then requires manual password authentication to decrypt physical device drives. Without the USB device, it boots into duress mode.
Duress mode provides a false shell into a working phone. Physical security system do this, by provide false statements of what is going on. Wipe the real stuff in the background if need be.
GraphneOS is using a Linux Kernel. I'm looking for something more Linux Distro style of implementation. Not choosing GraphneOS is pure objective to remove myself from Google and Apple as much as possible in a communication tool.
Android device has become phone and text only. Linux device has become my engagement. Going for a walk without primary communication is peaceful.
- No dependency on Google - Actually free and open OS (this means: root access to device, being able to customise any part of the distro/WM/DE, full, low-level access to external devices etc)
That duress pin idea is not good at all and would be bad for the users of GrapheneOS.
Not to want to give too much. Cell phone companies have no issue deactivating an account with a stated text message. Duress kernel can mimic it with other slight of hand displays that the _foot_ will accept as reality.
User lock down versus machine lock down moves to allowing the machine holes to be used for bypassing. User lock down allows for analyzing and patching the machine holes.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
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.
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.
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.
Obviously it isn't a direct substitute for Apple pay but it would be more functionality than we have now.
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.
I think in the short term, you should take a look at e.g. Cheogram, Conversations, and Element and consider ways to enhance integration. Address book integration, automatically extending contact do not disturb exceptions, and maybe even dialer integration.
In the long term, it would be best to try to guage antitrust regulator attitudes wrt to protocols like XMPP and Matrix. In the end, they are the only ones who can really force mass adoption of an open protocol. But alternative OSs having native support and integration for such messaging protocols can tip the scales and be used as evidence of the protocol's viability and legitimacy.
There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.
[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)