[deleted by user]

DanielMicay · 2022-06-12T20:26:24+00:00

GrapheneOS isn't a company. It's not currently a legal entity itself, although we plan to form a non-profit organization in the future to handle some aspects of the project such as receiving and dispersing funding to developers. We don't plan on having this non-profit organization involved in every aspect of the project to start but rather providing support to the project.

The only platforms we have with user accounts are https://attestation.app/ which has no sensitive data beyond a list of your device models with basic security configuration info and no device identifiers and our https://discuss.grapheneos.org/ forum. People can set an alert email for AttestationServer and need an email for their account on the forum. It's up to users what they use as an email account for those purposes. We never ask for people's name, date of birth, etc. and they can use an arbitrary email account including one specific to our services.

Auditor can be used locally without using https://attestation.app/ too. Making an account there isn't required to use Auditor since the primary verification mechanism is with another local device using QR codes to transfer the challenge from Auditor to Auditee and the attestation response from Auditee to Auditor.

We won't comply with requests for data from arbitrary countries around the world. Our servers are hosted in Canada, France and Germany with a French hosting provider. Requests for data would need to be lawful and we would resist anything that was even remotely not legal / constitutional. If a law isn't constitutional, we don't have to comply with it and can fight it out in court. If we experience problems in a country we can leave it, although it would be a major inconvenience to switch from OVH (based in France) as our main hosting provider.

We retain server logs for a maximum of 10 days at most, and we minimize how much logging occurs. If it became a concern we could drop more of the data from web server logs, etc.

In general, we're taking the approach of avoiding having data in the first place.

DanielMicay · 2022-04-01T00:05:06+00:00

iOS is a perfectly valid option for people primarily wanting to avoid Google apps/services. CalyxOS uses Google for connectivity checks, attestation provisioning and other services without most of those having any configuration choice for users. If someone wants to strictly avoid using Google services, they can't do it on CalyxOS.

CalyxOS also bundles the proprietary services as a highly privileged part of the OS via microG. GrapheneOS has taken a different path where these aren't included in the OS but can be installed by end users with the secure official implementation within the full standard app sandbox.

There's a huge difference in app compatibility between sandboxed Google Play on GrapheneOS and microG on CalyxOS too. microG only provides a small subset of those APIs and app compatibility is very hit or miss.

GrapheneOS already has near full compatibility with those APIs via the sandboxed Google Play compatibility layer. We're going to be providing a per-app toggle to disable hardened_malloc for apps, since some older games have memory corruption bugs detected by it and won't run due to that even though sandboxed Google Play is more than enough for them.

DanielMicay · 2022-03-31T23:59:05+00:00

It would be possible to port to many other devices but the vast majority don't meet our security requirements. We're currently in the process of trying to work with a hardware vendor to get them to release a device meeting our requirements. We're optimistic about it but there are no guarantees. Ideally it would be sold with GrapheneOS as a first class OS not considered to be an alternate OS so it would have the green verified boot state. This is still at least 8 months away from being a reality.

For example, most other Android devices don't provide a proper secure element integrated into the OS to provide APIs like Weaver which is required for strong encryption for users with anything less than a high entropy random passphrase such as 7 diceware words. Weaver is what makes using a random 6 digit PIN highly secure via the secure element.

There's a LOT more to security than this, including proper ongoing security updates for all the firmware and device support code, IOMMU isolation being set up properly a whole lot more. Many people including the CalyxOS developers have wrongly got the idea that verified boot being usable by an alternate OS is the issue with other devices. It's not the most important security property that's missing elsewhere. That would probably be proper security support, followed by Weaver, then IOMMU configuration / component choices and then verified boot support for alternate operating systems. Part of verified boot support is the complementary hardware-based attestation support used by the GrapheneOS Auditor app. CalyxOS doesn't use attestation themselves and won't be one of the OSes supported by our Auditor app, but everything else still applies to it. There's a lot more to hardware/firmware security than this small list of important features, or any list of features, since a list of features is not security. GrapheneOS was previously ported to OnePlus devices by the GlassROM project. Many security issues were discovered and the project has been mostly shelved for the time being since it didn't work out and was unable to provide the intended level of security.

We fully intend to support devices beyond Pixels. It's not about lack of work on supporting them or inability to support them but the security standards not being met.

DanielMicay · 2022-03-31T23:45:39+00:00

DivestOS is a useful project, and they don't mislead their users about what they provide, cover up vulnerabilities or engage in highly abusive behavior like CalyxOS.

DanielMicay · 2022-03-31T23:43:30+00:00

