You don't need a sim card to make accounts for a phone in the first place. Not sure how, but on android devices they let you make an account without giving them a phone number. Probably because even Google realizes how bad gating application installs on new phones on having a phone number would look.
The problem is that even if you have separate google accounts on each android device, Google can still track you by looking at your contacts.
AuroraStore uses a pool of burner Google Play Store accounts to facilitate anonymous downloads. This is what happens when those burner accounts get flagged.
I'm using my Proton account in my phone and in play store. now i tried adding my proton account in AuroraStore, and it worked flawlessly. so my question: why AuroraStore uses google accounts instead of another providers?
what happened? if you're trying to say that this is "impossible", its not. But if you're trying to say about privacy, that account I tried is another one of mine. im not stupid to use my primary proton account in my phone.
They suggest PlayStore if you need to get apps that are only available on the Play Store. They do not recommend it above other options, and have mentioned that they very much disapprove of Play App Signing being mandatory.
For people using sandboxed Google Play, we strongly recommend using the sandboxed Play Store as the primary way of obtaining apps from the Play Store. We don't recommend using the Play Store as a first choice for obtaining apps.
We don't recommend the Play Store as a source of apps in general. For obtaining apps from the Play Store, we primarily recommend using our sandboxed Play Store feature. Aurora Store is mainly useful for working around Play Integrity API store listing restrictions.
Aurora Store can be used without the shared account feature. The shared account feature was on track to getting blocked for years and we've warned about it. Sharing accounts is against the Google terms of use and they've been ramping up their detection and banning of it. It's somewhat strange they allowed it to go on for so long. Aurora Store does still work as an alternate Play Store frontend since Google hasn't blocked that.
Due to Aurora Store bypassing the Play Integrity API store listing restrictions, they may decide to take steps to hinder it. It's a very easily bypassed way of using the Play Integrity API but it harms alternative operating systems.
Sailfish OS user on Jolla Phone 2: Aurora is working fine here.
P.S. Sailfish OS is NOT an Android distribution. It is a proper Linux system and they have their own custom Android runtime (AppSupport) as a layer on top for running Android apps. This runtime _is_ Android under the hood, but is separate from Sailfish itself (has its own native app ecosystem).
Linux doesn't mean using glibc and systemd. Unlike the Android Open Source Project, SailfishOS has a largely closed source user interface and application layer.
GrapheneOS doesn't recommend Aurora Store for apps obtainable via sandboxed Play Store. We mention it as a workaround for apps setting their Play Store listings as requiring the Play Integrity device and strong integrity levels.
Aurora Store works without the default enabled account sharing feature. The account sharing feature is disallowed by Google's terms of use banning account sharing.
I feel the title editorializes a bit too much. The thread only confirms the bug, not a specific cause yet. As sibling comments indicate, the effect on GrapheneOS users is undetermined.
This is standart, and happens constantly with Invidious (youtube frontend). This happened before on AuroraOSS too. They probably just flagged the accounts and no API change or A/B testing an API change.
If anything, it seems more poised to damage the usability of systems which actively rely on Aurora Store, like CalyxOS and the likes. Graphene actively discourages using Aurora.
Yeah, this seems to have nothing to do with GrapheneOS. There's some account used by default when you don't use your own in Aurora, and Google has started seeing too much traffic to the Play Store APIs from it. I'm surprised it took this long tbh. The server busy errors are transient and go away after a while, but if the load persists, they'll come back.
Although the nice thing about Aurora Store is it allows you to install apps without a google account linked to your device, keeping Google Play Services signed-out.
Somewhere in the FAQ GOS advertises that Play Services can be used without signing in, but they also recommend the official Play Store (which requires signing in) and explicitly don't recommend Aurora (which doesn't).
Unless I'm missing something, I don't see how you can functionally use Play Services signed-out when in order to obtain those apps in the first place, you need to sign into a Google Account for Google Play.
That's personally what I used Aurora for, plus as an easy way to export APK files.
Some apps offer direct APK downloads from their websites. If Google Play Services is detected, they use it for push notifications. Otherwise, they fall back to an internal background connection. WhatsApp is an example.
You still need to supply Play Services:
GrapheneOS uses Sandboxed Google Play. LineageOS requires flashing a package like MindTheGapps. There is also microG, an open-source reimplementation of Play Services APIs.
> You can also just get a burner phone number for a few bucks.
But you have to keep paying the monthly cost, if you loose access to a phone number in your Google account it's game over for any account recovery or "let's verify it's you" it might decide to throw your way.
> > a Google Account that isn't tied to anything else.
> Isn't that pretty much impossible? You need a phone number for verification, which effectively ties it to that phone number.
I just want to follow-up on this because some people claim this is not correct because they have managed to create accounts without phone numbers.
Indeed, I think to this day, under special circumstances (like e.g. on reasonably recent Android devices) you might be able to setup a Google account without phone number.
The trick is, that in the general case, you can not keep this account online indefinitely.
First thing to note: This way of account creation does not seem to work anymore.
Second thing to note: After once logging in from a different country, trying to login again REQUIRES me to provide a phone number after successfully giving username/password/2FA code. No way to use the recovery code instead...
Also, given that this account was never before connected to a phone of any kind, by definition, the addition of a phone number cannot provide additional security confirmation (it's data that simply wasn't present before and any "personal" phone number could potentially do -- of course I haven't tried, because that's the point of not linking a phone number).
I think this way it is finally proven that they only do this to harvest the data/phone numbers and any claim of enhanced security is void.
I write this after having lost the second account to the phone number required screen despite being in possession of all the credentials which were ever assigned to that account...
It's the SomethingAwful model: go to the store and find the cheapest Android phone from some prepaid company for :tenbux: then use it to set up your Google account during out-of-box-setup while on the store's free public WiFi (since Google OOBE allows free account creation without a number or existing email), then toss the phone in a drawer afterwards.
"Hope ya got ten bucks!"
(I got a random 5G Moto phone for ~$10 on clearance and it was an absolute shitter of a phone full of garbage packed in malware, but after cleaning and debloating as much as I can, it's at least a nifty toy to poke at Termux or something.)
> Google Account that isn't tied to anything else.
At the risk of being a privacy absolutist / fatalist: Google’s entire business model is surveillance. They follow you around and track your habits so you can be influenced. Given that, a Google account is always tied to something else.
Piggybacking on this... I create my fair share of "burner accounts" and almost always they (not just Google) connect it to my true identity. Granted I'm not using VPNs or really trying to hide the connection but it seems trivial for them to associate.
They have required unique phone numbers for accounts I've tried lately, or parent's phone numbers. Facebook is worse though, they are quick to ban an account/phone number.
I'm under no illusion that google doesn't know I own my multiple accounts. They most certainly do. I usually use the same user agent (with containers) on the same IP, after all.
But my goal is to avoid a stranger gaining access to my google services if they manage to unlock a lost device or steal my TV/streaming box that has no lock at all.
I wish Google supported a permission system per device. For example on most of my android devices all I really want is to be logged into Youtube and the play store. I most certainly do not want those devices to have access to my contacts, emails, calendar, keep, drive, payment, etc. (I don't personally use all of those things, but you might and that's what a random thief would gain access to.)
Google's business model is providing you services that are excellent, while also providing advertisers access to your willing eyeballs when you use those services.
Yes, the advertising targeting is incredibly invasive, but let's not pretend they aren't providing world class Search, Email, Docs, Maps, Video (YT), etc in exchange.
GrapheneOS is focused on privacy but that must come from a secure baseline.
GrapheneOS is much more privacy focussd than any other mobile operating system. Accrescent is the end goal for a secure and private app store but it's still in alpha. GrapheneOS is also the best for degoogling (eliminating all google services) because it comes with zero Google services unlike all the other ones listed here: https://eylenburg.github.io/android_comparison.htm
How can you call other OSes more privacy focused when they haven't closed as many VPN leaks as GrapheneOS? That's like bare minimum for privacy.
> Which is very much contrary to software freedom.
Yeah, the goal is privacy although the OS is completely open source.
They do improve user experience by allowing disabling emergency alerts, call recording without alerts, no mandatory camera noise in Japan, no extra warning popup from installing APKs from the web (it's the same permission in every app store iirc), increases password length to 128 digits. All the network services are open source afaict while all the other mobile operating systems listed in that android comparison connect to Google's closed source services, netowrk permission, sensors permission, storage scopes, contact scopes.
You can still easily install whatever Android app you want on GrapheneOS and you can install dangerous apps like shizuku and apps with way too many permissions. But yeah the goal is privacy so that everyday people can protect themselves as well as journalists can protect themselves. I want journalists to get the best privacy possible without having to know a ton of technical things or making many choices.
Verified boot does indeed make this more complicated, but it's totally possible to build Graphene with your own signing key and get full control over the OS that way (i.e. https://github.com/schnatterer/rooted-graphene).
Looking at their public statements on the matter, it seems like the problem isn't exactly that they treat the user as a potentially hostile actor so much as that they treat the system UI and persistent storage as a potentially hostile actor (though I admit from a practical perspective that's nearly the same thing): https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
I believe you misunderstand what "software freedom" means. You can compile and install GrapheneOS yourself, and you can grant yourself admin access. This is software freedom.
Software freedom does not mean that you should run everything as an admin, always. And just in case: software freedom does NOT mean that you should remove your firewall and let everybody SSH into your server by having a blank password.
You can't grant yourself admin access with the official build. Only the Graphene devs have the ability to push changes to the OS on your phone. Yes you can fork the software and build a version with your own signing key, then wipe your phone and install your custom build and thereby take back control, but then is that really still Graphene?
I think it's fair to say that that's at least borderline anti software freedom, even if it's true they have good security reasons for doing things that way.
Thinking about possible ways they could retain the same security properties without impinging software freedom... maybe there's a way they could make the root of trust default to a signing key embedded in the device's own secure hardware? Then by default that key could sign Graphene's own signing certificate to allow them to push updates, but the user would retain the ability to revoke that signature and sign someone else's certificate instead (or their own certificate) if they decided they didn't trust Graphene anymore, or wanted to give themselves root.
I am confused, why were your messages flagged? I disagreed with you, but I didn't see a reason to flag them? Also I don't know how to flag a message, but that's another topic.
It's not flagged now. But yes, way too many people use flags as an "I disagree" button these days. I feel like that used to be very rare (even down-votes aren't supposed to be used that way) and is becoming more common, though maybe it's just because previously I wasn't on HN long enough to notice the pattern.
> I think it's fair to say that that's at least borderline anti software freedom
Then you don't understand software freedom either.
Software freedom doesn't mean AT ALL that random projects on the Internet MUST implement the features YOU want. Never, not at all, it's not borderline, it's not up to debate.
Software freedom is about being able to use the software the way you want, as in "you get access to the sources, you modify them, build them and run them". You can do that with GrapheneOS (well except for the binary blobs situation, but that's not in GrapheneOS' hands at all). Software freedom is NOT about GrapheneOS giving you root access on official builds because you want it. And it's also NOT about GrapheneOS installing Doom on the official builds because I want it.
> Software freedom is about being able to use the software the way you want
You can't use the software in the way you want if it uses hardware backed cryptography to block you from doing so.
> you get access to the sources, you modify them, build them and run them
This is completely untrue for 99% of the population. If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
You could argue "but someone else could modify it for you, build it, and make an easy way for you to install it", and normally I'd accept that, but given that installing that modified version would require you to completely reset your phone and install the new modified OS from scratch, I think it's debatable at that point whether Graphene itself is the source of that freedom, rather than the fork. Like I said, borderline.
> You can't use the software in the way you want if it uses hardware backed cryptography to block you from doing so.
You can use the software the way you want, from sources. If I run an open source server at home, it does not give you the right to enter my house and come reboot my server, does it?
> This is completely infeasible for 99% of the population
Sure, it isn't. Still that's what software freedom is.
> If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
I disagree, I'm very happy that free software exists.
> I think it's debatable at that point whether you'd still be running Graphene
It's not: you're running a fork at that point. That's precisely how free software works.
> And if exercising your freedom requires you to stop running Graphene and start running something else, is it really fair to say Graphene itself supports that freedom?
Yes! Again that's precisely what software freedom is about! When you run GrapheneOS, you have the freedom to fork it and run it however you want. When you run Windows or macOS, you don't.
> If you're still not convinced, consider what would happen if companies started using remote attestation to verify you're running the official GrapheneOS build and block forks...
Well GrapheneOS would still be free software?!?!? It's the software from those companies that wouldn't be. I hate remote attestation as much as the next person, and typically banks absolutely suck because they love doing that kind of bullshit. But because banks suck does not mean that GrapheneOS is not free software?
Note that I am not trying to contradict you for the sake of it. I believe too few people understand how open source works, and that is a pity because it is important to understand it. When I open source some code I wrote, I make it available for people to do whatever they want with the code. I don't give them ANY RIGHT on the products I sell (even if those products are running said open source software) or on the feature I implement.
Too many people believe that because it's open source, they have a right to tell the authors what features they should implement. This is wrong. You want root access on your GrapheneOS? Go fork it. I don't want it, I am happy with GrapheneOS. If GrapheneOS gave me root access, I would fork it to remove it. And that would still be free software!
> Well GrapheneOS would still be free software?!?!? It's the software from those companies that wouldn't be.
I think I have a broader definition of software freedom than you do. In this hypothetical scenario, GrapheneOS itself may technically be "free software" in the sense that the source code is open, but it would still be cooperating in a intentional scheme to prevent you, the user, from modifying it to work the way you want. Same deal if they started selling locked hardware with their signing key hard coded so you can't install a fork. You would legally have the ability to fork the software, but technical measures would be preventing you from running it.
Granted, they're not doing that, but it's one short step away. That's why I say it's borderline anti-freedom, not that it actually is.
I don't think it makes a difference whether the means employed to make a piece of software non-free are legal (copyright law) or technical (DRM, remote attestation, hardware locks). It's still restricting your freedom.
I really want to insist on this: when someone develops software, you don't get to choose what they develop. That's just life.
If they make their software open source, you get to fork it (sometimes contribute to it) and this is already very generous. But that's all.
I say that as an open source author and maintainer, and my experience is that the vast majority of developers do NOT understand that. I have been criticised, insulted, sometimes bullied by people who wanted me to implement whatever they wanted ON TOP of providing my work for free.
You can have your own definition of "free software" that means "the developers have to agree with my personal taste", and say that "Linux is borderline not free software because I want them to officially support Zig and they don't", but it doesn't bring much. What makes Linux free software is that you can fork it.
I guess I don't understand the need to have a definition that only serves for complaining about a free project not implementing a feature you want. I get it, you wish GrapheneOS gave you root access. But it is not the choice of the people who do the work and make it available for free. But because it is free software, you can fork it and modify it yourself, and this is great.
For what it's worth this isn't just "my personal taste". I think Richard Stallman and the Free Software Foundation, at least, would agree with my definition[1]:
> Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense rather than a practical reality. These binaries are not free software even if the source code they are compiled from is free.
I didn't say anything about what GrapheneOS devs must do. They don't have to do anything. I just think that some of what they are doing comes close to impinging on user freedom (though it doesn't quite cross that line, in my opinion).
I'm asking for them to not block you from modifying the software on your phone. I've said multiple times now I agree they're not currently doing that, but they're one short step away.
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known [...] in its practitioners' perverse terminology as “secure boot”—freedom 1 becomes an empty pretense
GrapheneOS implements secure boot, using a key you do not control. If you install GrapheneOS, the Graphene devs have the ability to push updates to the code running on your phone but you yourself do not unless you completely uninstall GrapheneOS and wipe all data on the phone.
Again you don't understand Stallman's quote. Let me try:
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense
Tivoisation or lockdown or abusively calling it "secure boot" is, according to Stallman, "non free". GrapheneOS does not do that. GrapheneOS does not even own the hardware that could do tivoisation. GrapheneOS is the fork of the original project that has been updated and installed on the original device. That means that not only GrapheneOS is free, but AOSP as well!
> is that if you choose to completely un-install Graphene and wipe your phone there's currently nothing that will prevent you from installing another OS built with a different signing key
And that's exactly what Stallman calls "free". If it prevents you from doing precisely that, it's not free. But it doesn't, so it's free.
Secure boot is a security feature. One that I want. One that makes GrapheneOS more secure than, say, a Linux on mobile. The whole point of GrapheneOS is that it is secure, and therefore it is designed around that. Thanks to secure boot, if an app manages to get root access and modify the system, it will be detect on the next boot, and therefore it won't persist. This is a desirable feature.
You apparently don't want that, it's your choice. You can use LineageOS, which allows it, or you can fork GrapheneOS and modify that part.
This is all free, this is all how it's supposed to work, this is all desirable. GrapheneOS is free to make the product they want, and that product doesn't allow you to have admin access.
You seem to misunderstand "owning your device". It does not mean "the software allows you to do everything you want", it means "you can install whatever you want on it". If you install something that does not give you root access (i.e. GrapheneOS), it is your choice.
Graphene literally implements secure boot. And again, I said it's borderline not-free, not actually not free so I don't know why you just wrote 7 paragraphs arguing against something I didn't say and have explicitly and repeatedly disclaimed.
Yes, GrapheneOS is free, but it has implemented features that designed to make it harder to exercise that freedom, and that put it one short step away from being not free.
> I don't know why you just wrote 7 paragraphs arguing against something I didn't say
I argue against something you keep repeating:
> GrapheneOS is free, but it has implemented features that are designed to make it harder to exercise that freedom
This is wrong. First because it does not make it harder to exercise that freedom, and second because GRAPHENE DID NOT IMPLEMENT IT IN THE FIRST PLACE.
People arguing the way you do is, IMO, one of the reasons the "free software" movement lacks credibility. You're just whining because you wish you could have root access on your system without having to install it yourself.
I'm confused. Are you saying Graphene doesn't implement secure boot? Or that you don't think requiring users to wipe their phone and install a custom OS build before exercising their freedom makes exercising that freedom harder?
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.
GrapheneOS will always choose security over privacy, even if that means playing into the hands of malicious actors like Google. For example they have stated they won't try to spoof SafetyNet because "we don't lie about security features"
I personally would prefer to have both but choose the privacy side when both are into conflict.
Both viewpoints are valid, but I don't use GrapheneOS for this reason.
Its quite obvious they dont want to spoof SafetyNet because it would anger Google and GOS developers will no longer get privileged access to security bulletins.
The OEM is Motorola. The partnership was announced earlier this year.
You are correct about them not getting early access from Google. There was a post within the last few months saying that Google no longer releases a lot of the code via git, but instead requires submitting a form and downloading the code via Google Drive. Google are actively trying to make third-party development difficult.
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.
We don't receive early access to Android releases or security bulletins from Google.
SafetyNet Attestation API was replaced by the Play Integrity API and has been shut down.
We don't do spoofing for the Play Integrity device integrity level because it's very easy for Google to detect and they can block it in many ways. They choose to focus on only blocking it being used at scale. We've explained we aren't doing this because we don't want users depending on it and then having it repeatedly break and become unavailable for long periods of time.
>For example they have stated they won't try to spoof SafetyNet because "we don't lie about security features"
They said they don't want to do it because it would stop working in the future when Google move to enforcing hardware-based attestation and it is not sustainable.
No, that's completely wrong. GrapheneOS is a privacy project and solely works on security to protect privacy.
We never said that about the SafetyNet Attestation API and that's a dead service. We've explained that we cannot provide a long term for the Play Integrity device integrity level because they can easily detect spoofing and very easily block it. The device integrity level is also gradually phasing in a requirement for hardware attestation. Apps already use the strong integrity level to enforce it.
It seems wise to have at least one alternative mobile phone app store. Even if it isn't very good. If the government can tell Google to do trivial things like, for example, change the name of bodies (plural now) of water, it can turn off your app updates, trapping you on insecure versions indefinitely. This probably matters more if you live outside of the US, but if I had a plan B for an app store on my phone, I would certainly at least evaluate it.
Name changes happen all the time and I would expect Google to match what the government sources use locally. The fact that the government is capricious is no reason for me to desire Google to become an alternative naming center.
The government didnt ask google, they changed the name on the Geographic Names Information System (GNIS), which is the official legal mapping source which other companies like Google etc use. Hence the change filtered down through software from the top official channel.
For example, the banking app I have refuses to be installed from the Play Store on GrafeneOS due to "not-certified" device, but works perfectly fine when installed by Aurora.
The check seems to be purely store-based and never enforced later.
Do you trust the banking app installed from Aurora enough to do your online banking?
I don't, and I really wish there would be a decent way to verify that the installed/provided apps are legit. For me this is the biggest downside of using GrapheneOS, which I'm otherwise extremely happy with.
(for me, the whole point of using GrapheneOS is privacy and not sending data to Google, so using the PlayStore is not an option)
I'm pretty sure if I try calling my bank or searching the website to confirm the developer's public key fingerprint, there's not going to be any answer. You have to ask Google's servers to give you the APK and trust what it gives you, either via the front-end called Aurora or the front-end called Play Store
Maybe not in practice, but in theory, it works. I don't think there's a better way of handling this without relying on some centralised authority (Google) to validate the authorship of an app, which is hardly desirable.
I think in general trust is established for Play Store apps by downloading the app with the Play Store on a phone with Google Certified Android. Then the app can get the signing key for storage in the database. Then this can be used to verify APKs downloaded outside the play store.
> you can sign into the Play Store with a Google Account that isn't tied to anything else.
The problem with this is that increasingly Google is insisting on having a phone number to create a Google account. Further, they are aggressively deleting old accounts that appear to be dormant.
The good old days of creating a Google account with just an email seem to be swiftly becoming a thing of the past.
I recently had to set up a new Android device for work. Since I keep all my personal accounts separate from my work accounts, I needed to create a new Google account on that phone. I ended up paying $8 for a month of the cheapest service I could find just to get a phone number so I could create that account.
Better security, for once. You get (security) updates a lot faster with GrapheneOS.
Also on GrapheneOS, Play Services and Play Store come unprivileged, sandboxed like any other app. So Google is not an admin on your phone, which I would argue is one step towards "severing the umbilical cord".
Moreover, GrapheneOS doesn't have any issue with apps sideloading.
And more. There are many reasons to use GrapheneOS.
Using the Play Store on GrapheneOS whether via sandboxed Google Play or another frontend definitely doesn't defeat any the purpose of it. You do not have to use the Play Store on GrapheneOS, but the privacy and security features it provides are not cancelled out by using it.
GrapheneOS has privacy features such as Contact Scopes and Storage Scopes which are most useful when using privacy invasive apps. Using privacy invasive apps doesn't defeat the point but protecting against those is a core part of the purpose of GrapheneOS. Our Sandboxed Google Play compatibility layer is a privacy feature itself to enable people to use those as regular sandboxed apps without invasive access to be able to run apps depending on them.
GrapheneOS (the project) might recommend for or against certain things in relation to their specific objectives, but that doesn't mean all GrapheneOS users have the same objectives or need to comply with the opinions of GrapheneOS.
For instance, I use GrapheneOS because it provides better security and privacy out of the box than LineageOS, but I'm also not so paranoid that I'm going to just blindly listen to advice against using F-Droid. What I want out of my Android instance is good security defaults with no bloatware, not to stop the NSA from looking at my travel photos and what HN articles I once looked at. It's okay if my OS is great but not perfect.
So yes, I am a GrapheneOS user who is [modestly] hurt by this. Signing in with a dummy account is just another one of those things that will end up being futile in years to come when Google requires iris scans, DNA samples, and anal probes in order to get a new account. Personally, I'd prefer installing whatever software I want on whatever devices I [pretend like] I own, without telemetry or jumping through hoops.
I've honestly never understood why F-Droid even still exists. Every time I've tried to use it (as recently as half a year ago) it's still a shitshow and never displays or updates apps correctly. Half the time an app showed up on the website that didn't show up on the phone app. The other half of the time even when I did get something installed, it would just never understand that an update existed and needed to download and update a given app. It's one of the worst pieces of software I've used in a while, and I can tolerate a good bit of jank from FOSS apps.
> Every time I've tried to use it (as recently as half a year ago) it's still a shitshow and never displays or updates apps correctly. Half the time an app showed up on the website that didn't show up on the phone app.
Sounds like an accurate recreation of the Play Store experience to me.
This is not me simping for Google, I would honestly prefer literally anyone else with an acceptable app store experience, but I can honestly say I've never had that experience with the Play Store. If there's an update, it updates. If there's an app, it appears in search. On the rare occasion an app doesn't appear and I go to the Play Store website looking for it, the reason the app didn't show up is because it's listed as incompatible with my device (usually Android version too low or too high).
> never displays or updates apps correctly. Half the time an app showed up on the website that didn't show up on the phone app. The other half of the time even when I did get something installed, it would just never understand that an update existed and needed to download and update a given app
You probably "just" need to pull down while on the "Latest" or "Updates" tab, to update your repository (it will show a small banner at the top while it's doing that). It's incremental, so it may take a while if it has been some time since you last did it (and auto-updates are disabled).
The way F-Droid works is that it downloads the whole index and then the catalog, version checks, etc, all runs locally, quite similarly to some package repositories actually.
I am not claiming its intuitive, but I think that part works fine once you understand how it works.
The last time it wouldn't update an app, I could see in the app store and on the website that my app had a new version, but no matter what I did, I could not make it update the app. I don't know what I was doing "wrong", but I think if I couldn't figure it out or make it happen, there's something very wrong with either the app or how it's "supposed" to work. Neither of which is an acceptable user experience for me.
F-Droid builds all apps by themselves, which especially with their old servers took a lot (between detecting that the update exists, building the app and going to sign everything at their air-gapped signing computer).
Now a lot of apps use the "reproducible builds" feature, which means that F-Droid will distribuite them as they come from the author, leaving its digital signature; but they still need to build them before distributing them, to verify that what the author built corresponds to the declared source code.
With the much powerful servers that they've had for a few months builds are a lot quicker, but there are still steps that can take several days, especially the part of signing the apps' index on their air-gapped computer.
There's a ton of things that could be improved, and it would be best if there were an alternative with better maintainers, but they're currently the only service of this kind for Android (well, IzzyOnDroid is a partial alternative, if you're careful to check their reproducible builds results).
My understanding is that F-Droid is hosted out of some home servers (instead of some universities like other similar package managers) so the bandwidth leaves much to be desired. But the UX is definitely a big part of the problem. I don't understand why it tends to abort downloads when I background it, and I don't understand why it doesn't show a toast that it aborted the download.
I very much prefer Obtainium these days despite the setup steps. I don't think it's a coincidence that Obtainium, Aurora, Zapstore, etc. are gaining mindshare over F-Droid, just like how Brave has explosive growth over FF.
Doesn't match my experience (or anyone I know that uses F-Droid), FWIW.
We search for stuff, install it, it updates in the background. We install some of our own repos, but the bulk of our apps come from F-Droid's default repos.
Hard to reconcile your account with my experience without specifics.
Yeah, the experience isn't great and there are better alternatives but F-Droid was there before anything else existed. It's also great to just have it as an option.
Yes, F-Droid and its apps are great <3 They add so much security by simply not having a lot of tracking code that can be exploited and tries to hook all over your system. And they have reproducible builds which is something the commercial stores don't even bother with. This is really important for security. I don't understand that GrapheneOS advises against them.
And yeah the iris scans sound like a scare but only 2 years ago there was a constant line of zombies here in the shopping mall giving their eye scans to altman.
The masses really don't care about privacy if you give them a worthless trinket.
I use it on a phone with (unfortunately) regular google play services. If I sign into the play store, that same account will be used for all other google services on the phone too. I'm not going to do that. I just don't want a google account (nor an apple one for that matter)
...with a Google Account that isn't tied to anything else
That isn't completely possible these days. Last I checked they want an existing email address and/or a cellphone number for verification. I guess "not tied to anything else" is proportional to how much you trust them to delete either of these bits of info after they are used, and not associate them with other accounts you might have used them with in the past/future.
GrapheneOS is defending against different things I guess. My personal threat model is protecting myself from the tentacles of these behemoth tech companies. To that end, GrapheneOS approach of "just install google play" is not good enough for me. I fail to see the privacy advantages compared to e.g. MicroG".
So, GrapheneOS is a supposed alternative to using Google's OS and their surveillance and adware - except you're supposed to run it on Google hardware, and apparently with a Google account and connecting to Google's services.
GrapheneOS does not include any support for using a Google account and does not require using Google apps/services. There are many inaccurate statements here about what we supposedly recommend. We do not specifically recommend using the Play Store as a source of apps in the first place. We recommend using the sandboxed Play Store for obtaining apps from the Play Store.
GrapheneOS uses Pixels because those are still the only Android devices with reasonable security including decent updates, working encryption for users without a strong passphrase and the hardware functionality usable to provide decent exploit protection. GrapheneOS is in the process of adding support for upcoming Motorola devices meeting the official requirements.
No, we do not recommend using the Play Store as a source of apps over other options such as Accrescent. We document how people can obtain apps from the Play Store via both the sandboxed Play Store and Aurora Store. We explain apps with store listings configuring to block a non-Google-certified OS can be obtained via Aurora Store but that the sandboxed Play Store is generally a better way to install apps from it. Giving people recommendations on how to use a certain source of apps is not a recommendation to use it over the options we recommend including Accrescent.
Pixels are currently the only devices providing the updates and security features listed at https://grapheneos.org/faq#future-devices. GrapheneOS has an official partnership with Motorola where their devices are being improved to meet these requirements and provide official GrapheneOS support. We're actively working on it with them. We've reported vulnerabilities, weaknesses and made feature proposals to Google for Pixels but they certainly haven't directly helped us or supported us.
We don't recommend using the Play Store as a first choice for obtaining apps. Aurora Store is another way to use the Play Store as a source of apps. If someone is using sandboxed Google Play in a profile, it makes sense to use the sandboxed Play Store to install apps. Aurora Store is mainly useful as a workaround for store listings enforcing Play Integrity and we do direct people to it for that.
Aurora Store still works fine. It doesn't require the default-enabled account sharing feature. It's not Aurora Store which is getting blocked but rather account sharing. Account sharing is against Google's terms of use and is now being detected more aggressively. We've warned about this for years but it took longer than expect for them to ramp up banning it. It's likely going to continue getting stricter.
Also, EU is pushing towards more "open" app-stores through anti-trust.
Not that it requires Google to "open up" their play-store, but that they must allow other app-stores to work on the same level. So basically allowing devs and users to move elsewhere.
I use Aurora on GOS. I get that they say sandboxed Play is more secure than Aurora, but I prefer it for its lack of toxicity and absence of shitty dark patterns.
I think the increased popularity of GOS is going to draw in more users like me who picked it for reasons adjacent to Graphene's original purpose, and I hope it's not too annoying for their community.
I actually think there's already a lot of us in the 'community' as-is. I personally describe it as 'Valuing Privacy/Freedom over Security'. One pretty clear example of this is how they don't recommend using FireFox Mobile and F-Droid, both of which I use regardless because I'm not willing to put up with worse privacy/usability tradeoffs in the name of (imo 'hyper-')security.
I think it's fine the mission of the project isn't directly aligned with some of us, though I can tell we often get on the core contributor's nerves lol
FYI, there are ungoogled chromium builds for Android. Firefox Mobile really is a lackluster browser unfortunately both from a usability and security standpoint (e.g. IonStack worked on Fennec)
I'm using Firefox mobile for many years exclusively (since chrome forced some stupid feature on me, I think it was tab groups which I hated and couldn't turn off. And of course no ubo). Could be a bit faster probably? Otherwise don't see any issues.
I would actually argue the exact opposite. All of the Chromium-based forks are a usability disaster. I have to use grid view only to see my tabs? It took them most of a decade to finally get the relatively common place bottom bar, and it still arbitrarily decides to ignore your setting if it thinks your screen is "too big"? It's just failure after failure. I absolutely dread when some shitty site I'm forced to use refuses to load in anything but chrome and I have to open up Vanadium for the first time in forever.
pretty sure Cromite allows more options than just grid view which I hate, I usually use List, though I recently switched back to Firefox, already even forgot the reason
They actually ban people from their Discord (which is their official support channel - so much for privacy/security!) for mentioning F-Droid. I'm starting to think the creator of F-Droid must have run over their dog.
I have mentioned F-Droid many times in they official Matrix before they moved to Discord and not been banned. You might be misunderstanding what actually happened or have not asked the moderators why someone was banned.
GrapheneOS has official chat rooms on Matrix and Discord to provide people with multiple options. We also have semi-official Telegram and SimpleX groups.
No one has been banned from our chat rooms for mentioning F-Droid. That's a completely fabricated claim easily disproven with a search. There are a massive number of discussions about it where people often disagree about it.
This is the exact reason I quit using Graphene. It felt exactly like selling out control of my device to the Graphene devs in the same way a stock phone is controlled by Google.
Far, far too "opinionated" for my taste. I frankly do not need the hyper paranoid security features like a hardened memory allocator or disabled root. I would rather be able to use my device the way I want, even if that's notionally "less secure".
I really wish there were another option. Lineage is too far in the opposite direction and feels like ad-blocked stock. Google still owns my phone, there's just a more pleasant coat of paint on it.
they do similar things for people trying to use magisk, but also relock the boot loader. I gave up trying to bother, since the whole reason I use roms is for root first, privacy second.
> I frankly do not need the hyper paranoid security features like a hardened memory allocator
I get the part about disabled root - you're choosing to sacrifice freedom for security - though I don't understand why you wouldn't want a hardened memory allocator. It provides additional security over the stock OS for very little cost (slightly more resource consumption), in an era where we absolutely need as much security as we can get; what are you losing by gaining this?
They're both security, just security "against" different things. Graphene frequently fails to clearly describe the threat model when calling something "more secure".
For example, let's say hypothetically I want to be secure against the threat of Google pushing a targeted update to my phone that runs malicious code. Turning on automatic software updates from Google would make me vulnerable to that threat. Using MicroG instead of Google Play Services would make me less vulnerable to that threat. But Graphene devs say things like "MicroG is less secure than Google Play Services".
Similarly, if you want privacy you might secure your device by locking the bootloader with your own keys - not a third-party vendor's keys. Saying that's "insecure" is extremely misleading: it just puts you in charge of security, instead of abdicating to someone else.
I wish there were something like GrapheneOS that let you choose, yourself, who to trust instead of requiring you trust an OS vendor implicitly.
> Turning on automatic software updates from Google would make me vulnerable to that threat. Using MicroG instead of Google Play Services would make me less vulnerable to that threat
I would say that any auto-update mechanism is a threat, so in both cases you would disable auto-updates.
But Graphene devs say things like "MicroG is less secure than Google Play Services".
It is. microG runs Google DroidGuard blobs in a privileged process (to pass Play Integrity Basic). Reminder for those who forgot about DroidGuard: it's an obfuscated binary blob delivered to you by Google on each request that uses a special VM with constantly changing registers, etc. to avoid analysis.
Actually, MicroG by default doesn't download or run droidguard binaries at all.
You're missing my point here, which is that failing to describe a particular threat scenario leads to meaningless words spoken about ill-defined "security". Security has to be against some particular threat... it's not an absolute concept.
> I hope it's not too annoying for their community
There's plenty of people like that in the GOS community (the forum and the Matrix). Everyone generally understands that different people have different threat models and may want to do things that aren't the most secure. Otherwise everyone would be using GOS in airplane mode with disabled cameras and only paying for things with Monero.
The core dev team is obviously a bit more security absolutist, but even they usually dont mind
> Everyone generally understands that different people have different threat models
Citation needed. If there are such people in what can be considered a grapheneos community that haven't gotten fed up yet and left, grapheneos themselves sure doesn't understand this
> Otherwise everyone would be using GOS in airplane mode with disabled cameras and only paying for things with Monero.
Nah, they're fine with tracking, so long as it happens in their sandbox. The official website has an install guide for google's background services, saying it's fine because it's in their security model. So long as the modem and camera firmware can't access your contacts, there is no tracking in baghdad
>Citation needed. grapheneos themselves sure doesn't understand this
The GrapheneOS team understand full well that in cases where the Play Store does not allow installing an app on your device due to device or georestrictive rules you may have no choice. I have seen them mention this and acknowledge it first hand. What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want instead of being a substitution attack risk. I don't think that is unreasonable.
>The official website has an install guide for google's background services, saying it's fine because it's in their security model.
The context is that before sandboxed-play-services were introduced people were sourcing APKs in unsafe/via unverified routes and having all sorts of problems with app compatibility because since GrapheneOS is a privacy project that do not accept sending copious amounts of data to one party with a mediocre privacy policy they included no Google services at all. sandboxed-play-services is a specific solution to the problem of apps being dependent on Google Mobile Services for functionality, and in that sense it is entirely optional. It was the best way for them to provide compatibility without destroying the privacy of their platform by introducing a privileged Google binary that can glean and abuse your production environment. It's reduced to the same level as any other app the user might choose to install themselves (which GrapheneOS want absolutely no say over as a user freedom protecting project).
GrapheneOS do not bundle any Google services in their official installation. They do not endorse Google's data collection and service practices. They do not believe Google tracking is fine in anyway, and the evidence is here: https://eylenburg.github.io/android_comparison.htm
What they have done is provide a workaround for people who have no alternative, while making sure it does not violate the device owners device in a special way compared to any other app they might install.
> What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want
Aurora is a lot less invasive while achieving that same goal, but they recommend installing Googleware instead. Wouldn't the open source front-end be the "bare minimum" standard to strive for, with all the added tracking when installing GMS falling below that standard?
> It was the best way for them to provide compatibility without destroying the privacy of their platform
Again mixing up threat models and equating it to privacy. It may not compromise the technical security (as GrapheneOS goes to incredible lengths to point out while implying that this covers everything), in that it doesn't allow Google to access data on the device that Android's security model says they shouldn't have, but Android's security model isn't my threat model. My threat model, and many other people's, includes Google tracking me. If nothing else, it can always see which IP addresses I pop up on together with other people and build a social graph if they wish (or if they're ordered to)
By just grabbing the apk files from their servers whenever I open aurora.apk, that issue can be almost entirely avoided, for example. There's the matter of microG but just to show that there are easy wins to be made that work for a lot of apps already that GrapheneOS vehemently opposes 'for security'
It's not strange that they offer a way to install GMS in a secure manner, it's strange that they don't recommend open alternatives where possible
And you're surely aware of the obvious bias of that link you shared. It's like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. And that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one could outweigh all others
>Aurora is a lot less invasive while achieving that same goal, but they recommend installing Googleware instead... GrapheneOS vehemently opposes 'for security'..
It's more accurate to say they suggest improvements not vehemently oppose. The community/project have opened issues with the Aurora Store project to get them closer to that goal of making sure the app downloads cannot be intercepted https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/697 and mitigating the TOFU problem by ensuring the first install is definitely the one the developer distributed via Play https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/1177
This is what I meant by standards. They only suggest Play Store because it is an existing solution that already meets those standards.
>Again mixing up threat models and equating it to privacy. My threat model, and many other people's, includes Google tracking me.
GrapheneOS are very conscious of avoiding sending data to Google where unnecessary. The evidence of that is in the link previously shared, but also in third-party reviews like https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter...
They also do advise that if you want to avoid Google's gaze you should explore non-Play Store apps if they can meet all your needs because Play Store apps are extremely likely to include Google libraries and dependencies that expose even more data to Google. Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store. I believe that from their perspective it takes a lot of careful consideration and planning to avoid exposing data to Google. This consideration and planning would never end with just Aurora Store so hopefully you can understand why they would not recommend it as a well thread-modelled privacy solution for Google. Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically. Does my explanation make sense?
>... like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. ...that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one can outweigh all others
I agree. Checklists are a bad way of conveying verified information and importance of each feature, and I do think the table can be improved. Thankfully it is open to contributions from Github account owners.
The first ticket you link is not by someone who seems to work on GrapheneOS, at least there's nothing in their profile to suggest as much. The improvement they suggest is hardening, preventing basically nation state attackers who either compromise or compel a CA to issue a false certificate for Google's servers
The second ticket is about checking if the data that Google sent via TLS has a second signature from Google. It doesn't prove what you claim about ensuring the key is from the developers. This is more useful for places like apkmirror that distribute apps and could include the signature that Google tacked on, for people who trust but cannot use Google; to verify Google's signature without needing to be able to connect to Google. That's not what Aurora does, so it's not relevant to the project. Can be defense-in-depth in case Google's front-ends are compromised but the signing back-end is not, but again, that's less likely than getting struck by lightning and such a powerful attacker could also just compel the developers to make a special update that performs malicious actions on their target
This is the level of misunderstanding that I find very common among GrapheneOS users btw: it all sounds good if you don't know much about it, but when you drill down to what it actually does and consider a specific threat model, it's no reason to recommend Google Play over Aurora for 99% of people's threat models. If you're an oppressed journalist in Iran or whistleblower in the USA, then the cert pinning could help, but most of us are more impacted by everyday tracking than by targeted nation state attacks
> Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store.
I'm probably misunderstanding you, but nobody said downloading an app via Aurora changes the contents of the download to become privacy-friendly. Like, downloading a .exe via an open source browser also doesn't change the download compared to if you download it with Google Chrome
You still have to be wary of what you download, deny it internet access if applicable, etc. It's just that you don't have to have google's stuff running in the background all the time, toggling internet access on (letting it upload queued telemetry) anytime you want to download or update an app that is distributed only via google
Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
> Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically.
What do you mean by nonsensically? I didn't know they recommend it under any circumstance though, that's cool. Do you happen to have a link for that, or remember where they wrote that?
>preventing basically nation state attackers who either compromise or compel a CA
I don't think the compromising, self-compromise or compelling of a Certificate Authority is a feat reserved for state-level attackers. I am not sure why it would exclude any malware that gains enough privileges, or existing campus-enterprise mobility management apps/parental control/antivirus that get compromised or hijacked. But really it comes back to one of the original points which was that GrapheneOS are comfortable recommending and promoting solutions with a high level of security/privacy as a general rule.
>The second ticket
Yeah, I believe I confused the 'frosting metadata' part with the important whole APK Signing Block. The part I wanted which the app store client should verify would be the signing certificate hash which you compare to what the server says the package should give you. As far as TOFU mainstream users basically trust in Google's Play Security & reviews process instead of developer signing certificates/keys because most developers do not publish that out-of-band somewhere they individually control. Widget on Dev's Socials/Site + Publishing hurdles + Developer Console auth + Google security/review add up to a non-zero chance the listing is good. When you get the app you have the benefit of certificate pinning and app signature verification to make sure that non-zero isn't majorly reduced in distribution/transit.
GrapheneOS don't even recommend getting apps from Play anyway if you can verify and source the apps directly from the developer.
>very common among GrapheneOS users btw
Can't say anything for your experiences, but of course I only speak for myself. I can say though that the GrapheneOS developers themselves will never tell you the OS is specifically for high-risk oppressed journalists and whistle-blowers. Another big disconnect is that GrapheneOS believe things need to be much more attack/abuse-resistant for the 99% than they are now, so asking them to aim a little lower than current standards will cause a lot of misunderstandings: https://xcancel.com/GrapheneOS/status/2044440381803069778#m
>You still have to be wary of what you download, deny it internet access if applicable, etc. Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
I agree mostly with this, but I think you can see it would be a bit painful and tedious for GrapheneOS to say "We can't endorse violating Google's TOS but Aurora Store is an option under specific circumstances and technical conditions. Apps from Play/Aurora may not contain any Google libraries, GMS dependencies or involve sending data to Google as potentially stated in their privacy policy but there is no accessible way to determine this per-app at a glance." every time they need to talk about Aurora Store.
>Do you happen to have a link for that, or remember where they wrote that?
I've been stuck with unupdated apps because Aurora hasn't been working for me for a while. A few of them have been nagging me to update. I have everything Google disabled or removed, and no I won't reenable any of it. Also I use anon strictly on Aurora, and no I won't login with my Google account; haven't logged in on a phone for over 8 years now and I have no intention of breaking the streak.
I had last successsful update on August 26, which I wouldnt call for a while, tried yesterday, I've got error messages everyone mentions
today I bothered to try various anonymous Aurora accounts and found finally the one working (like 5th in row) and updated the apps, I can live with updates once a week, not exactly sure what is OP doing
I mean if they are really rate limited just give me waiting time, I don't really care whether I have to wait in queue for an hour if it will update the app later without my intervention
btw. I am not using graphene, find it too paranoid for my taste, though I use my phone without google account for like 10+ years and current phone is first where I have (not disabled/have preinstalled) google play services
Unfortunately Google doesn't return a waiting time, and the limits are probably high enough to be irrelevant for normal users (although I've seen articles of it happening on the Play Store, over the years).
Aurora hasn't worked right for the most part for a year due to device attestation shit.
I'm meh on it. Not being able to install the shit from play store isn't such a bad thing. It is lame as hell that Google is doing their damndest to make apple look user friendly.
Honest question, because AFAIK there's no guarantee or (legal) requirement to support any API. Whether that's fully documented, has SDKs or whether it's something reversed-engineered doesn't matter WRT the support the company owning the API is supposed or required to give.
An official API is an API described in official documentation and explicitly open to the public, an unofficial one is one not documented publicly and only meant for the company's products.
If it's rate limits, I wonder if Aurora Store could just download and mirror the apk for the top 40 most popular apps (probably >50% of their downloads) and serve that mirror to most Aurora Store users who click the "download" button? Then for less popular apps they can use the old system.
> Aurora uses burner account for anonymous login. looks like their account pool is flagged
This seems like it was destined to get banned somehow... and I don't think it means that the store itself is blocked, just the pool of accounts they (ab)use.
Google account sharing is disallowed by their terms of use. They're getting better at detecting and banning it. Aurora Store still works as a Play Store client but the approach they've been using to bypassing a need to create an account was destined to get blocked as you've said. We've been warning it would likely be increasingly blocked for years. It took longer than we expected to reach this point.
That’s quite the conclusion to derive from a Gitlab issue. Do you mind sharing your thought process or was that just a knee jerk reaction without any reasoning behind it?
Remember when people kept justifying Android over Windows Phone/Maemo/WebOS/BlackBerry/FirefoxOS on the grounds that it was free and open source software, infinitely customizable, and that Google was a good-faith partner who wanted openness in the mobile market?
AOSP is still open. The problem is nobody wants to bear the (monumental) cost of polishing and convincing brands to allow installing it in THEIR devices. Google was motivated back then for creating an alternative and openness was a good bait.
The fact that no one wants to bear the cost to pre-load it on devices, when combined with the fact that it's not nearly as easy to install OSes on mobile devices as it is on most laptop/desktop/server machines, means that it might as well be closed-source. The point of software is to be executed. If I don't have a good way to execute the software for its intended purpose, I have a collection of ones and zeros, and nothing more.
The window to have a real open mobile OS is starting to close. If there is to be a meaningful change, it must happen soon.
This is exactly why I switched to Android. Running any Linux binary with just a small bit of patchwork to get Xorg running (this was before Wayland) felt like magic. So much power in your pocket, I could plug a keyboard and display into the device and use it as a computer! And internet-connected 24/7! Coming from a literal Nokia where I made some web-apps for the javascript-supported browser (that was already a major leap for a mobile phone), it blew my mind. The sole reason Android blew up is the endless possibilities developers saw (starting with the device manufacturers of course). Now the developers are here, the competitors haven't been competing because who cared about Firefox OS or Windows Mobile even back in 2014, and so Google can do whatever
I maintain my grandmothers phone, which comes down mostly to just updating WhatsApp once in a while. Obviously she doesn't have a google account, so I've installed her AuroraStore.
It's a shame that there is no official way to install apps on android without a google accout[1], since it's a basic functionality, just like calls or a web browser.
[1] For obvious reasons I don't want her to download apks from the internet.
Is it not possible to just download the updated whatsapp apk from some online source? That is the benefit of android after all, side loading is still possible relatively easily.
There are whatsapp cracked apks which actually work as whatsapp... and they have "extras", and I would never install it, although I have seen it installed
There are other Android stores. Amazon ran one for the longest time. Many brands have their own app stores as well.
It's the app publishers defaulting to Google that's the biggest issue.
At least WhatsApp has an official APK download, most apps don't.
That said, Google will still let you update apps without being signed in. Hold the Play Store icon to open the quick action menu. From there you can go to "my apps" and update all of the apps on your phone, bypassing the login prompt. Not great, but a workaround that should do the trick while Aurora finds another way to hack their way into the Play Store APIs.
Okay, it was a bit of clickbait. Didn't expect it to be picked up like this.
Mistake from me: apparently GrapheneOS does not recommend Aurora Store (citation needed). Kind of weird though; it means Google still knows a lot about you, which doesn't seem very privacy conscience.
Google blocking Aurora Store was a conclusion made in the bug thread. It was not my conclusion.
And for the nit pickers: Sailfish OS is not Android, but its emulation layer _is_. :shrug: Even though Sailfish is nice, without its Android layer it is practically unusable.
Funny thing: the 'busy server' problem existed for almost a week. I could download 1 app per day max on my Jolla C2. But just now, now that this thread makes top of Hackernews, everything started working just fine!
> Kind of weird though; it means Google still knows a lot about you, which doesn't seem very privacy conscience.
I remember being in the GrapheneOS room and hearing them directly recommend using Windows 10 over Linux, as it was more secure. They are known to prioritize security over privacy.
GOS's intended audience are those who are in danger of being hacked or persecuted, not privacy conscious users trying to escape surveillance. Google, for all their faults, is pretty unlikely to hack your phone and reveal your secrets.
There's many privacy features that work to allow users to use anti-privacy apps like WhatsApp with more privacy. Contact scopes, storage scopes, sensors permission, network permission, VPN leaks fixed and enhanced secondary profiles.
Plenty of less scrupulous surveillance companies like Facebook take advantage of security flaws for their surveillance so it's important to start from a secure baseline to guard against this threat.
We don't recommend using the Play Store as a first choice for obtaining apps. Aurora Store is another way to use the Play Store as a source of apps. If someone is using sandboxed Google Play in a profile, it makes sense to use the sandboxed Play Store to install apps. Aurora Store is mainly useful as a workaround for store listings enforcing Play Integrity and we do direct people to it for that.
Aurora Store still works fine. It doesn't require the default-enabled account sharing feature. It's not Aurora Store which is getting blocked but rather account sharing. Account sharing is against Google's terms of use and is now being detected more aggressively. We've warned about this for years but it took longer than expect for them to ramp up banning it. It's likely going to continue getting stricter.
Aurora Store still works fine without the default enabled account sharing feature. Google hasn't blocked using Aurora Store as an alternate Play Store client but rather account sharing. By default, Aurora Store violates the Play Store terms of use by sharing accounts. That's what's being detected and blocked.
Aurora Store isn't one of the main recommendations from GrapheneOS for obtaining apps. It's mainly useful as a workaround for installing Play Store apps requiring the device or strong integrity level for their Play Store listing. It would be better to find another way to deal with this.
272 comments
[ 0.23 ms ] story [ 13.1 ms ] threadYou can install the Play store from the GrapheneOS App Store.
In fact I'm pretty sure the GrapheneOS folks advise against Aurora Store, etc.
The problem is that even if you have separate google accounts on each android device, Google can still track you by looking at your contacts.
How could an account from a completely different company let you login to Google's Play Store???
You probably mean a Google account that uses your Proton mail address?
Aurora Store can be used without the shared account feature. The shared account feature was on track to getting blocked for years and we've warned about it. Sharing accounts is against the Google terms of use and they've been ramping up their detection and banning of it. It's somewhat strange they allowed it to go on for so long. Aurora Store does still work as an alternate Play Store frontend since Google hasn't blocked that.
Due to Aurora Store bypassing the Play Integrity API store listing restrictions, they may decide to take steps to hinder it. It's a very easily bypassed way of using the Play Integrity API but it harms alternative operating systems.
P.S. Sailfish OS is NOT an Android distribution. It is a proper Linux system and they have their own custom Android runtime (AppSupport) as a layer on top for running Android apps. This runtime _is_ Android under the hood, but is separate from Sailfish itself (has its own native app ecosystem).
Aurora Store works without the default enabled account sharing feature. The account sharing feature is disallowed by Google's terms of use banning account sharing.
For extra privacy, you can sign into the Play Store with a Google Account that isn't tied to anything else.
Somewhere in the FAQ GOS advertises that Play Services can be used without signing in, but they also recommend the official Play Store (which requires signing in) and explicitly don't recommend Aurora (which doesn't).
Unless I'm missing something, I don't see how you can functionally use Play Services signed-out when in order to obtain those apps in the first place, you need to sign into a Google Account for Google Play.
That's personally what I used Aurora for, plus as an easy way to export APK files.
You still need to supply Play Services:
GrapheneOS uses Sandboxed Google Play. LineageOS requires flashing a package like MindTheGapps. There is also microG, an open-source reimplementation of Play Services APIs.
Isn't that pretty much impossible? You need a phone number for verification, which effectively ties it to that phone number.
But you have to keep paying the monthly cost, if you loose access to a phone number in your Google account it's game over for any account recovery or "let's verify it's you" it might decide to throw your way.
Yeah now they have IMEI and all the other device specific info anyway they might as well forego the phone number
> Isn't that pretty much impossible? You need a phone number for verification, which effectively ties it to that phone number.
I just want to follow-up on this because some people claim this is not correct because they have managed to create accounts without phone numbers.
Indeed, I think to this day, under special circumstances (like e.g. on reasonably recent Android devices) you might be able to setup a Google account without phone number.
The trick is, that in the general case, you can not keep this account online indefinitely.
I once worked out a trick to get it going and I was feeling safe because I had setup 2FA and backup codes (see https://masysma.net/37/google_how_to_create_an_account_witho...).
First thing to note: This way of account creation does not seem to work anymore.
Second thing to note: After once logging in from a different country, trying to login again REQUIRES me to provide a phone number after successfully giving username/password/2FA code. No way to use the recovery code instead...
Also, given that this account was never before connected to a phone of any kind, by definition, the addition of a phone number cannot provide additional security confirmation (it's data that simply wasn't present before and any "personal" phone number could potentially do -- of course I haven't tried, because that's the point of not linking a phone number).
I think this way it is finally proven that they only do this to harvest the data/phone numbers and any claim of enhanced security is void.
I write this after having lost the second account to the phone number required screen despite being in possession of all the credentials which were ever assigned to that account...
"Hope ya got ten bucks!"
(I got a random 5G Moto phone for ~$10 on clearance and it was an absolute shitter of a phone full of garbage packed in malware, but after cleaning and debloating as much as I can, it's at least a nifty toy to poke at Termux or something.)
At the risk of being a privacy absolutist / fatalist: Google’s entire business model is surveillance. They follow you around and track your habits so you can be influenced. Given that, a Google account is always tied to something else.
But my goal is to avoid a stranger gaining access to my google services if they manage to unlock a lost device or steal my TV/streaming box that has no lock at all.
I wish Google supported a permission system per device. For example on most of my android devices all I really want is to be logged into Youtube and the play store. I most certainly do not want those devices to have access to my contacts, emails, calendar, keep, drive, payment, etc. (I don't personally use all of those things, but you might and that's what a random thief would gain access to.)
Yes, the advertising targeting is incredibly invasive, but let's not pretend they aren't providing world class Search, Email, Docs, Maps, Video (YT), etc in exchange.
GrapheneOS is much more privacy focussd than any other mobile operating system. Accrescent is the end goal for a secure and private app store but it's still in alpha. GrapheneOS is also the best for degoogling (eliminating all google services) because it comes with zero Google services unlike all the other ones listed here: https://eylenburg.github.io/android_comparison.htm
How can you call other OSes more privacy focused when they haven't closed as many VPN leaks as GrapheneOS? That's like bare minimum for privacy.
Therefore, the system needs to protect itself and other apps from the user. Which is very much contrary to software freedom.
Yeah, the goal is privacy although the OS is completely open source.
They do improve user experience by allowing disabling emergency alerts, call recording without alerts, no mandatory camera noise in Japan, no extra warning popup from installing APKs from the web (it's the same permission in every app store iirc), increases password length to 128 digits. All the network services are open source afaict while all the other mobile operating systems listed in that android comparison connect to Google's closed source services, netowrk permission, sensors permission, storage scopes, contact scopes.
You can still easily install whatever Android app you want on GrapheneOS and you can install dangerous apps like shizuku and apps with way too many permissions. But yeah the goal is privacy so that everyday people can protect themselves as well as journalists can protect themselves. I want journalists to get the best privacy possible without having to know a ton of technical things or making many choices.
Looking at their public statements on the matter, it seems like the problem isn't exactly that they treat the user as a potentially hostile actor so much as that they treat the system UI and persistent storage as a potentially hostile actor (though I admit from a practical perspective that's nearly the same thing): https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
I believe you misunderstand what "software freedom" means. You can compile and install GrapheneOS yourself, and you can grant yourself admin access. This is software freedom.
Software freedom does not mean that you should run everything as an admin, always. And just in case: software freedom does NOT mean that you should remove your firewall and let everybody SSH into your server by having a blank password.
I think it's fair to say that that's at least borderline anti software freedom, even if it's true they have good security reasons for doing things that way.
Then you don't understand software freedom either.
Software freedom doesn't mean AT ALL that random projects on the Internet MUST implement the features YOU want. Never, not at all, it's not borderline, it's not up to debate.
Software freedom is about being able to use the software the way you want, as in "you get access to the sources, you modify them, build them and run them". You can do that with GrapheneOS (well except for the binary blobs situation, but that's not in GrapheneOS' hands at all). Software freedom is NOT about GrapheneOS giving you root access on official builds because you want it. And it's also NOT about GrapheneOS installing Doom on the official builds because I want it.
You can't use the software in the way you want if it uses hardware backed cryptography to block you from doing so.
> you get access to the sources, you modify them, build them and run them
This is completely untrue for 99% of the population. If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
You could argue "but someone else could modify it for you, build it, and make an easy way for you to install it", and normally I'd accept that, but given that installing that modified version would require you to completely reset your phone and install the new modified OS from scratch, I think it's debatable at that point whether Graphene itself is the source of that freedom, rather than the fork. Like I said, borderline.
You can use the software the way you want, from sources. If I run an open source server at home, it does not give you the right to enter my house and come reboot my server, does it?
> This is completely infeasible for 99% of the population
Sure, it isn't. Still that's what software freedom is.
> If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
I disagree, I'm very happy that free software exists.
> I think it's debatable at that point whether you'd still be running Graphene
It's not: you're running a fork at that point. That's precisely how free software works.
> And if exercising your freedom requires you to stop running Graphene and start running something else, is it really fair to say Graphene itself supports that freedom?
Yes! Again that's precisely what software freedom is about! When you run GrapheneOS, you have the freedom to fork it and run it however you want. When you run Windows or macOS, you don't.
> If you're still not convinced, consider what would happen if companies started using remote attestation to verify you're running the official GrapheneOS build and block forks...
Well GrapheneOS would still be free software?!?!? It's the software from those companies that wouldn't be. I hate remote attestation as much as the next person, and typically banks absolutely suck because they love doing that kind of bullshit. But because banks suck does not mean that GrapheneOS is not free software?
Note that I am not trying to contradict you for the sake of it. I believe too few people understand how open source works, and that is a pity because it is important to understand it. When I open source some code I wrote, I make it available for people to do whatever they want with the code. I don't give them ANY RIGHT on the products I sell (even if those products are running said open source software) or on the feature I implement.
Too many people believe that because it's open source, they have a right to tell the authors what features they should implement. This is wrong. You want root access on your GrapheneOS? Go fork it. I don't want it, I am happy with GrapheneOS. If GrapheneOS gave me root access, I would fork it to remove it. And that would still be free software!
I think I have a broader definition of software freedom than you do. In this hypothetical scenario, GrapheneOS itself may technically be "free software" in the sense that the source code is open, but it would still be cooperating in a intentional scheme to prevent you, the user, from modifying it to work the way you want. Same deal if they started selling locked hardware with their signing key hard coded so you can't install a fork. You would legally have the ability to fork the software, but technical measures would be preventing you from running it.
Granted, they're not doing that, but it's one short step away. That's why I say it's borderline anti-freedom, not that it actually is.
I don't think it makes a difference whether the means employed to make a piece of software non-free are legal (copyright law) or technical (DRM, remote attestation, hardware locks). It's still restricting your freedom.
If they make their software open source, you get to fork it (sometimes contribute to it) and this is already very generous. But that's all.
I say that as an open source author and maintainer, and my experience is that the vast majority of developers do NOT understand that. I have been criticised, insulted, sometimes bullied by people who wanted me to implement whatever they wanted ON TOP of providing my work for free.
You can have your own definition of "free software" that means "the developers have to agree with my personal taste", and say that "Linux is borderline not free software because I want them to officially support Zig and they don't", but it doesn't bring much. What makes Linux free software is that you can fork it.
I guess I don't understand the need to have a definition that only serves for complaining about a free project not implementing a feature you want. I get it, you wish GrapheneOS gave you root access. But it is not the choice of the people who do the work and make it available for free. But because it is free software, you can fork it and modify it yourself, and this is great.
> Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense rather than a practical reality. These binaries are not free software even if the source code they are compiled from is free.
[1]: https://www.gnu.org/philosophy/free-sw.html#make-changes:~:t...
I didn't say anything about what GrapheneOS devs must do. They don't have to do anything. I just think that some of what they are doing comes close to impinging on user freedom (though it doesn't quite cross that line, in my opinion).
You can do all that with GrapheneOS today.
What you are asking for is root access on the GrapheneOS official builds. Where does Stallman say you should get it?
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known [...] in its practitioners' perverse terminology as “secure boot”—freedom 1 becomes an empty pretense
GrapheneOS implements secure boot, using a key you do not control. If you install GrapheneOS, the Graphene devs have the ability to push updates to the code running on your phone but you yourself do not unless you completely uninstall GrapheneOS and wipe all data on the phone.
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense
Tivoisation or lockdown or abusively calling it "secure boot" is, according to Stallman, "non free". GrapheneOS does not do that. GrapheneOS does not even own the hardware that could do tivoisation. GrapheneOS is the fork of the original project that has been updated and installed on the original device. That means that not only GrapheneOS is free, but AOSP as well!
> is that if you choose to completely un-install Graphene and wipe your phone there's currently nothing that will prevent you from installing another OS built with a different signing key
And that's exactly what Stallman calls "free". If it prevents you from doing precisely that, it's not free. But it doesn't, so it's free.
Secure boot is a security feature. One that I want. One that makes GrapheneOS more secure than, say, a Linux on mobile. The whole point of GrapheneOS is that it is secure, and therefore it is designed around that. Thanks to secure boot, if an app manages to get root access and modify the system, it will be detect on the next boot, and therefore it won't persist. This is a desirable feature.
You apparently don't want that, it's your choice. You can use LineageOS, which allows it, or you can fork GrapheneOS and modify that part.
This is all free, this is all how it's supposed to work, this is all desirable. GrapheneOS is free to make the product they want, and that product doesn't allow you to have admin access.
You seem to misunderstand "owning your device". It does not mean "the software allows you to do everything you want", it means "you can install whatever you want on it". If you install something that does not give you root access (i.e. GrapheneOS), it is your choice.
Yes, GrapheneOS is free, but it has implemented features that designed to make it harder to exercise that freedom, and that put it one short step away from being not free.
I argue against something you keep repeating:
> GrapheneOS is free, but it has implemented features that are designed to make it harder to exercise that freedom
This is wrong. First because it does not make it harder to exercise that freedom, and second because GRAPHENE DID NOT IMPLEMENT IT IN THE FIRST PLACE.
People arguing the way you do is, IMO, one of the reasons the "free software" movement lacks credibility. You're just whining because you wish you could have root access on your system without having to install it yourself.
I'm out.
Note that nobody (new) can submit to it today; the developer console HTTP 503s and is only available to an allow-list of developers.
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.
I personally would prefer to have both but choose the privacy side when both are into conflict.
Both viewpoints are valid, but I don't use GrapheneOS for this reason.
You are correct about them not getting early access from Google. There was a post within the last few months saying that Google no longer releases a lot of the code via git, but instead requires submitting a form and downloading the code via Google Drive. Google are actively trying to make third-party development difficult.
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.
SafetyNet Attestation API was replaced by the Play Integrity API and has been shut down.
We don't do spoofing for the Play Integrity device integrity level because it's very easy for Google to detect and they can block it in many ways. They choose to focus on only blocking it being used at scale. We've explained we aren't doing this because we don't want users depending on it and then having it repeatedly break and become unavailable for long periods of time.
They said they don't want to do it because it would stop working in the future when Google move to enforcing hardware-based attestation and it is not sustainable.
We never said that about the SafetyNet Attestation API and that's a dead service. We've explained that we cannot provide a long term for the Play Integrity device integrity level because they can easily detect spoofing and very easily block it. The device integrity level is also gradually phasing in a requirement for hardware attestation. Apps already use the strong integrity level to enforce it.
For example, the banking app I have refuses to be installed from the Play Store on GrafeneOS due to "not-certified" device, but works perfectly fine when installed by Aurora.
The check seems to be purely store-based and never enforced later.
(for me, the whole point of using GrapheneOS is privacy and not sending data to Google, so using the PlayStore is not an option)
I'm pretty sure if I try calling my bank or searching the website to confirm the developer's public key fingerprint, there's not going to be any answer. You have to ask Google's servers to give you the APK and trust what it gives you, either via the front-end called Aurora or the front-end called Play Store
https://github.com/privacyguides/verified-apps-android
https://github.com/privacyguides/verified-apps/
I think in general trust is established for Play Store apps by downloading the app with the Play Store on a phone with Google Certified Android. Then the app can get the signing key for storage in the database. Then this can be used to verify APKs downloaded outside the play store.
But using Aurora I can install it just fine and it works flawlessly.
The problem with this is that increasingly Google is insisting on having a phone number to create a Google account. Further, they are aggressively deleting old accounts that appear to be dormant.
The good old days of creating a Google account with just an email seem to be swiftly becoming a thing of the past.
lol. lamo, even.
Google states: Using a false name or incorrect information when creating a Google account is against Google's Terms of Service.
Interesting, I never tried Aurora on Graphene. For me the combination of Play Store and F-Droid worked really well so far.
I don't really see the point of using GrapheneOS instead of Stock Android if I then have to use the play store.
Also on GrapheneOS, Play Services and Play Store come unprivileged, sandboxed like any other app. So Google is not an admin on your phone, which I would argue is one step towards "severing the umbilical cord".
Moreover, GrapheneOS doesn't have any issue with apps sideloading.
And more. There are many reasons to use GrapheneOS.
GrapheneOS has privacy features such as Contact Scopes and Storage Scopes which are most useful when using privacy invasive apps. Using privacy invasive apps doesn't defeat the point but protecting against those is a core part of the purpose of GrapheneOS. Our Sandboxed Google Play compatibility layer is a privacy feature itself to enable people to use those as regular sandboxed apps without invasive access to be able to run apps depending on them.
For instance, I use GrapheneOS because it provides better security and privacy out of the box than LineageOS, but I'm also not so paranoid that I'm going to just blindly listen to advice against using F-Droid. What I want out of my Android instance is good security defaults with no bloatware, not to stop the NSA from looking at my travel photos and what HN articles I once looked at. It's okay if my OS is great but not perfect.
So yes, I am a GrapheneOS user who is [modestly] hurt by this. Signing in with a dummy account is just another one of those things that will end up being futile in years to come when Google requires iris scans, DNA samples, and anal probes in order to get a new account. Personally, I'd prefer installing whatever software I want on whatever devices I [pretend like] I own, without telemetry or jumping through hoops.
Sounds like an accurate recreation of the Play Store experience to me.
You probably "just" need to pull down while on the "Latest" or "Updates" tab, to update your repository (it will show a small banner at the top while it's doing that). It's incremental, so it may take a while if it has been some time since you last did it (and auto-updates are disabled).
The way F-Droid works is that it downloads the whole index and then the catalog, version checks, etc, all runs locally, quite similarly to some package repositories actually.
I am not claiming its intuitive, but I think that part works fine once you understand how it works.
F-Droid builds all apps by themselves, which especially with their old servers took a lot (between detecting that the update exists, building the app and going to sign everything at their air-gapped signing computer).
Now a lot of apps use the "reproducible builds" feature, which means that F-Droid will distribuite them as they come from the author, leaving its digital signature; but they still need to build them before distributing them, to verify that what the author built corresponds to the declared source code.
With the much powerful servers that they've had for a few months builds are a lot quicker, but there are still steps that can take several days, especially the part of signing the apps' index on their air-gapped computer.
There's a ton of things that could be improved, and it would be best if there were an alternative with better maintainers, but they're currently the only service of this kind for Android (well, IzzyOnDroid is a partial alternative, if you're careful to check their reproducible builds results).
You're sure you understand what it does?
I very much prefer Obtainium these days despite the setup steps. I don't think it's a coincidence that Obtainium, Aurora, Zapstore, etc. are gaining mindshare over F-Droid, just like how Brave has explosive growth over FF.
We search for stuff, install it, it updates in the background. We install some of our own repos, but the bulk of our apps come from F-Droid's default repos.
Hard to reconcile your account with my experience without specifics.
https://github.com/rumboalla/apkupdater
though personally I use it only for Fdroid, Gitlab and Github
And yeah the iris scans sound like a scare but only 2 years ago there was a constant line of zombies here in the shopping mall giving their eye scans to altman.
The masses really don't care about privacy if you give them a worthless trinket.
I use it on a phone with (unfortunately) regular google play services. If I sign into the play store, that same account will be used for all other google services on the phone too. I'm not going to do that. I just don't want a google account (nor an apple one for that matter)
For example the eBay app. Does not allow installing from the play store on grapheneos.
Like my personal phone?)
Installing Google Play service is in itself a privacy downgrade.
That isn't completely possible these days. Last I checked they want an existing email address and/or a cellphone number for verification. I guess "not tied to anything else" is proportional to how much you trust them to delete either of these bits of info after they are used, and not associate them with other accounts you might have used them with in the past/future.
How can I get this wonderful thing?
Braindead dev claims this is to limit the "piracy" and bug reports, nevertheless it's either Aurora or APKMirror.
I dare you try creating a Google account that isn't tied to anything else.
Nowadays you can't even create an account in desktop browser without first having to scan a qr code from a mobile device first.
WTF?
GrapheneOS uses Pixels because those are still the only Android devices with reasonable security including decent updates, working encryption for users without a strong passphrase and the hardware functionality usable to provide decent exploit protection. GrapheneOS is in the process of adding support for upcoming Motorola devices meeting the official requirements.
Maybe in the future you'll recommend other phones, so it'll be less bad, but for now - you've verified that the "inaccurate statements"
Pixels are currently the only devices providing the updates and security features listed at https://grapheneos.org/faq#future-devices. GrapheneOS has an official partnership with Motorola where their devices are being improved to meet these requirements and provide official GrapheneOS support. We're actively working on it with them. We've reported vulnerabilities, weaknesses and made feature proposals to Google for Pixels but they certainly haven't directly helped us or supported us.
Aurora Store still works fine. It doesn't require the default-enabled account sharing feature. It's not Aurora Store which is getting blocked but rather account sharing. Account sharing is against Google's terms of use and is now being detected more aggressively. We've warned about this for years but it took longer than expect for them to ramp up banning it. It's likely going to continue getting stricter.
Not that it requires Google to "open up" their play-store, but that they must allow other app-stores to work on the same level. So basically allowing devs and users to move elsewhere.
Apple moved first with making a special 'sideloading' case for apps not under their control, Google is just copying what they did.
No more free sideloading.
I think the increased popularity of GOS is going to draw in more users like me who picked it for reasons adjacent to Graphene's original purpose, and I hope it's not too annoying for their community.
I think it's fine the mission of the project isn't directly aligned with some of us, though I can tell we often get on the core contributor's nerves lol
No one has been banned from our chat rooms for mentioning F-Droid. That's a completely fabricated claim easily disproven with a search. There are a massive number of discussions about it where people often disagree about it.
Far, far too "opinionated" for my taste. I frankly do not need the hyper paranoid security features like a hardened memory allocator or disabled root. I would rather be able to use my device the way I want, even if that's notionally "less secure".
I really wish there were another option. Lineage is too far in the opposite direction and feels like ad-blocked stock. Google still owns my phone, there's just a more pleasant coat of paint on it.
> disabled root
ah yes
I get the part about disabled root - you're choosing to sacrifice freedom for security - though I don't understand why you wouldn't want a hardened memory allocator. It provides additional security over the stock OS for very little cost (slightly more resource consumption), in an era where we absolutely need as much security as we can get; what are you losing by gaining this?
For example, let's say hypothetically I want to be secure against the threat of Google pushing a targeted update to my phone that runs malicious code. Turning on automatic software updates from Google would make me vulnerable to that threat. Using MicroG instead of Google Play Services would make me less vulnerable to that threat. But Graphene devs say things like "MicroG is less secure than Google Play Services".
Similarly, if you want privacy you might secure your device by locking the bootloader with your own keys - not a third-party vendor's keys. Saying that's "insecure" is extremely misleading: it just puts you in charge of security, instead of abdicating to someone else.
I wish there were something like GrapheneOS that let you choose, yourself, who to trust instead of requiring you trust an OS vendor implicitly.
It is. microG runs Google DroidGuard blobs in a privileged process (to pass Play Integrity Basic). Reminder for those who forgot about DroidGuard: it's an obfuscated binary blob delivered to you by Google on each request that uses a special VM with constantly changing registers, etc. to avoid analysis.
On GrapheneOS that crap runs in a sandbox.
You're missing my point here, which is that failing to describe a particular threat scenario leads to meaningless words spoken about ill-defined "security". Security has to be against some particular threat... it's not an absolute concept.
There's plenty of people like that in the GOS community (the forum and the Matrix). Everyone generally understands that different people have different threat models and may want to do things that aren't the most secure. Otherwise everyone would be using GOS in airplane mode with disabled cameras and only paying for things with Monero.
The core dev team is obviously a bit more security absolutist, but even they usually dont mind
Citation needed. If there are such people in what can be considered a grapheneos community that haven't gotten fed up yet and left, grapheneos themselves sure doesn't understand this
> Otherwise everyone would be using GOS in airplane mode with disabled cameras and only paying for things with Monero.
Nah, they're fine with tracking, so long as it happens in their sandbox. The official website has an install guide for google's background services, saying it's fine because it's in their security model. So long as the modem and camera firmware can't access your contacts, there is no tracking in baghdad
The GrapheneOS team understand full well that in cases where the Play Store does not allow installing an app on your device due to device or georestrictive rules you may have no choice. I have seen them mention this and acknowledge it first hand. What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want instead of being a substitution attack risk. I don't think that is unreasonable.
>The official website has an install guide for google's background services, saying it's fine because it's in their security model.
The context is that before sandboxed-play-services were introduced people were sourcing APKs in unsafe/via unverified routes and having all sorts of problems with app compatibility because since GrapheneOS is a privacy project that do not accept sending copious amounts of data to one party with a mediocre privacy policy they included no Google services at all. sandboxed-play-services is a specific solution to the problem of apps being dependent on Google Mobile Services for functionality, and in that sense it is entirely optional. It was the best way for them to provide compatibility without destroying the privacy of their platform by introducing a privileged Google binary that can glean and abuse your production environment. It's reduced to the same level as any other app the user might choose to install themselves (which GrapheneOS want absolutely no say over as a user freedom protecting project).
GrapheneOS do not bundle any Google services in their official installation. They do not endorse Google's data collection and service practices. They do not believe Google tracking is fine in anyway, and the evidence is here: https://eylenburg.github.io/android_comparison.htm What they have done is provide a workaround for people who have no alternative, while making sure it does not violate the device owners device in a special way compared to any other app they might install.
Aurora is a lot less invasive while achieving that same goal, but they recommend installing Googleware instead. Wouldn't the open source front-end be the "bare minimum" standard to strive for, with all the added tracking when installing GMS falling below that standard?
> It was the best way for them to provide compatibility without destroying the privacy of their platform
Again mixing up threat models and equating it to privacy. It may not compromise the technical security (as GrapheneOS goes to incredible lengths to point out while implying that this covers everything), in that it doesn't allow Google to access data on the device that Android's security model says they shouldn't have, but Android's security model isn't my threat model. My threat model, and many other people's, includes Google tracking me. If nothing else, it can always see which IP addresses I pop up on together with other people and build a social graph if they wish (or if they're ordered to)
By just grabbing the apk files from their servers whenever I open aurora.apk, that issue can be almost entirely avoided, for example. There's the matter of microG but just to show that there are easy wins to be made that work for a lot of apps already that GrapheneOS vehemently opposes 'for security'
It's not strange that they offer a way to install GMS in a secure manner, it's strange that they don't recommend open alternatives where possible
And you're surely aware of the obvious bias of that link you shared. It's like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. And that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one could outweigh all others
It's more accurate to say they suggest improvements not vehemently oppose. The community/project have opened issues with the Aurora Store project to get them closer to that goal of making sure the app downloads cannot be intercepted https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/697 and mitigating the TOFU problem by ensuring the first install is definitely the one the developer distributed via Play https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/1177 This is what I meant by standards. They only suggest Play Store because it is an existing solution that already meets those standards.
>Again mixing up threat models and equating it to privacy. My threat model, and many other people's, includes Google tracking me.
GrapheneOS are very conscious of avoiding sending data to Google where unnecessary. The evidence of that is in the link previously shared, but also in third-party reviews like https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter... They also do advise that if you want to avoid Google's gaze you should explore non-Play Store apps if they can meet all your needs because Play Store apps are extremely likely to include Google libraries and dependencies that expose even more data to Google. Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store. I believe that from their perspective it takes a lot of careful consideration and planning to avoid exposing data to Google. This consideration and planning would never end with just Aurora Store so hopefully you can understand why they would not recommend it as a well thread-modelled privacy solution for Google. Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically. Does my explanation make sense?
>... like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. ...that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one can outweigh all others
I agree. Checklists are a bad way of conveying verified information and importance of each feature, and I do think the table can be improved. Thankfully it is open to contributions from Github account owners.
The second ticket is about checking if the data that Google sent via TLS has a second signature from Google. It doesn't prove what you claim about ensuring the key is from the developers. This is more useful for places like apkmirror that distribute apps and could include the signature that Google tacked on, for people who trust but cannot use Google; to verify Google's signature without needing to be able to connect to Google. That's not what Aurora does, so it's not relevant to the project. Can be defense-in-depth in case Google's front-ends are compromised but the signing back-end is not, but again, that's less likely than getting struck by lightning and such a powerful attacker could also just compel the developers to make a special update that performs malicious actions on their target
This is the level of misunderstanding that I find very common among GrapheneOS users btw: it all sounds good if you don't know much about it, but when you drill down to what it actually does and consider a specific threat model, it's no reason to recommend Google Play over Aurora for 99% of people's threat models. If you're an oppressed journalist in Iran or whistleblower in the USA, then the cert pinning could help, but most of us are more impacted by everyday tracking than by targeted nation state attacks
> Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store.
I'm probably misunderstanding you, but nobody said downloading an app via Aurora changes the contents of the download to become privacy-friendly. Like, downloading a .exe via an open source browser also doesn't change the download compared to if you download it with Google Chrome
You still have to be wary of what you download, deny it internet access if applicable, etc. It's just that you don't have to have google's stuff running in the background all the time, toggling internet access on (letting it upload queued telemetry) anytime you want to download or update an app that is distributed only via google
Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
> Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically.
What do you mean by nonsensically? I didn't know they recommend it under any circumstance though, that's cool. Do you happen to have a link for that, or remember where they wrote that?
https://github.com/flawedworld for example as part of GrapheneOS organisation and has interviewed for GrapheneOS in the past (https://www.youtube.com/watch?v=WkQ_OCzuLNg).
>preventing basically nation state attackers who either compromise or compel a CA
I don't think the compromising, self-compromise or compelling of a Certificate Authority is a feat reserved for state-level attackers. I am not sure why it would exclude any malware that gains enough privileges, or existing campus-enterprise mobility management apps/parental control/antivirus that get compromised or hijacked. But really it comes back to one of the original points which was that GrapheneOS are comfortable recommending and promoting solutions with a high level of security/privacy as a general rule.
>The second ticket
Yeah, I believe I confused the 'frosting metadata' part with the important whole APK Signing Block. The part I wanted which the app store client should verify would be the signing certificate hash which you compare to what the server says the package should give you. As far as TOFU mainstream users basically trust in Google's Play Security & reviews process instead of developer signing certificates/keys because most developers do not publish that out-of-band somewhere they individually control. Widget on Dev's Socials/Site + Publishing hurdles + Developer Console auth + Google security/review add up to a non-zero chance the listing is good. When you get the app you have the benefit of certificate pinning and app signature verification to make sure that non-zero isn't majorly reduced in distribution/transit.
GrapheneOS don't even recommend getting apps from Play anyway if you can verify and source the apps directly from the developer.
>very common among GrapheneOS users btw
Can't say anything for your experiences, but of course I only speak for myself. I can say though that the GrapheneOS developers themselves will never tell you the OS is specifically for high-risk oppressed journalists and whistle-blowers. Another big disconnect is that GrapheneOS believe things need to be much more attack/abuse-resistant for the 99% than they are now, so asking them to aim a little lower than current standards will cause a lot of misunderstandings: https://xcancel.com/GrapheneOS/status/2044440381803069778#m
>You still have to be wary of what you download, deny it internet access if applicable, etc. Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
I agree mostly with this, but I think you can see it would be a bit painful and tedious for GrapheneOS to say "We can't endorse violating Google's TOS but Aurora Store is an option under specific circumstances and technical conditions. Apps from Play/Aurora may not contain any Google libraries, GMS dependencies or involve sending data to Google as potentially stated in their privacy policy but there is no accessible way to determine this per-app at a glance." every time they need to talk about Aurora Store.
>Do you happen to have a link for that, or remember where they wrote that?
Recent examples: https://xcancel.com/GrapheneOS/status/2093353794247467344#m https://news.ycombinator.com/item?id=49548219
Their absolutist of their own view of security
I don't see the word "privacy" in that sentence though.
Have you looked for help? It sure isn't because of any Google component being disabled
today I bothered to try various anonymous Aurora accounts and found finally the one working (like 5th in row) and updated the apps, I can live with updates once a week, not exactly sure what is OP doing
I mean if they are really rate limited just give me waiting time, I don't really care whether I have to wait in queue for an hour if it will update the app later without my intervention
btw. I am not using graphene, find it too paranoid for my taste, though I use my phone without google account for like 10+ years and current phone is first where I have (not disabled/have preinstalled) google play services
Aurora hasn't worked right for the most part for a year due to device attestation shit.
I'm meh on it. Not being able to install the shit from play store isn't such a bad thing. It is lame as hell that Google is doing their damndest to make apple look user friendly.
Not news nor "blocking".
Honest question, because AFAIK there's no guarantee or (legal) requirement to support any API. Whether that's fully documented, has SDKs or whether it's something reversed-engineered doesn't matter WRT the support the company owning the API is supposed or required to give.
Or am I wrong there?
It affects using Aurora Store "anonymously" because that means using shared accounts, so far higher activity per account.
It's possible they're also detecting contemporary usage of the same account.
But there's a slight chance that it's just due to someone abusing the accounts outside Aurora Store.
This seems like it was destined to get banned somehow... and I don't think it means that the store itself is blocked, just the pool of accounts they (ab)use.
Good times, good times.
The window to have a real open mobile OS is starting to close. If there is to be a meaningful change, it must happen soon.
https://grapheneos.org/install/web
It's a shame that there is no official way to install apps on android without a google accout[1], since it's a basic functionality, just like calls or a web browser.
[1] For obvious reasons I don't want her to download apks from the internet.
Grandma doesn’t care if it looks like an update or not.
https://www.whatsapp.com/download
It's the app publishers defaulting to Google that's the biggest issue.
At least WhatsApp has an official APK download, most apps don't.
That said, Google will still let you update apps without being signed in. Hold the Play Store icon to open the quick action menu. From there you can go to "my apps" and update all of the apps on your phone, bypassing the login prompt. Not great, but a workaround that should do the trick while Aurora finds another way to hack their way into the Play Store APIs.
Mistake from me: apparently GrapheneOS does not recommend Aurora Store (citation needed). Kind of weird though; it means Google still knows a lot about you, which doesn't seem very privacy conscience.
Google blocking Aurora Store was a conclusion made in the bug thread. It was not my conclusion.
And for the nit pickers: Sailfish OS is not Android, but its emulation layer _is_. :shrug: Even though Sailfish is nice, without its Android layer it is practically unusable.
Funny thing: the 'busy server' problem existed for almost a week. I could download 1 app per day max on my Jolla C2. But just now, now that this thread makes top of Hackernews, everything started working just fine!
I remember being in the GrapheneOS room and hearing them directly recommend using Windows 10 over Linux, as it was more secure. They are known to prioritize security over privacy.
See the "degoogling" section.
There's many privacy features that work to allow users to use anti-privacy apps like WhatsApp with more privacy. Contact scopes, storage scopes, sensors permission, network permission, VPN leaks fixed and enhanced secondary profiles.
Plenty of less scrupulous surveillance companies like Facebook take advantage of security flaws for their surveillance so it's important to start from a secure baseline to guard against this threat.
Aurora Store still works fine. It doesn't require the default-enabled account sharing feature. It's not Aurora Store which is getting blocked but rather account sharing. Account sharing is against Google's terms of use and is now being detected more aggressively. We've warned about this for years but it took longer than expect for them to ramp up banning it. It's likely going to continue getting stricter.
Aurora Store isn't one of the main recommendations from GrapheneOS for obtaining apps. It's mainly useful as a workaround for installing Play Store apps requiring the device or strong integrity level for their Play Store listing. It would be better to find another way to deal with this.
Try and find a category for "open source" apps on any app store.