bookreader there are instructions on how to build GrapheneOS yourself. Also, you can set up your own releases server as well as apps repository. Everything is open source so you can just copy everything. Anyone with time and the skills required can do it.
For the official builds, I think the options make sense. Most of the connections go through the owner VPN.
other8026 Perhaps nothing wrong with the servers now, from the point of view of being compromised, but how about tomorrow or 6 months from now.
I'm also not arguing for my needs, I'm trying to clarify the positions being presented in this thread.
bookreader I'm also not arguing for my needs, I'm trying to clarify the positions being presented in this thread.
I'm not replying to you in specifics, but I'm using your quote to bring up very important point (well from my point of view):
At some point in your privacy journey, whoever you may be, you will have to make some decisions based on trust. In this case GrapheneOS.
And then just let it be, and get on with your life.
Not saying I can't understand it, well in this case I really can't, but I have my own "braindamage" topics so in a certain way I can... 😅
bookreader I think its obvious that somebody would have to maintain those servers.
I suspect anybody who has the skills to set up the infrastructure and the funding to pay for the server(s) can also build GrapheneOS from source and change the built-in server selectors to the desired values. Signing the builds would mean that if, hypothetically, the GrapheneOS project were compromised, the devices running the custom build would get only system images built and signed by the entity doing the builds and signing, not the hypothetically compromised project.
bookreader Basically what is being asked for isn't just "google"/"grapheneos"/"disabled", but rather also add a "custom" option. From the top of my head, connectivity check, gps, updater.
That could be done, and it's possible that a pull request implementing that would be accepted. But the situation is not like the situation for a custom DNS resolver, where there are tens or hundreds of candidates that GrapheneOS users might wish to select among. At present there are not many SUPL proxies (maybe just Google's and GrapheneOS's?), and at present there is one GrapheneOS system image update server.
Meanwhile, if it is possible for users to plug in arbitrary values, some will plug in a wrong value, raising the support load. As long as there is only one "right answer" for 99.9% of users, a situation in which the 0.1% select a custom server by doing a build might be the right tradeoff for the project team.
Please note that I do not speak for the GrapheneOS project.
bookreader I'm also not arguing for my needs, I'm trying to clarify the positions being presented in this thread.
I'm not sure I follow here. OP's question was answered. Looking at the history, it was you who started talking about governments taking over servers and saying you were concerned about the location of GrapheneOS's servers. So, it seems that you're really trying to clarify your position, not the "positions being presented in this thread."
bookreader Perhaps nothing wrong with the servers now, from the point of view of being compromised, but how about tomorrow or 6 months from now.
I really don't see what the issue is here. I'd suggest you review what servers are hosted by GrapheneOS and what they do. The OS doesn't blindly trust the servers. Here are a couple quotes from the website:
The update client avoids trusting the data obtained from the update server via signature verification with downgrade protection. Verified boot provides another layer of signature verification with downgrade protection. GrapheneOS servers do not have access to GrapheneOS signing keys.
The update server isn't a trusted party since updates are signed and verified along with downgrade attacks being prevented.
Apps are also signed, so no reason to worry there either.
The remaining servers are mostly either proxies (so can't mess with those) or what are essentially headers returned from a web server.
bookreader The default connections FAQ explains that all of the connections other than connectivity checks go through the Owner user VPN. Use a VPN provider you trust and set the connectivity checks to Standard so that you won't appear as a GrapheneOS user on the local network or to your ISP.
bookreader OS releases along with app repository metadata and the apps themselves are signed with downgrade protection. An attacker who compromises the servers can't serve malicious updates to users. Every router along the way from your device to the servers can see the source IP and destination IP for each packet. If you want to hide this from your local network and ISP, you need a VPN. If your device connects to a self-hosted server, you'll be uniquely identifying yourself through that which is the opposite of obtaining more privacy. Self-hosting these servers or using an incredibly niche one hosted by someone else would be reducing your privacy not improving it. Use a VPN and stop trying to accomplish what a VPN provides through this.
865be553dc4f5b2b GrapheneOS is an international project. It currently has 7 full time developers and only 1 of those 7 developers is based in Canada. The project itself is not based in any specific place. GrapheneOS Foundation provides a legal entity to support and defend the project, but it is not the open source project itself. A main purpose of the GrapheneOS Foundation is to shield the project members from attacks and move legal liability to an organization. The project existed from late 2014 until March 2023 without this non-profit organization and would continue existing without it. We can form non-profits in other countries too if we decide that would provide value to us, but managing one of them is already going to be a lot of work so we aren't currently planning to do that.
GrapheneOS Use a VPN provider you trust and set the connectivity checks to Standard so that you won't appear as a GrapheneOS user on the local network or to your ISP
So besides privacy benefits, the project recommend a VPN to hide the fact that GrapheneOS is being used?🤔
bookreader Perhaps nothing wrong with the servers now, from the point of view of being compromised, but how about tomorrow or 6 months from now.
These servers are almost all KVM (virtual server). These large hosters have data centers in several continents. It only takes a few minutes to move a KVM (Backup image) to another server in a different data center.
FlipSid If you want to hide that GrapheneOS is being used, you should use a VPN and set connectivity checks to the Standard mode using Google servers. The Disabled mode will indicate that you're using a non-standard Android device, although not specifically that it's GrapheneOS. All of the default connections other than connectivity checks go through the VPN including app updates, OS updates, HTTPS network time, PSDS, SUPL, attestation key provisioning and widevine key provisioning. We recommend leaving all the other connections using GrapheneOS servers and instead using a VPN to mask that you're using it.
GrapheneOS you'll be uniquely identifying yourself through that which is the opposite of obtaining more privacy
It doesn't matter if I can be identified, it matters if I can be CATEGORIZED. If GrapheneOS is deemed by some government to be a terrorist organization for providing protection against government monitoring, then users of GrapheneOS may be deemed terrorists.
VPNs can fall into the same category, so really aren't solving anything.
boldsuck These servers are almost all KVM (virtual server).
Who cares? If the person who would be moving them is thrown in PRISON, then they aren't moving anywhere.
@GrapheneOS I understood your point about the non-profit entity, but are there any plans in the future to install an oversight board that would work like an independent arbiter over developers? That might put a lot of minds to ease in my view. The idea is that developers have all the technical expertise, but the project needs a human face as well that handles amongst other things situations where a certain developer (or half of them) goes rogue. So far the project is not that big, but when it grows later, it cannot just rely on developers to handle all the matters like trust, communications, PR.
865be553dc4f5b2b So far the project is not that big, but when it grows later, it cannot just rely on developers to handle all the matters like trust, communications, PR.
I am personally not aware of research comparing the governance structures of various open-source organizations against their longevity, size of user base, etc. I don't know how large or how long-lived a "developers running the show" organization can be, and I also don't know what the failure rate might be for large "oversight board" organizations. Maybe somebody else has data?