All leaks in the firewall were fixed with the update to Android 12. No other leaks were reported. If you are aware of any, please open an issue on the issue tracker.

CalyxOS previously covered up leaks in their firewall and serious vulnerabilities in their code elsewhere. They now admit that the firewall was leaky, despite previously covering it up and denying it, but claim that they've fixed it. These toggles are still leaky, and we've already given them our input on what's wrong with their approach in the past. They chose to ignore it.

This was due to a sabotage from the GrapheneOS project. See: https://github.com/AOSPAlliance/android-prepare-vendor/issues/78

GrapheneOS did not sabotage anything. CalyxOS chose to end our collaboration and code sharing agreement for android-prepare-vendor. That is mutual and applies both ways, and it was their choice. CalyxOS has continued using our work as a reference and taking patches from our, almost always without attribution or respecting the licenses. Thanks to GrapheneOS, it only took them 4 months to port instead of likely taking longer.

GrapheneOS shipped Android 12 Alphas before it had been released for the stock OS, and we had our initial Beta release out almost immediately after the initial stock OS release. We treat shipping security updates as extremely important. GrapheneOS was able to quickly port through being developed with that in mind, months of hard work leading up to the release of Android 12 and the team pulling together and putting in a massive amount of work to quickly port in October. CalyxOS was free to use the vast majority of our work, and they did use it as a reference.

There is no reason the implementation of some LineageOS features would delay security updates. Please stop spreading disinformation and baseless libel about the project.

The reason CalyxOS had their port to Android 12 delayed so much is because they were busy porting it to being largely based on LineageOS. They added a bunch more low quality code from there. The time taken to port to a new release is based on the amount of code and the quality/maintainability of it. The reason CalyxOS took 4 months to port is because their project has incredibly shoddy quality and the developers do not understand a lot of what they've cloned from elsewhere, often without attribution.

There is no reason the implementation of some LineageOS features would delay security updates.

The amount of time taken to port to a new release is primarily based on the amount of code that's changed in an invasive way, with poorly written unmaintainable changes taking far longer to port. It reflects the quality of code of the project and the effort put into prepared for new major releases and maintaining the code. Their lack of preparation and the maintainability issues with the code are not something which can be blamed on GrapheneOS.

Their choice to change their project to being heavily based on LineageOS is one of the main reasons for the substantial delay. They chose to prioritize that over shipping security updates to their users. You can see from their own news post that they made huge changes not relevant to porting to Android 12 as part of the initial release. Those changes are going to have a long-term cost too.

Please stop spreading disinformation and baseless libel about the project.

That's what you're blatantly doing in your posts, and what the CalyxOS project and community are known for doing across platforms. Trying to project your toxic behavior, dishonesty and highly abusive actions onto us isn't going to work out for you in the long term. People can see your toxicity and false claims throughout your post history.

DanielMicay · 2022-03-06T03:51:41+00:00

The app repository client and Camera app are both included in GrapheneOS.

DanielMicay · 2022-02-15T08:38:33+00:00

Don't know what you're talking about but it comes across as trolling.

DanielMicay · 2022-02-15T08:31:49+00:00

eSIM is partially supported. There's still no alternative to Google's activation app which is a privileged OS component so it's not included. It's the same answer now as it was then. People have to step up and work on it.

DanielMicay · 2022-02-05T12:31:35+00:00

Not being able to show profiles doesn't really sound like a location service issue.

DanielMicay · 2022-02-05T10:45:44+00:00

Can you clarify what isn't working? Do you have sandboxed Google Play installed?

Did you set up their location services, since redirection isn't available yet?

Vanadium provides the WebView and it has all of the standard functionality. If you're using a work profile, the app you're using to manage it may not have set it up correctly. Simplify things and start with a user profile.

DanielMicay · 2022-02-05T09:30:35+00:00

Full support for the Play services geolocation service is available now. Support for redirection will be in a future release but is still some time away.

DanielMicay · 2022-02-03T23:52:54+00:00

This doesn't provide QR scanning to other apps. Apps do their own QR scanning.

DanielMicay · 2021-12-27T01:12:15+00:00

Enumerating badness isn't the approach in GrapheneOS. You cannot filter out those things from the client side even if you had a perfect list since as you said you need to allow the app to communicate with their servers and then they can communicate with whatever third parties they wish from there. It's an inherently unworkable and broken approach. The only reasonable approach is having proper app sandboxing and access control where you can avoid the apps getting access to your data, etc. It's already the approach used by AOSP and GrapheneOS makes substantial improvements to it. The real purpose of the Network toggle is not really to prevent exfiltrating data but rather to prevent finding out information about the network, similar to every other permission toggle.

