I really appreciate having a non-Google Android OS, free of Play services and other lock-in, and use Graphene on my own Pixel. The focus on security and hardening is also appreciated, but I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience. As-is it feels like a barebones AOSP with all the security improvements existing as a sort of hypothetical improvement in the background.
Why is this the most top voted comment? Do a lot of people really feel this way? Honestly, I feel it's ridiculous to expect this from Graphene OS. It's a privacy focused OS. If you want shiny features there is iOS.
If anything, it would be detrimental to their mission. Asking them to improve android in every way is the lawyers equivalent of ddos'ing an adversary with paperwork
It's a good idea, if not for Graphene. Graphene could be the Debian of mobile OSs, they keep doing what they do best, stay aligned with their goals, and others could use it as a base and add dancing hamsters to the bootloader.
They are already stretched a bit in terms of doing what they are comfortable and best at which is implementing privacy and security enhancements in AOSP and maintaining them across AOSP changes and upgrades (or getting them upstreamed if palatable to Google/AOSP).
They have made major usability improvements like eSIM support and network-based location. They have also been forced to work on things due to unrelenting popular demand like Android Auto support, sandboxed-google-play and the compatibility layer and Google Messages & RCS support.. to the cost of working on other security/privacy enhancements. At the end of the day, this is more a question of resources available.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world.
> I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world
I agree completely. I don't expect one small team to carry the weight of building an ideal OS. I'm just disappointed that while there's loads of work being done spinning up interesting desktop OSes with new paradigms for UX and system management, the same can't be said of the mobile space. Everything there is basically some slight variation on iOS.
It would be a complete waste of time for devs to focus on making the AOSP apps pretty. I don't really get the hate, AOSP apps are completely fine and it's not like you have to look at it all the time
AOSP apps look and work terrible in my opinion. The music player hasn't changed since what, Android 2?
There's a reason ROMs like LineageOS develop their own alternatives. Most ROMs seem to use those open source alternatives rather than the apps Google abandoned with AOSP.
I was talking about the AOSP apps GOS ships, which is handful and doesn't include a music player. Apart from maybe the gallery app, I don't see any other as completely unusable. They already maintain Camera, PDF viewer, Vanadium, App store and Auditor
Each of the AOSP apps still present in GrapheneOS going to be replaced or overhauled. They're only there as basic bundled functionality. There's no point in improving some of those apps because there are either better open source apps to use as a starting point or we can make our own instead. It would be nice to have modern Compose apps instead of a slightly improved legacy code with modern features bolted onto it.
I'm not sure what you mean. They do have a secret key used for hardware attestation, but to my knowledge it's not supported anywhere and your own build would pass attestation just as well. For apps outside the core you wouldn't even have to do that much - just fork them and install your own.
> I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience.
i agree with the sentiment, but not for the features part. just getting the core functionality working across devices (securely of course) is already a lot of tedious work. just look at the dearth of supported devices that do not run a specific soc or from a famous brand.
for vast majority of features, one can personalize themselves by getting apps. most don't need rooting or any technical know-how. it will be unproductive to spend time ricing the os for users when they got their own personal preferences regardless. which is why it is fine to focus on getting the core things right first.
What does Android need "in terms of usability, features, and overall experience"? I personally don't feel that anything is missing. I'd love a denser battery maybe.
I'd like to see some experimentation with core system UI, like the notification/quick settings thing. I'm not convinced the weird double-pull-down hybrid thing Android uses is a good design. I'd love to see some experimentation on a multitasking system that isn't clunky and inconsistent. Some of the tweaks Samsung puts in their Android spin could be nice. I'm not expecting a security-focused team to work on this stuff, but it's too bad that nobody is. I feel like we've settled on a pretty lousy core mobile operating system paradigm, and just generally wish people were experimenting and iterating on a variety of ideas.
I watched my partner adjust the volume on her android phone (some Motorola phone) and first there was the vertical slider, she tapped it, and it expanded to idk 5-6 different volume sliders? I appreciate having the option, and I feel like that’s a lot to shove into the UI for a mobile device.
I prefer the iOS model, though it’s not without its own issues. For iOS, if no media is playing, the volume buttons control the ringer/notification volume. If there’s music or a video actively playing, the controls adjust the playback volume. Honestly, my biggest gripe is not being able to easily set ringer volume while something is playing - I just did a quick test with Spotify open, and going to the settings app and adjusting the ringer stopped playback for the ringer sample to play.
I see what you mean, but GrapheneOS has completely different goals. Simply put, Graphene strives to be a secure, degoogled Android. Other than that, it has the same goal as the Pixel phones: to be as close to mainline Android as possible.
While this is awesome, I'm kinda skeptical on the premise on two points.
Almost nobody cares about privacy, and this is going to be super expensive. I might be fine with paying extra, but the economy might not work out, like it didn't for Blackphone. Fairphone is barely alive as well. Seeing as phones are just source of ad money Google can drop the prices on their phones as well.
Some European countries and banks already require crap like Play Integrity for essential apps. So far it's possible to hold out, but for how much longer?
GrapheneOS user here. Every single banking and financial app I use works. Both European ones and non-European. Some require changing per-app settings, but nothing crazy. There's a good chance that your banking app will work.
We're working with a major Android OEM on the future generations of their existing devices meeting the official GrapheneOS requirements so we can officially support their devices. People will be able to buy the regular devices and install GrapheneOS at no extra cost. We're talking about selling devices with GrapheneOS preinstalled but that's not a requirement for the partnership to be a success and other companies could still do it as they do now with Pixels.
Play Integrity API doesn't impact GrapheneOS as much as other alternatives not focused on privacy and security in a similar way. A subset of the apps using the Play Integrity API are explicitly permitting GrapheneOS via hardware attestation including multiple banks like Swissquote. We're working on convincing more banks to permit it. Our hope is for regulators to invalidate the current approach and require defining clear security standards which need to be fairly enforced. The status quo of some banks banning using a much more secure OS that's even much more heavily using hardware-based security features while permitting a Google Mobile Services OS with no patches for 6 years is a massive antitrust issue. It impacts every alternative hardware platform and OS since Android app compatibility is important for competing. The obstacles to getting approved should also not be unreasonably high. It's better if apps don't do this but we can accept they are going to do it if it's a fair system permitting competition, unlike the Play Integrity API.
You don't have to carry two phones. The idea is that the second phone stays home powered off and is used as an access token for the bank's website. There is no reason to carry it around. Pay cash in stores or use a credit card when cash is inconvenient.
I think this is a pretty outdated view of banking. I open a banking app at least a few times a day. In the EU just about every online transaction has to be approved in the app, we also use various payment apps for quick person to person transfers, use the app to generate disposable virtual cards for online purchases, etc.
I could cut myself off from the modern financial world and just use online banking like it's 2010 but that's a pretty big ask.
The US is way, way behind in banking P2P technology / fintech adoption. In many parts of Asia, even uneducated street vendors now accept digital payments via mobile phones (that's how easy it is). See - https://www.forbes.com/sites/pennylee/2024/04/17/the-us-lags... and
I would rather not have the kind of "financial innovation" that requires non-free apps running on non-free operating systems on locked down hardware. These apps, by design, track how people spend their money.
Traditional banks have about as much data about how you spend your money as any modern fintech. The banking system is non-free, locked down and centralized to begin with. How you access it is just a matter of cosmetics and policies.
> These apps, by design, track how people spend their money.
That depends - In India, for example, I am free to use either (1) a private company's app (like PayTM, Google Pay, PaisePe etc.) (2) a Government app or (3) my Bank's app to make digital payment using the Unified Payment Interface (UPI) (or all 3). And, if I don't want to use any mobile app, I can still make offline payment through my mobile phone over USSD - https://razorpay.com/blog/how-to-make-offline-upi-payments/ ...
(You are right though that it is prone to abuse in the absence of strong privacy and data protection laws - digital payment does allow new form of surveillance capitalism to the corporates and new avenues of authoritarian control to the government).
Barclays in the UK offer (or used to) a hardware device with a keypad allowing the user to do a challenge-response using the bank card's chip and PIN. Not sure if they still do, though.
What if one doesn't own an android/iphone device? Banking is a fundamental need, so most countries regulate them to cater to a wide range of users. In this case it's possible that the bank could be compelled to provide you a 2FA device if you don't have one.
I don't think there is such regulation. Many banks simply do not have any other means of authentication any more. They can't give out 2FA devices because their systems just don't support them.
That's because they're stupid or doing something suspicious, probably both.
There's legitimately zero reason to allow 2FA only on your own propreitary app. You can't even make a financial argument - allowing other TOTP methods is cheaper because now you don't need an app!
> Article 7 Requirements of the elements categorised as possession
> 1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.
> 2. The use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.
No, because phones that lock keys in hardware effectively prevent that, and that works only with hardware that prevents its owners from having full control an doing what they want with their hardware.
"Unextractable keys" works with hardware that you don't "truly own".
What if you truly want the security properties provided by a device which can keep keys in a way where you fully control their use but its extremely hard for anyone to extract them?
it costs basically nothing to change banks. you sign up to a new one and they transfer your account and direct debits. you just tell your employer where to send your next salary payment.
Sorry, not available where I live and not the bank I can use for what I need. I won't give personal details but my options were limited for multiple reasons.
Maybe the real focus should be treating Android as a single purpose environment rather than your real/life depending one.
Maybe the better approach would be focusing on getting postmarketOS to work, and use an emulation or recompilation layer that is running Android in a box (pun intended). Anbox and others were still too painful to use for daily usage, but maybe you can get rid of everything except the things that Play Integrity checks against? Maybe we can make waydroid work?
Waydroid is not a private or secure way to run Android apps. It uses an old fork of LineageOS and throws away most of the privacy and security model with how it's implemented. It does that to run Android apps on top of a much less private and secure base OS. Compatibility is far worse and it in no way avoids the Play Integrity API checks. Most banking apps do permit GrapheneOS and some of the apps banning using a non-stock OS or non-GMS devices with the Play Integrity API have explicitly permitted GrapheneOS via hardware attestation including Swissquote. Banks have no reason to ban GrapheneOS since it has all of the standard privacy and security model combined with major privacy and security improvements. They're often willing to permit it once they understand what it is and how they can verify it with a standard Android API. Convincing every app using Play Integrity to do this case-by-case is painful and unrealistic, but regulation can require permitting secure alternatives meeting defined security requirements.
why not the other way around? aosp already has a much better security posture, already runs almost everything virtualised, and will soon run 'desktop linux' apps in a vm
in fact statements from graphene suggest they hope to eventually move away from linux on the host
it won't be a special graphene phone, they are working with the OEM to make their next flagship meet graphene's security requirements; it'll just be another phone they support that isn't a pixel
I had my previous cheapo Chinese phone for 7 years. Only bought new one this year because the battery was gone and the display had some scratches. The photos are a little nicer I guess?
/e/ has extraordinarily poor privacy and security. It's largely the opposite of GrapheneOS. It's hardly focused on privacy and security. See the information available at https://discuss.grapheneos.org/d/24134-devices-lacking-stand... including the information that's linked from third party privacy and security researchers.
/e/ always uses multiple Google services and builds in privileged support for Google apps and services so the branding as a degoogled OS doesn't really make sense. GrapheneOS doesn't brand itself that way but doesn't make connections to Google servers by default and doesn't provide privileged access to Google apps and services.
It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand.... It lags extremely far behind on kernel, driver and firmware patches even when they're available. It lags far behind on AOSP and browser patches too. As an example, /e/ on the Pixel 7 is still on Android 13 with multiple years of missing High and Critical severity kernel, firmware and driver patches since they didn't backport it to Android 13 while the Pixel 7 is on Android 16.
No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
You're responding to verifiable technical information by linking to harassment content based on fabricated stories.
The company you've linked was scamming people who wanted GrapheneOS phones by selling them end-of-life devices no longer supported by it and devices near end-of-life while pretending they were perfectly fine and would last years. They were misleading people about what they were getting and violating our trademark. Despite profiting from selling devices with GrapheneOS, they were also actively misleading people about it with many inaccurate claims. Their response to us politely bringing it up was blocking our project account and attacking us. When we warned our community, they responded by joining in with spreading fabricated stories about our team aimed at directing harassment towards us. The videos linked in the article are harassment content filled with fabrications and misrepresentations. The initial video is from someone responsible for encouraging repeated swatting attacks towards our team and the 2nd is from someone who openly uses Kiwi Farms which they directly personally involved to target us.
/e/ leadership spent years trying to mislead people about GrapheneOS including highly inaccurate claims about privacy and usability. We began debunking this and posting accurate technical criticisms of /e/. Despite spending years attacking us with little to no response from us, /e/ has responded to us informing people about it by joining the harassment you've tried to promote. Their CEO / founder has directly participated in it. It's a very typical pattern from /e/ and their community for the response to accurate technical information to be fabricated stories aimed at targeting us with harassment.
Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.
Because the technicalities of accomplishing something like that are quite complicated from what I understand. If an app has the necessary permissions and network access, almost anything you try to stop it from transmitting data about the platform and data about its usage is futile.
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
The approach used by /e/ doesn't actually work and enables fingerprinting VPN users. It only stops the least invasive tracking for client side analytics, etc. where there are single purpose domains which can be blocked. Multi-purpose domains used for both privacy invasive things and functionality don't get blocked. The app's own servers used for the most privacy invasive behaviors in practice of course don't get blocked. They can share whatever they want with arbitrary third parties through those. However, it won't get blocked client side by /e/ if it's needed for any functionality so third party services which are privacy invasive won't be blocked unless the app doesn't need them, doesn't do it server side and doesn't do basic evasion of filtering deployed in many apps by resolving DNS queries themselves or having IP fallbacks like Facebook.
Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.
Global Mock Location is a standard Android feature not specific to /e/. GrapheneOS also supports it, and is building a better replacement for it similar to our Contact Scopes and Storage Scopes features providing otherwise missing functionality in Android that's partly available in iOS. /e/ doesn't have either of those things or other privacy features such as the Sensors toggle.
/e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