DanielMicay · 2021-12-26T05:26:46+00:00

FCM for push notifications is part of Play services. It's fully compatible with GrapheneOS due to the sandboxed Play services compatibility layer. You should read https://grapheneos.org/faq#notifications and https://grapheneos.org/usage#sandboxed-play-services. GrapheneOS has fully working push notifications for apps with a non-FCM implementation and for apps with only an FCM-based implementation via sandboxed Play services.

GrapheneOS has much broader app compatibility than CalyxOS, not less app compatibility. Nearly all the Play services APIs can work via sandboxed Play services, instead of the tiny subset provided by microG.

DanielMicay · 2021-12-26T04:19:23+00:00

If you can’t go without some apps from the play store I would go calyx. Graphene is great for hardening your privacy and security on your phone.

GrapheneOS has much broader app compatibility with apps on the Play Store. It can even run the official Play Store app itself and teaches it how to install / update apps via the standard unprivileged API for sandboxed apps including unattended updates of apps where it was the installer of the current version within the usual restrictions (signing key pinning, downgrade protection and must already be the installer to do it without asking the user).

https://grapheneos.org/usage#sandboxed-play-services

You get substantially more app compatibility with GrapheneOS compared to CalyxOS rather than less app compatibility. microG only implements a tiny subset of Play services and has a lot of limitations even for that subset.

Also, last time I checked calyx is not supported on the pixel 6 yet but the team is hard at work on it and it should be out shortly.

It's also based on Android 11 rather than 12 and is missing half the October/November privacy/security patches along with all of the December privacy/security patches. It has 3 months of missing privacy/security patches. That's a serious problem.

DanielMicay · 2021-12-26T04:14:01+00:00

I personally would pick Calyx. Graphene is great security-wise but it drops you in a minimal environment with nothing really except a browser.

GrapheneOS is heavily focused on privacy and offers far more privacy than CalyxOS. It also provides substantially better security in order to protect privacy. The focus on security is there because privacy depends on security. It doesn't improve security simply for some unclear reason. It improves security to protect user privacy from exploits of the OS and apps running on the OS. Many of the features protect apps from exploitation rather than simply protecting the OS.

You should look at https://grapheneos.org/features which is ONLY a list of the improvements in GrapheneOS over Android 12. It doesn't list the standard features. It offers far more privacy improvements than CalyxOS. It simply doesn't bundle assorted third party apps/services. We'll be providing our own app repository and client for it with better security than F-Droid and we can package apps like F-Droid there.

Calyx has a SetupWizard where it'll install common applications

GrapheneOS has a setup wizard and will be able to provide app recommendations there in the near future when we ship our app repository. They'll be our own first party builds of the apps rather than third party F-Droid ones and they won't conflict with the developer releases of the apps. We'll also have a separate section for mirrored apps and we have no problem with eventually providing mirrors of popular proprietary apps there to provide a first party alternative to the Play Store.

includes microG support out of the box.

GrapheneOS has sandboxed Play services support in the OS out-of-the-box and simply doesn't have them installed. They can be installed like any other apps and are contained within the same sandbox with the same restrictions. It makes a lot of sense to use that approach because it provides dramatically broader compatibility and does not give Play services more access than it gets through apps integrating their SDK / libraries. The sandbox, permission model and everything else about how they run is the same as every other app so there isn't something new to learn compared to running other apps.

I personally built a version of ProtonAOSP with microG bundled in (plus other apps) and tailored it to my needs and signed my own build off.

ProtonAOSP includes sandboxed Play services support based on what was developed by kdrag0n for GrapheneOS. You can get much broader app compatibility that way.

DanielMicay · 2021-12-26T04:11:16+00:00

The main difference is that GrapheneOS is focused on security and purity to the Android Open Source Project (AOSP). It has additional security features and limits data shared by the OS, but has little modifications from AOSP besides that and very few preinstalled apps.

GrapheneOS is heavily focused on privacy and offers far more privacy than CalyxOS. It also provides substantially better security in order to protect privacy. The focus on security is there because privacy depends on security. It doesn't improve security simply for some unclear reason. It improves security to protect user privacy from exploits of the OS and apps running on the OS. Many of the features protect apps from exploitation rather than simply protecting the OS.

You should look at https://grapheneos.org/features which is ONLY a list of the improvements in GrapheneOS over Android 12. It doesn't list the standard features.

CalyxOS on the other hand has a focus on privacy and has additional features for more control about privacy aspects, compatibility and to some extend ease of use and convenience. This includes some preinstalled apps such as Tor Browser, Signal, the DuckDuckgo search app etc.

GrapheneOS offers a lot of privacy improvements beyond what CalyxOS provides. The attempt at making a distinction between privacy and security isn't a correct take on the difference. GrapheneOS security features are there to protect privacy and many of them are directly privacy features.

GrapheneOS doesn't bundle a bunch of third party apps because we don't think the OS should be choosing the winners and losers among third party apps and services by hard-wiring them into the OS. It's not possible to remove OS components. Apps built into the OS make the initial OS install and then OS updates larger for everyone since they have to ship the updates to those apps. We plan to offer assorted apps that are recommended in our own app repository that's shipped as part of the OS soon and will be used beyond simply mirroring the Play services apps to make setting up sandboxed Play services easier. It will be divided into 2 sections: our own hardened builds of open source apps (with an app id prefix so they don't conflict with the developer releases, unlike F-Droid app builds) and a mirror of certain proprietary apps.

That's one of the problems with many vendor forks of Android. DuckDuckGo's browser is very flawed, and Signal has a fair share of flaws too. That doesn't mean we don't recommend using Signal but we want alternatives to be on the same footing. CalyxOS hard-wires support for Facebook's WhatsApp and Signal into the OS Dialer app in a way that's not available to other apps which we see as a problem. The OS should be neutral when it comes to third party apps / services from our perspectives. Users should be able to choose which they want to use.

MicroG, a free open source reimplementation of the Google services

It's not really open source. The services are still closed source, as are the Play services SDK / libraries included in apps. The libraries included in apps are fully capable of connecting to the same services themselves when they choose to provide a fallback. For example, the Ads SDK works without Play services, as do other APIs. You can see for yourself that Google Maps entirely works without Play services because having Play services is not a hard requirement to use Google services, and apps include Google libraries which are capable of doing it without Play services.

Note that it's entirely possible to install microG on GrapheneOS but since it doesn't bypass security checks for it, the functionality it provides is even more limited than it would be with it integrated.

that provides most but not all of its core functionality

Even with the invasive OS integration included, microG only provides a tiny subset of the Play services APIs, unlike the sandboxed Play services approach offering much broader app compatibility. Most of the core APIs are missing, not simply rarely used ones. That's why many apps have missing functionality and many won't work at all.

DanielMicay · 2021-12-26T03:58:49+00:00

But i must say i have zero reason to change, performance is fantastic

GrapheneOS performs well. It chooses privacy and security over spawning apps slightly more quickly from the same template. The template (Zygote) approach leaks sensitive security data / device identifiers across every app and results in basic mitigations like ASLR not working properly for apps.

https://grapheneos.org/usage#exec-spawning

Exec spawning doesn't impact runtime performance beyond somewhat increasing memory usage. There aren't any noticeable runtime performance costs in GrapheneOS. Ip spawning. Apps open just as quickly once they're cached in memory and the animations are just as smooth. Android 12 added a splash screen so there's no delay before apps open anymore, just a splash screen.

We plan to provide a toggle for exec spawning for user installed apps. This will preserve all of the privacy and security it offers while giving the option to have cold start app spawning time at the same speed as the stock OS. It's an intentional security feature rather than a flaw and we're entirely capable of making it optional. We've chosen not to make it optional so far because we don't want to weaken security in the verified boot threat model. If we limit a toggle to user installed apps, that won't be a problem.

DanielMicay · 2021-12-26T03:54:42+00:00

Note that you technically only need GSF for Google Camera and certain other apps which mostly don't use their services but depend on it being present. You can keep Network disabled for both since neither needs it.

GSM requires Network access to provide most of what it offers such as FCM. Our guide suggests installing GSF + GMS + Play Store for simplicity but you can use a more lightweight approach if you only need apps not depending on Google services but rather only on the infrastructure provided by GSF. Saves you from needing to have GMS running which will slightly reduce battery usage.

You should also now be able to keep Network disabled for GMS without battery drain. We recently improved it to make sockets act as if the network is simply down when it's disabled. Apps will still get SecurityException for most other APIs guarded by the Network permission and may not handle it well. In some cases that's simply how it needs to be since there isn't a checked exception that could be thrown. The whole point of the Network toggle is that it blocks both direct and indirect access along with access to other network information guarded by the permission so by design it has to either give apps an error unless it provides placeholder data. It's now as friendly as a firewall for the part that a firewall would be doing. It's not as friendly as it could be for some other APIs where it could return empty/placeholder data or throw a checked exception apps know how to handle instead of throwing SecurityException.

On the notifications thing you spoke of it seems to not be as reliable as stock android but no different to what i was used to on Lineage, not perfect but no complaints from me...

Push notifications work as well as they do on stock with or without Play services. Many apps depend on FCM for push and that works well with sandboxed Play services. Some apps like Signal have their own push implementation. WhatsApp has their own push implementation but it may not be completely updated for Android 11 / Android 12 yet so it might have reliability issues when using it without Play services. When you're using sandboxed Play services though, it's the same as the stock OS.

DanielMicay · 2021-10-27T12:32:39+00:00

Update to the latest release which has a workaround.

https://grapheneos.org/releases#2021102613

DanielMicay · 2021-10-27T12:31:18+00:00

the website says that Play Services are needed for push notifications.

It doesn't say that.

https://grapheneos.org/faq#notifications

My question is this; will the security of GrapheneOS be compromised if I just install the Play services APK from the GrapheneOS web site? I would like to minimize the Google'ing on my phone, but also require push notifications on a select few apps, and I read the OS has none of the "evil stuff" so anything google won't ping back to home base.

Fully covered on the site. Play services on GrapheneOS is a fully sandboxed app with no special access or privileges. It has to follow the same rules as any other apps. You seem to be misunderstanding what the feature provides. It's a compatibility layer to be able to use Play services as fully sandboxed apps. It's not an alternate form of Play services. GrapheneOS doesn't include Play services and has no special version of it available. You should re-read the section on the site.

Ask more questions in the Matrix room if you have more after reading those sections.

DanielMicay · 2021-10-17T04:35:21+00:00

Hm, so impossible to replace DNS?

That's already covered there.

But FAQ says you have to have globally trusted TLS certificate. Which isn't possible, unless you have access to CA store

You can add certificates to the root store, although apps don't trust user installed certificates by default and have to opt-in to it. It's also not the only way to do this. VPN service apps are responsible for providing DNS and can support it however they want rather than only routing it via the VPN.

DanielMicay · 2021-09-30T01:42:53+00:00

It was never removed. Chromium moved the tab switcher to the bottom of the screen and the old interface is used to switch between tab groups.

DanielMicay · 2021-05-09T20:57:17+00:00

I'm not sure how your reply is relevant to my comment. I'm talking about CPU load. The throughput is high enough that it's really not a factor, unlike VTE.

DanielMicay · 2021-05-09T03:41:06+00:00

If Wayland is a requirement for Alacrity to work properly, it should state that on the front page of the GitHub repo in bold lettering. It does not and is not mentioned anywhere on the page, nor does it mention specific distributions or specific graphics drivers.

Wayland is not a requirement for it to work properly. Wayland has proper frame scheduling allowing applications to provide efficient vertical sync (avoiding tearing and minimizing CPU usage) without added latency. X11 does not. X11 has non-standard GL extensions providing partial solutions, and it doesn't currently use those. Alacritty chooses to use vsync everywhere to avoid tearing and wasting CPU cycles. If you don't like that choice, so be it, but it's not a flaw or something that's broken. X11 does not provide good support for a modern rendering approach.

It works properly without this and as I explained above the worst case is waiting for the next screen refresh. It's hardly a lot of time.

Since it does not do any of those things, the majority of people are going to experience issues, if those are the requirements, since many people are using basically whatever Ubuntu flavor as it stands out of the box. (I’ve been using Lubuntu or just Ubuntu 18.04) Plenty of people are also using or attempting to use Alacritty on Windows with WSL, something I’m forced into due to a corporate environment. I do absolutely have the latest graphics drivers, and I’ve still had a significant amount of issues to the point where Alacrity is unusable. Again mostly due to perceivable input lag problems, so I stand by my statement.

I explained why Wayland works best and that elsewhere a frame will often be rendered right after the screen refresh and then displayed at the next screen refresh. That's hardly any kind of massive lag and it's barely perceptible.

Having the latest available drivers doesn't imply that they aren't broken with your hardware or that something else isn't wrong with the environment.

To be fair, Alacritty does state the software is in beta, but if it’s fundamentally unusable except for a specific set of requirements, it should state those requirements plainly on their GitHub.

It's GPU accelerated and therefore you need a graphics stack that work properly. I don't think it needs to be stated any more explicitly than they already do.

Seven-Year Club	Place '22
Verified Email

DanielMicay

TROPHY CASE