Benvenuto nel Poliverso

Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We've made it clear we're shipping Android 16 soon and that the supported devices will remain supported.

CoffeeLover ☕ likes this.

reshared this

in reply to GrapheneOS

Koutsie

in reply to GrapheneOS • 2 mesi fa • •

I've not seen any discourse about this?

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Pixels remain the only devices providing a high level of security combined with proper secure support for using another OS. We hope to have more options by the end of 2026 based on contact with an OEM interested in meeting our requirements but there's no specific timeline.

mei | fully hingeless architecture now in production likes this.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Our very reasonable hardware requirements are listed at grapheneos.org/faq#future-devi…. We expect industry standard security patches/features, not anything exotic. Multiple OEMs have indicated they should have no issue meeting these requirements with the next generation Snapdragon SoC.

GrapheneOS Frequently Asked Questions

Answers to frequently asked questions about GrapheneOS.

^GrapheneOS

in reply to GrapheneOS

d.rift

in reply to GrapheneOS • 2 mesi fa • •

The first OEM to figure out how to do that AND an eink display is going to make absolute bank.

in reply to GrapheneOS

J. Ling 🦑

in reply to GrapheneOS • 2 mesi fa • •

🤞 9to5google.com/2025/06/19/fair… is one of them

Fairphone 6 leaks in new images with new design, easily-replacable battery [Gallery]

The Fairphone 6 is just about ready for launch, and a new leak is giving us plenty of insight into what to expect.

^{Will Sattelberg (9to5Google)}

in reply to J. Ling 🦑

GrapheneOS

in reply to J. Ling 🦑 • 2 mesi fa • •

@jling No, this device will not meet our requirements. Fairphone doesn't care much about security and does not attempt to provide a reasonable level of security for their devices. They don't keep up with basic security patches or OS updates. They don't provide basic industry standard security features. They're not a good platform for GrapheneOS and we don't expect them to become one. Fairphone devices should be avoided if you care about privacy and security.

@J. Ling 🦑

in reply to GrapheneOS

Okuna

in reply to GrapheneOS • 2 mesi fa • •

@jling point taken. But still,to me it’s a shame, it would be the best of two worlds… a repairable, upgradable phone with a replaceable battery and a secure privacy friendly GOS.
Sad, this does not work

@J. Ling 🦑

in reply to Okuna

Balibalou

in reply to Okuna • 2 mesi fa • •

@Okuna @jling where is the link who say the new fairphone will not have any security chip ? Because dor the moment there is just possible leak of the FP6, nothing more, so wait a bit to see if it will have or not this kind of chip inside

@J. Ling 🦑 @Okuna

in reply to Balibalou

GrapheneOS

in reply to Balibalou • 2 mesi fa • •

@lajuste @Okuna @jling Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.

@J. Ling 🦑 @Balibalou @Okuna

in reply to GrapheneOS

Balibalou

in reply to GrapheneOS • 2 mesi fa • •

@Okuna @jling I don't see the link with /e/OS, we were talking about hardware, not software. The last time I talk with my contact linked to Fairphone, it was saying that they are putting on the table to add more hardware security on the table so I am looking for the link that show Fairphone is publicly saying the opposite now. And I can find nothing about it so I prefer believe my contact which not represents Fairphone but it is better than someone not linked to Fairphone saying the opposite. So if someone find an official answer, I am interested in it to confront my contact and push in the other direction for the best.

@J. Ling 🦑 @Okuna

in reply to Balibalou

GrapheneOS

in reply to Balibalou • 2 mesi fa • •

@lajuste @Okuna @jling Fairphone themselves said they had no plans to add a secure element in response to people asking about it. It was not unofficial.

@J. Ling 🦑 @Balibalou @Okuna

in reply to GrapheneOS

Okuna

in reply to GrapheneOS • 2 mesi fa • •

@lajuste @jling I think we can only state that:
1. Currently the fairphone does not offer hardware acceptable for GOS
2. No one can predict the future.
I am sure, when fairphone offers hardware which is acceptable, GOS will seriously consider it
For me: Case closed your honor

@J. Ling 🦑 @Balibalou

in reply to Okuna

GrapheneOS

in reply to Okuna • 2 mesi fa • •

@Okuna @lajuste @jling Their hardware doesn't meet bare minimum standards for security significantly lower than our requirements. It's beyond it simply not being up to our standards. It's much further from our standards than many other devices.

If they were drastically changing their approach, they would start shipping the security patch backports on time and start shipping OS updates much faster including not simply aiming to skip all the monthly and quarterly releases.

@J. Ling 🦑 @Balibalou @Okuna

in reply to GrapheneOS

Jose J. Fernández

in reply to GrapheneOS • 2 mesi fa • •

I've been following you for quite a while and love the work you are doing. I'm considering either getting a Pixel and installing GrapheneOS or a Fairphone, for non-security related reasons.

You mention than /e/os is dramatically less secure and this surprises me a bit. I'm not an expert in security, would you mind explaining why it is damatically less secure? Thanks! 🙌

in reply to Jose J. Fernández

GrapheneOS

in reply to Jose J. Fernández • 2 mesi fa • •

@josejfernandez Fairphone has a month or two of delays for standard partial privacy/security patch backports and a year or more of delays for full security patches via updating to the latest OS release. It gets worse over the lifetime of the device. Fairphone is missing basic security features like a secure element which among other things is needed for working disk encryption without a strong passphrase.

/e/OS is significantly worse than that at providing privacy/security patches.

@Jose J. Fernández

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@josejfernandez /e/OS makes it worse by hiding the real patch level within the OS UI and downplaying the importance of keeping up with patches for publicly disclosed privacy/security vulnerabilities including many remote code execution vulnerabilities.

On many devices they aren't providing driver/firmware updates either because they don't set it up, are way behind or the device is end-of-life. They're selling end-of-life and near end-of-life devices while pretending it's all fine and dandy.

@Jose J. Fernández

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@josejfernandez /e/OS disables important security features and rolls back the privacy/security model substantially. They do not properly sign their builds and don't do proper production builds. This also applies to LineageOS but /e/OS forks LineageOS and makes it much worse. The patch delays and how much security is rolled back separately from patches is much worse.

If you care about privacy and security then a Fairphone is a bad choice regardless of OS but /e/OS is an extremely poor choice.

@Jose J. Fernández

in reply to GrapheneOS

Jose J. Fernández

in reply to GrapheneOS • 2 mesi fa • •

Thank you for taking the time to explain! Appreciated.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

In 2017, Pixel 2 added an off-the-shelf secure element (SE) with Weaver and insider attack resistance. Weaver provides aggressive throttling to make disk encryption work without a strong passphrase. Insider attack resistance means SE firmware updates require Owner user unlock.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Weaver has a key-value mapping with a slot for each profile on the device where providing the correct authentication token gets back a stored random token needed as an extra input for disk encryption. It's a few hundred lines of code. It's what makes a random 6 digit PIN work.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Most Android devices still lack a secure element providing Weaver, a StrongBox KeyMint and other standard functionality. Weaver was shipped by the Pixel 2 (2017) and StrongBox by the Pixel 3 (2018). It's not a high expectation for devices to provide these features in 2025.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Most Android devices similarly lack proper privacy/security patches for drivers/firmware from day 1 and don't provide long term support. It's not a high expectation. OEMs get 1 month early access and should always ship Android Security Bulletin (ASB) and similar patches on time.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Pixel 8 and later provide 7 years of proper updates. Our minimum requirement is 5 years which has been the case since the Pixel 6. This requirement eliminates most devices despite us keeping it at 5 years. Getting security patches on time for 5 years isn't a high expectation.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

ARM provides standard exploit protections used by firmware and software to defend attack exploitation.

Pointer Authentication Codes (PAC) and Branch Target Identication (BTI) are near universal with ARMv9. Memory Tagging Extension (MTE) is more important and often omitted.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

All of the standard ARM Cortex cores provide PAC, BTI and MTE. SoC vendors simply need to keep the security features intact and provide basic integration for them. OEMs need to do the same. We greatly expand usage of all 3 of these and were the first to use MTE in production.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

MTE support launched with the Pixel 8 when it moved to ARMv9, but the stock OS still doesn't use it by default. In GrapheneOS, we always use it for the Linux kernel and nearly all base OS processes including apps. We provide a toggle to enable it for all user installed apps.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

We use it for known compatible user installed apps by default but it's incredibly good at detecting memory corruption and uncovers a lot of bugs. Due to this, we integrated it into our user-facing crash reporting system and per-app exceptions can be made for user installed apps.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

With Android 16, Pixel stock OS uses MTE for the small subset of users enabling Advanced Protection. It doesn't use it for the kernel or most of the OS, only a small portion of the OS and a tiny number of apps marked compatible. The implementation is also much weaker than ours.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Our MTE integration is one of the biggest security features we offer. Qualcomm still hasn't added MTE support, but it's supposed to be available with their 2025 SoC launch. Exynos and MediaTek added it for flagships. Samsung integrated support for it as a development feature.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Snapdragon provides solid overall security. It includes a basic secure element for the flagships. Our expectation is Snapdragon will add MTE this year and OEMs willing to do the work of providing proper security features and patches can make devices meeting our standards in 2026.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

The most secure non-Pixel devices disallow using another OS or don't allow another OS to use important hardware-based security features. Samsung flagships would be the next best option if they didn't do this. Our expectation is we need to work with an OEM, so we're doing that.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

GrapheneOS will continue supporting the current devices we support until their end-of-life dates. We'll also add support for new Pixels as long as they meet our requirements. We've tried to make that clear, but recent posts about changes to AOSP have been widely misrepresented.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

Prior to Android 16, Pixels had first class support in the Android Open Source Project as the official reference devices. This was never one of our requirements and no other device provides it. Many people are promoting hardware and software with atrocious security based on this.

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

A device without proper privacy/security patches or the hardware-based security features we expect didn't become a better option due to Pixels losing something no other device has ever provided. There isn't a non-Pixel device providing Android 15 QPR2 device trees let alone 16.

in reply to GrapheneOS

Chris

in reply to GrapheneOS • 2 mesi fa • •

Interesting monologue. But many people out there aren't so into security like you guys. The just want to ditch Google, use some kind of ad/tracker blocker for apps an for compatibilty MicroG on their phone.

in reply to Chris

GrapheneOS

in reply to Chris • 2 mesi fa • •

@Kubiac That doesn't make not having current privacy and security patches acceptable. People do not realize this is what they're getting. They don't realize these operating systems are putting their privacy at risk through being vulnerable to having their data and control over their device obtained through publicly known vulnerabilities. You underestimate how much people care about privacy and security. Not knowing not knowing about the differences in options does not mean they don't care.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac Aside from lacking good security, the microG approach does not provide broad app compatibility and good usability. There's a misconception that good compatibility and usability has to come at the cost of privacy and security. The insecure options without basic privacy/security patches which you're talking about how much worse compatibility and usability too.

@Chris

in reply to GrapheneOS

Leszek

in reply to GrapheneOS • 2 mesi fa • •

thank you for extensive clarification, I also got mixed up in the recent press about changes to AOSP!

in reply to GrapheneOS

Solal Nathan

in reply to GrapheneOS • 2 mesi fa • •

@Fairphone I hope Fairphone could meet the requirements on the next model if Qualcomm supports MTE on their next chip.

@Fairphone

in reply to Solal Nathan

GrapheneOS

in reply to Solal Nathan • 2 mesi fa • •

@solalnathan It's already known that their next model isn't going to provide MTE and is still going to be missing other requirements. They don't provide the required firmware/driver support for their devices either. There's a larger OEM in contact with us and aiming to meet our requirements in 2026 with the next generation Qualcomm SoC launched this year. We're optimistic about that. We don't think Fairphone is going to meet our requirements.

@Solal Nathan

in reply to GrapheneOS

Henning

in reply to GrapheneOS • 2 mesi fa • •

@solalnathan

It would be AMAZING if you could drop the word "headphone jack" somewhere in your conversations.

As a lot of GrapheneOS users listen to music with wired #headphones, but also want to have the USB port in "charging only" mode (for security and #privacy reasons), using a USB DAC is a total pain.

The tech is also pretty bad, I have a charging+audio dongle, which works fine, but resets itself when power is in/out.

#Audio #Android #Audiophile #Bluetooth

#Android #privacy #Bluetooth #audio #headphones #audiophile @Solal Nathan

in reply to Henning

GrapheneOS

in reply to Henning • 2 mesi fa • •

@hen @solalnathan The way our USB-C port control feature works does allow you to use "Charging-only while locked" and connect USB-C headphones while unlocked. It blocks new USB-C connections at both a hardware and software level but will leave USB-C data enabled until the USB-C connection ends. It would be better for security to not have an active USB-C connection but the feature does still work for that use case. It would be hard for all but very advanced attackers to take advantage of that.

@Solal Nathan @Henning

in reply to GrapheneOS

Henning

in reply to GrapheneOS • 2 mesi fa • •

@solalnathan

Yes that is true and I use it like that. But this means a pretty bad experience compared to a simple old headphone jack (like on my 4a, also running GrapheneOS but EOL).

While you get used to it, trying it again is dramatic; it just works, always!

Nothing worse than having headphones plugged in but the whole train listening to your music.

@Solal Nathan

in reply to Henning

GrapheneOS

in reply to Henning • 2 mesi fa • •

@hen @solalnathan The initial devices built for us by an OEM are going to be their regular devices improved to meet our security and support time requirements. We aren't going to have much influence over the initial hardware. If GrapheneOS on these devices is highly successful, then we can make the business case that it makes sense to have custom hardware and firmware beyond meeting our minimum requirements. Our minimum requirements cannot require more than what we have on current devices.

@Solal Nathan @Henning

in reply to GrapheneOS

Henning

in reply to GrapheneOS • 2 mesi fa • •

@solalnathan

Let's see then! I am excited if it will be a good fit to replace my 6a in the future.

Thanks for your work, stay positive and await some big donations incoming!

#DonateToFOSS

#donatetofoss @Solal Nathan

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

BTW your communication would come along much more trustworthy if you wouldn't throw around all those ultimate wordings. I personally never trust people who tell me aggressively that they are the only ones I should trust.

And it would be much better to let independent people check if your requirements are so totally reasonable instead of adding that label yourself.

in reply to Lazy B0y

Lazy B0y

in reply to Lazy B0y • 2 mesi fa • •

I totally understand more security is always better, but at the same time millions of people use other phones and the world keeps turning.

A binary world view is just splitting things into extremes and not helping to gradually advance for the better.

We had that with windows/linux for ages.
Yes Windows is shit and insecure, but the world didn't explode despite we know since decades that no one should use it and they still do it.

in reply to Lazy B0y

GrapheneOS

in reply to Lazy B0y • 2 mesi fa • •

@lazyb0y Our hardware security requirements are a very reasonable expectation to have proper security patches and industry standard security features. We're not setting a particularly high bar. The vast majority of devices are failing to provide bare minimum security patches and features. Our bar is set above the bare minimum but not at a very high level. There's nothing about what we do or our requirements for hardware which are a binary view of security. We're expecting reasonable security.

@Lazy B0y

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@lazyb0y The purpose of GrapheneOS is providing highly private and secure device. Hardware, firmware and driver security is part of doing that. We cannot properly protect users on devices not meeting our security requirements so we don't add support for them. It would not be GrapheneOS without our core feature set and important security patches/protections. Simply expecting proper patches rules out nearly all devices. The same goes for Pixel 3 or even Pixel 2 era AOSP secure element features.

@Lazy B0y

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

now
It's totally fine and ok if you talk about you, your goals and your requirements.

And that you keep not supporting other devices because of these requirements.

But this thread started with criticising others who maybe have other goals and requirements and a vague pointer on them saying bad things about you that I cannot judge due missing references.

in reply to Lazy B0y

GrapheneOS

in reply to Lazy B0y • 2 mesi fa • •

@lazyb0y This thread is a response to companies and individuals falsely claiming that GrapheneOS is being discontinued or has no future due to AOSP no longer including first class support for Pixels. AOSP doesn't include first class support for non-Pixels and there is no OEM providing device trees for Android 15 QPR2 from March 2025, let alone Android 16 from June 2025. Doesn't sense make to portray it the way people are doing to market their products and attack us when nothing else has that.

@Lazy B0y

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@lazyb0y Pixels had device trees as part of AOSP until June 2025 with the release of Android 16. We still have their device trees from the May 2025 release of Android 15 QPR2 as a reference. That doesn't exist for any other devices. It does not make sense to portray that going away as making other devices better or Pixels not viable for us anymore. It is not what we have said and our previous threads about this and the difficulties it creates have been widely misrepresented for false marketing.

@Lazy B0y

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

Thanks for replying!

It's great that you publish these requirements.

It's great that you strive for high security.

But it's not adding useful information when you state your own requirements (generally, for all others) as reasonable.

They are implicitly reasonable for you because you state them and you wouldn't do that otherwise.

But they are not necessarily reasonable for others as they must match their risk/exploitability/cost/effort of implementation balance for others.

in reply to Lazy B0y

GrapheneOS

in reply to Lazy B0y • 2 mesi fa • •

@lazyb0y Our requirements are for industry standard features and patches which are not difficult to provide. We've been told they're reasonable requirements which are realistic to meet by a large Android OEM with substantial market share. They want to meet the requirements and the main barrier to doing so was Qualcomm's substantial delay for shipping the standard ARMv9 MTE security feature. Only reason Qualcomm had a delay is because they don't use standard Cortex cores/cache but rather custom.

@Lazy B0y

in reply to Lazy B0y

GrapheneOS

in reply to Lazy B0y • 2 mesi fa • •

@lazyb0y We have not done anything of the kind. We have never claimed people should only trust us. We have pointed out that nearly all phone products marketed as private and secure actually have atrocious privacy and security far worse than many mainstream devices, which is accurate. iPhones are one of the only examples of devices with high private and security which are being marketed that way. Nearly all the other options are acting as if they're better than iPhones while being far worse.

@Lazy B0y

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

Well, you are continuously saying that other devices and therefore other OSes for these devices are inherently insecure and to me that implicitly means "trust only us".

And you are even repeating it right after declining it here and now ;)

to me as a user with not much clue about mobile security these posts dont come along as informational but as a flame war between two parties that doesn't help me decide what is really good(enough) for me to use.

in reply to Lazy B0y

GrapheneOS

in reply to Lazy B0y • 2 mesi fa • •

@lazyb0y We have repeatedly said that iPhones provide a high level of privacy and security. You would be losing a huge amount of both moving to most niche products and alternate operating systems. We do not do what you are saying at all. We provide accurate information on these topics, as do others confirming what we say. Months or even a year or more of delays for publicly disclosed privacy/security patches means having an atrocious level of privacy and security. That's very straightforward.

@Lazy B0y

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@lazyb0y We have never said to trust only us and have always provided accurate and nuanced information about how GrapheneOS compares to other options. You're making very false claims about what we said. Lack of understanding of the topic does not excuse misrepresenting what we've said. If you want to use an OS / device without basic privacy and security protections or patches, you are welcome to do so. You would be better off sticking with your iPhone, which does have good privacy and security.

@Lazy B0y

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@lazyb0y There's a high quality third party comparison between Android-based operating systems at eylenburg.github.io/android_co…. It has a privacy and security focus.

Their comparison includes rows for the typical delays introduced for the bare minimum privacy and security patches and full privacy and security patches. It bases those rows on the best case for the most well supported device by that OS, not the average. There are much longer delays with many of the devices those OSes support.

Comparison of Android-based Operating Systems

^{eylenburg.github.io}

@Lazy B0y

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

thanks, this is the kind of information that helps me learn about these things!

in reply to GrapheneOS

Light

in reply to GrapheneOS • 2 mesi fa • •

If Pixels' security features were industry standard, why do most devices not have them?

in reply to Light

GrapheneOS

in reply to Light • 2 mesi fa • •

@light There are many devices with most of these features, but not all. Lack of proper privacy/security patches and secure non-stock OS support are the main things missing. MTE is missing on Snapdragon due to their custom cores/cache but is part of standard Cortex cores.

@Light

in reply to GrapheneOS

Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS • 2 mesi fa • •

I know you said you have no percise timeline, but when you say end of 2026, are you talking about the launch of the actual devices, or the launch of your crowdfunding campaign?

in reply to Andromxda 🇺🇦🇵🇸🇹🇼

GrapheneOS

in reply to Andromxda 🇺🇦🇵🇸🇹🇼 • 2 mesi fa • •

@Andromxda That's when we hope to have at least one non-Pixel option not involving a crowdfunding campaign. It would be a device meeting our requirements based on an OEM doing more to meet them rather than a device built specifically for GrapheneOS. A device built specifically for GrapheneOS is further into the future than 2026.

@Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS

Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS • 2 mesi fa • •

Thanks for the clarification. By meeting your requirements, you mean that someone would be able to buy that device with the stock OS installed, unlock the bootloader, flash GrapheneOS, and re-lock the bootloader, just like with Pixels nowadays, right? (as well as all the other required hardware security features, etc. of course)

in reply to Andromxda 🇺🇦🇵🇸🇹🇼

GrapheneOS

in reply to Andromxda 🇺🇦🇵🇸🇹🇼 • 2 mesi fa • •

@Andromxda Yes, but they could sell devices with it.

@Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS

Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS • 2 mesi fa • •

What exactly would be the difference between someone meeting your requirements and selling devices with GrapheneOS preinstalled vs. having them make a custom device? Which features/requirements would you add to the list for a custom device?

in reply to Andromxda 🇺🇦🇵🇸🇹🇼

GrapheneOS

in reply to Andromxda 🇺🇦🇵🇸🇹🇼 • 2 mesi fa • •

@Andromxda If they were making a device specifically to run GrapheneOS then there could be hardware and firmware changes made beyond our minimum requirements. Our minimum requirements are industry standard features and a large OEM is fully capable of providing all of them without really developing much. It requires them to use reasonable components, properly set everything up and support the device long term. If it's a device made for GrapheneOS we would want more than just our defined minimum.

@Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS

Andromxda 🇺🇦🇵🇸🇹🇼

in reply to GrapheneOS • 2 mesi fa • •

Do you have any specific examples in mind? Or will that only be revealed later, once a custom device becomes more realistic? What would a perfect device look like in terms of hardware and firmware?

in reply to GrapheneOS

Lazy B0y

in reply to GrapheneOS • 2 mesi fa • •

What I still dont understand, as "security" is no binary thing but always a spectrum, and risk is always something that is also a calculation that has a bunch of factors(like likeliness of exploitability in certain scenarios) - does Graphene consider also all OEM Androids on all other phones as too insecure to be used by most people?

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@multisn8 Weaver is simply a table mapping authentication tokens derived from the lock method for Weaver to a random token needed as an additional input for key derivation. It implements aggressive throttling with a hardened monotonic timer in the secure element. There's hardware-based key derivation via the Trusted Execution Environment (TEE) which predates the addition of Weaver in 2017 with the Pixel 2. Weaver provides all security for a random 6 digit PIN since KDF work factor can't help.

@Multi

in reply to GrapheneOS

ActivityPub - Collegamento all'originale

neo

in reply to GrapheneOS • 2 mesi fa da Mostr Bridge • •

Does this mean you'll also be able to support upcoming Pixel devices or only the existing ones?

in reply to neo

GrapheneOS

in reply to neo • 2 mesi fa • •

@f901616f00a63f4f9c7881d4871a03df3d4cee7291eafd7adcbeea7c95c58e27 We expecting the Pixel 10 to meet our requirements, but we don't know if it will. We'll have to see at launch. We intend to continue supporting new Pixels as long as they meet our requirements, including after we have an OEM making hardware for us to use meeting our requirements. We wouldn't stop supporting new Pixels based on having an OEM making us hardware meeting our requirements.

@neo

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@TuxOnBike Those EU requirements do not come close to meeting our requirements. We expect the basic Android and other privacy and security patches to be shipped on time each months, not with huge delays. It's also important to note that the Android Security Bulletins are a subset of the overall privacy and security patches backported to older releases. The full patches are through upgrading to the new stable releases. 6 months of delay for getting the full set of patches isn't good enough.

@TuxOnBike

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@Frorscher It will likely be possible to support it, but it will take us significantly more time than usual. We added support for the Pixel 6a and later within around 24 hours from launch. It's definitely not going to be that quick. We can't predict how long it will take but it's going to take more time.

@Frorscher

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@Kierkegaanks GrapheneOS greatly exceeds the security expectations of any banking app. Most banking apps work fine on GrapheneOS. A subset of banking apps ban using anything other than a Google certified OS on Google certified hardware so those ones won't work on GrapheneOS. That doesn't have to do with security but rather enforcing licensing Google Mobile Services. Banking apps believe doing that is useful for security but they still permit devices with years of missing security patches...

@Kierkegaanks regretfully

in reply to GrapheneOS

tinyocean

in reply to GrapheneOS • 2 mesi fa • •

Is it really not possible to establish a symbiotic relationship with google?

You said the security team is fond of you, so it should be possible to convince other key people?

I mean most of the stuff you do does not harm googles business model.

in reply to tinyocean

GrapheneOS

in reply to tinyocean • 2 mesi fa • •

@tinyocean We thought it would be possible but it seems it isn't. We have talks with a large Android OEM ongoing and they're doing initial work towards supporting GrapheneOS. We hope there will be another device we can support in 2026 or 2027 based on this. Qualcomm releasing MTE support this year is key and appears to be happening.

@tinyocean

in reply to GrapheneOS

SmarTekk

in reply to GrapheneOS • 2 mesi fa • •

so that will be the time for me to leave google. I can't switch back to normal Android.... I will take my 9a as long as possible but......

Questa voce è stata modificata (2 mesi fa)

in reply to GrapheneOS

AADHIL

in reply to GrapheneOS • 2 mesi fa da Mostr Bridge • •

What platform you using now to communicate

in reply to AADHIL

AADHIL

in reply to AADHIL • 2 mesi fa da Mostr Bridge • •

If you use mastodon which server you using ?

in reply to AADHIL

GrapheneOS

in reply to AADHIL • 2 mesi fa • •

@5d385aa4e5068e236bec562836d0f16ef002de43c50832c623cc4cda0223fbf4 @tinyocean This is the @GrapheneOS account on our grapheneos.social instance for project/developer accounts. It's being bridged by someone else to Nostr. We'll make a Nostr account eventually but this isn't one.

@GrapheneOS @AADHIL @tinyocean

in reply to GrapheneOS

AADHIL

in reply to GrapheneOS • 2 mesi fa da Mostr Bridge • •

I asked that because you are the one who read and send postes and replies from mostr.pub

in reply to AADHIL

GrapheneOS

in reply to AADHIL • 2 mesi fa • •

@5d385aa4e5068e236bec562836d0f16ef002de43c50832c623cc4cda0223fbf4 @tinyocean That's the bridge someone runs. It shows your posts as coming from there to us. We aren't explicitly using it, it just bridges posts back and forth.

@AADHIL @tinyocean

in reply to GrapheneOS

minimo

in reply to GrapheneOS • 2 mesi fa da Mostr Bridge • •

Join the nostriches, join the permissionless social protocol!

in reply to minimo

GrapheneOS

in reply to minimo • 2 mesi fa • •

@772576c08bdc5da43f61802e767b2231e32c6f556fecee011ba30ff63c2d8529 @5d385aa4e5068e236bec562836d0f16ef002de43c50832c623cc4cda0223fbf4 @tinyocean We plan to eventually but have a huge amount of work to do so it's not one of our high priorities.

@AADHIL @tinyocean @minimo

in reply to GrapheneOS

🇯🇴

in reply to GrapheneOS • 2 mesi fa • •

I didn't see any mislead about it yet. But I though about it.
Can I have some example?

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@xuxxux @solalnathan Their devices aren't security-focused and are far from meeting our requirements.

@Solal Nathan @xuxxux

in reply to GrapheneOS

Felix

in reply to GrapheneOS • 2 mesi fa • •

@Frorscher That's one thing i don't quite understand with grapheneos.

Why the rush with new major versions? It seems like you work on android 16 support like hell, is there a reason why it can't be delayed? Don't older versions like 15 recieve security patches anymore?

Don't get me wrong, i seriously enjoy your work, and many of the additional features you provide have become must haves for me, but i don't mind waiting for quality work, especially 1/2

@Frorscher

in reply to Felix

GrapheneOS

in reply to Felix • 2 mesi fa • •

@newhinton @Frorscher Older Android releases receive partial security backports with most of the High and Critical severity patches. They don't receive everything and the patches can be months later than they were fixed in the latest monthly, quarterly or yearly releases. The patches are also more than those to the Android Open Source Project. There are many driver and firmware patches which for Pixels are now for Android 16. Our last few releases were to backport these to Android 15 QPR2.

@Frorscher @Felix

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@newhinton @Frorscher Many of driver library and service updates break when backported to Android 15 QPR2. They're for Android 16 and aren't meant to work on Android 15 QPR2. It can also happen with firmware and kernel drivers but for this month it was smooth. There's no guarantee that next month's patches can be backported in the same way. We need to at least get the Android 16 port done before the end of the month. We can't easily backport all Android 16 driver libraries/services to 15 QPR2.

@Frorscher @Felix

Unknown parent

Chris

Unknown parent • 2 mesi fa • •

I used GrapheneOS for one year with Play Services enable because of two apps. Afterwards I switched to CalyxOS with MicroG and all apps are working. The compatibility is not that bad. It is better than you think.
Apart from that it uses Open Street Maps data and it asks me if the new App can connect to Google messaging server. It even has a list of all connected apps. It's much more usable than Play Services and avoids Google servers where possible. That's privacy and usability.

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@dirksche @Kubiac CalyxOS does not provide current privacy or security patches, does not maintain the whole standard Android privacy/security model and doesn't provide similar privacy or security features to GrapheneOS. It lacks basic features like Contact Scopes and Storage Scopes needed for parity with iOS. microG is not a secure implementation and their approach gives strictly more access to Google code than our approach. Sandboxed Google Play gives less access to Google code, not more.

@das nächste bitte @Chris

in reply to Chris

das nächste bitte

in reply to Chris • 2 mesi fa • •

@Kubiac So thats why people are free to choose the OS they like.
You are happy with CalyxOS? Great.
For me security is he most important "feature". Thats why I love GrapheneOS.

@Chris

Questa voce è stata modificata (2 mesi fa)

in reply to Chris

GrapheneOS

in reply to Chris • 2 mesi fa • •

@Kubiac CalyxOS does not provide current privacy or security patches, does not maintain the whole standard Android privacy/security model and doesn't provide similar privacy or security features to GrapheneOS. It lacks basic features like Contact Scopes and Storage Scopes needed for parity with iOS. microG is not a secure implementation and their approach gives strictly more access to Google code than our approach. Their approach also very clearly has far less usability and compatibility.

@Chris

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@unexpectedteapot CalyxOS does not provide current privacy or security patches, does not maintain the whole standard Android privacy/security model and doesn't provide similar privacy or security features to GrapheneOS. It lacks basic features like Contact Scopes and Storage Scopes needed for parity with iOS. microG is not a secure implementation and also gives strictly more access to Google code than our approach. That approach also very clearly has far less usability and compatibility.

@unexpectedteapot

in reply to Chris

unexpectedteapot

in reply to Chris • 2 mesi fa • •

@Kubiac you missed their point. They are saying other software systems like Calyx lack timely fixes for vulnerabilities that are publicly known, and obviously guarantee none of the prevention methods Graphene provides. (that btw have mitigated multiple vulnerabilities in the past from being exploited)

Practically speaking, a false sense of privacy under provably poor security measures is very bad. You can't have privacy without security, simple as.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@dirksche @Kubiac You should review the third party comparison at eylenburg.github.io/android_co…. CalyxOS doesn't have comparable privacy features, always connects to multiple Google services and has Google services baked into the OS with privileged access. Their approach to compatibility with functionality like Android Auto is giving it privileged access. microG has privileged access and even downloads/runs Google binaries as part of itself for some of the functionality.

Comparison of Android-based Operating Systems

^{eylenburg.github.io}

@das nächste bitte @Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@dirksche @Kubiac GrapheneOS has our own implementation of network location which unlike microG is not in any way tied to Google service compatibility. Our compatibility layer defaults to rerouting the Google Play location API to the OS location API. Contrary to what they're claiming, we do reimplement functionality from Google Play services. We do it our own way with a focus on privacy, security and usability microG does not meet our standards so we continue building our own approach to this.

@das nächste bitte @Chris

Unknown parent

GrapheneOS

Unknown parent • 2 mesi fa • •

@xuxxux @solalnathan They do not provide proper privacy/security patches or OS updates for their current devices. They have repeatedly made hardware and software choices extremely counter to providing good privacy and security. Replacing their more reasonable non-GMS Fairphone OS with /e/OS is another example of this. They have a partnership with a company making an extraordinarily insecure and non-private OS marketed as highly private. Users are being misled into using highly insecure devices.

@Solal Nathan @xuxxux

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@unexpectedteapot You should review the third party comparison at eylenburg.github.io/android_co…. CalyxOS doesn't have comparable privacy features, always connects to multiple Google services and has Google services baked into the OS with privileged access. Their approach to compatibility with functionality like Android Auto is giving it privileged access. microG has privileged access and even downloads/runs Google binaries as part of itself for some of the functionality.

Comparison of Android-based Operating Systems

^{eylenburg.github.io}

@unexpectedteapot

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@unexpectedteapot GrapheneOS has our own implementation of network location which unlike microG is not in any way tied to Google service compatibility. Our compatibility layer defaults to rerouting the Google Play location API to the OS location API. Contrary to what they're claiming, we do reimplement functionality from Google Play services. We do it our own way with a focus on privacy, security and usability microG does not meet our standards so we continue building our own approach to this.

@unexpectedteapot

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac You should review the third party comparison at eylenburg.github.io/android_co…. CalyxOS doesn't have comparable privacy features, always connects to multiple Google services and has Google services baked into the OS with privileged access. Their approach to compatibility with functionality like Android Auto is giving it privileged access. microG has privileged access and even downloads/runs Google binaries as part of itself for some of the functionality.

Comparison of Android-based Operating Systems

^{eylenburg.github.io}

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac GrapheneOS has our own implementation of network location which unlike microG is not in any way tied to Google service compatibility. Our compatibility layer defaults to rerouting the Google Play location API to the OS location API. Contrary to what you're claiming, we do reimplement functionality from Google Play services. We do it our own way with a focus on privacy, security and usability microG does not meet our standards so we continue building our own approach to this.

@Chris

Unknown parent

Balibalou

Unknown parent • 2 mesi fa • •

@Okuna @jling can you link me that so I can use the statement to push for a more secure hardware please?

@J. Ling 🦑 @Okuna

Unknown parent

esplovago

Unknown parent • 2 mesi fa • •

adding @murena
and @fairphone for getting a reply useful for all the fediverse community 😀

@lajuste @Okuna @jling

@Murena - choose freedom! @J. Ling 🦑 @Fairphone @Balibalou @Okuna

in reply to GrapheneOS

Chris

in reply to GrapheneOS • 2 mesi fa • •

I know this site.
The remaining connections to Google can be changed via ADB in CalyxOS. And besides not all connections to Google are evil. You literally let the people use the original Play Services which does who knows what even sandboxed. Android Auto is optional and has to be enabled first in the settings menu. Privileged access is not a bad thing, since MicroG is not developed by Google and has no tracker build in.

in reply to GrapheneOS

Chris

in reply to GrapheneOS • 2 mesi fa • •

So does MicroG. It uses position.xyz or beacondb.net and not the google server. The connection to supl.google.com is still there but the strip out sensitive information. So it is not that big of a deal.
My problem with sandboxed Play services is that is is still the original from Google. I don't know how and when it communicates with other apps and what data it send, when it has internet permission. And when I ask for details I never get any answer from you guys.

in reply to Chris

GrapheneOS

in reply to Chris • 2 mesi fa • •

@Kubiac

No, CalyxOS always has connections to Google services beyond the ones they acknowledge and does not have a way to disable all of them.

microG has major privacy and security issues. It does not properly secure connections and has leaks of data to apps. Giving it privileged access makes the problem worse. microG has components it downloads as executables from Google and which it runs as part of itself.

CalyxOS includes privileged access for multiple Google apps, not only Android Auto.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac

You're promoting using an insecure OS without current privacy/security patches which does not preserve the standard privacy/security model. It greatly reduces privacy and security compared to the Android Open Source Project. It certainly doesn't provide comparable privacy or security to GrapheneOS. It doesn't have remotely comparable features. It lacks basic privacy features like Contact Scopes and Storage Scopes needed for iOS parity to avoid being forced to give apps data access.

@Chris

in reply to Chris

GrapheneOS

in reply to Chris • 2 mesi fa • •

@Kubiac microG primarily exists to use Google services and uses a bunch of them.

microG does not have a network location implementation comparable to the privacy and functionality of the one provided by GrapheneOS.

Your claim about CalyxOS stripping out sensitive information to supl.google.com is false. It sends location data to supl.google.com, which is clearly sensitive data.

You do not understand the difference between microG and sandboxed Google Play. You don't understand how they work.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac Every app using Play services has the Google Play SDK and libraries included in it. You are running the Google Play code on CalyxOS while giving it significantly more access to your data. You have not avoided running Google Play code on your device but now it runs in a weaker sandbox with a weaker permission model.

The whole point of sandboxed Google Play is we use the standard app sandbox used for each app using Google Play including the Google Play SDK and libraries you still use.

@Chris

Unknown parent

Chris

Unknown parent • 2 mesi fa • •

And you guys are great in avoiding the answer by switching to another topic. You are great in promoting your own product and talking badly about alternatives without giving any details or proof. You are just saying that your sandboxed Play Services are the most secure and private friendly solution, because trust me bro'.

in reply to Chris

GrapheneOS

in reply to Chris • 2 mesi fa • •

@Kubiac You're responding to our thread on our timeline posting false marketing for an insecure product rolling back privacy/security compared to the Android Open Source Project. You're resorting to making false claims about GrapheneOS and about what you're promoting because there's no substance. You have made numerous very clearly inaccurate statements showing ignorance about how things work. You have not and cannot show proof for your false claims about these topics. Simply stop messaging us.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac You came to this thread pushing false claims about GrapheneOS and promoting non-hardened operating systems. None of what you've been posting here has anything to do with the original topic. It's strange for you to be claiming we're changing the topic when it's the only thing you came here to do. We're responding to your posting promotion of non-hardened operating systems without comparable privacy or security. If you didn't bring it up, we wouldn't be talking about it in response.

@Chris

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@Kubiac The standard app sandbox on GrapheneOS is much better, meaning Google Play code has strictly less access than it does on CalyxOS. You've given more access to Google Play code which you are still running.

You're responding to our threads doing false marketing for a non-hardened OS that's much less secure than AOSP due to consistently lacking current privacy and security patches along with not preserving the basic privacy/security model and features. What do you think you'll achieve?

@Chris

in reply to GrapheneOS

richarddebruin

in reply to GrapheneOS • 2 mesi fa • •

he just did have some questions (not promoting anything, but just tell his experience). And now you guys block his account? Mmmn .. I find that a bit strange. Why?

in reply to richarddebruin

GrapheneOS

in reply to richarddebruin • 2 mesi fa • •

@richarddebruin No, he was very clearly not here to ask questions. He showed up in this thread to make attacks on GrapheneOS and promote a non-hardened OS without current privacy/security patches that's clearly in a much different space than us. This doesn't have to do with what we posted about in our thread. Rather than asking questions, what they were doing is making objectively false claims about GrapheneOS and our open source sandboxed Google Play compatibility layer feature.

@richarddebruin

in reply to GrapheneOS

richarddebruin

in reply to GrapheneOS • 2 mesi fa • •

he was just asking how it works. Nothing more. Why is a closed playstore service (nobody knows what is inside) in a sandbox with network connection more safe then the open microG solution?

in reply to richarddebruin

GrapheneOS

in reply to richarddebruin • 2 mesi fa • •

@richarddebruin They were here repeatedly making false claims about how it works. They were not here asking questions.

> Why is a closed playstore service (nobody knows what is inside) in a sandbox with network connection more safe then the open microG solution?

microG exists to provide compatibility with closed source Google Play code inside each app depending on Google Play. It exists to run closed source code. Neither microG or sandboxed Google Play is needed if you don't want to run that.

@richarddebruin

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@richarddebruin Both microG and our sandboxed Google Play compatibility layer are open source. Both exist to provide compatibility with closed source code.

It's a misconception that open source makes a project trustworthy, private or secure. microG is none of those things.

microG does not preserve all of the important security checks or important parts of the privacy model of all the APIs they implement. They have a history of covering up vulnerabilities and misleading people about it.

@richarddebruin

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@richarddebruin GrapheneOS doesn't come with sandboxed Google Play and you don't need to use it. It's only needed for compatibility with apps which contain the Google Play SDK and libraries with a hard requirement on Play services. If you don't use those apps, you don't need either approach. If you do use those apps, you are running closed source Google Play code. It can and does make connections to Google services itself without Play services. Google services can be used without Play services.

@richarddebruin

in reply to GrapheneOS

richarddebruin

in reply to GrapheneOS • 2 mesi fa • •

Thank you for the quick answers 👍. I am a little bit wiser 🤗

in reply to richarddebruin

GrapheneOS

in reply to richarddebruin • 2 mesi fa • •

@richarddebruin We gave these same answers and also much more details throughout the thread. It's just not all visible here. We did give detailed responses to their claims, which is not something they were owed in any way. They were hostile to us from their very first response to our device support thread and then descended into making these attacks on us. We blocked them after quite a lot of replies back and forth because they had begun attacking our team in a way we aren't going to allow.

@richarddebruin

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@richarddebruin See grapheneos.social/@GrapheneOS/… for one of the places where we posted detailed information in response to their claims about GrapheneOS. That's not the only place we responded. We provided a lot of information, and it was ignored. They've continued making inaccurate claims we've already addressed in detail. They had no interest in what we had to say and completely ignored it. They didn't respond, they just made personal attacks then repeated the claims we addressed on their feed.

GrapheneOS

2025-06-23 17:05:54

@pixelschubsi @davidculley The whole point of the sandboxed Google Play compatibility layer is that we provide zero special access or privileges to Google apps and services. The only purpose of using sandboxed Google Play is to use apps which contain the Google Play SDK and libraries. You are running Google Play's code when you use those apps. It runs as part of the apps within their app sandbox. Many of those libraries including Ads and Analytics work without Google Play services.

@richarddebruin

in reply to GrapheneOS

tuxayo

in reply to GrapheneOS • 2 mesi fa • •

Thanks for all your state of the art work ❤
Would sandboxing microg solve enough of security concerns around it? (if done like DivestOS discuss.privacyguides.net/t/di…) So treating it like the the GMS. And still get to not have tons of non libre code running. And privacy gain with less unnecessary data being phoned home. Which is also security and something reasonable to have in a thread model. (Dummy ad and analytics implementations IIUC)

DivestOS' unprivileged microG implementation

Latest release of my DivestOS can now run microG in an unprivileged manner: not a privileged system app and not a regular system app not pre-installed no special permissions no automatically granted permissions feature gated behind a toggle in Sett…

^{Privacy Guides Community}

in reply to tuxayo

GrapheneOS

in reply to tuxayo • 2 mesi fa • •

@tuxayo

> Would sandboxing microg solve enough of security concerns around it?

No, it wouldn't. Building our own better implementation would do that and we have already done a lot of work towards that including reimplementing the location API. Our reimplementation is what's used by default, avoiding needing to grant Location to sandboxed Play services to use apps needing the Google Play location API. We've had that for years.

It's a misconception that we aren't reimplementing the APIs.

@tuxayo

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@tuxayo

> So treating it like the the GMS. And still get to not have tons of non libre code running.

You have the Google Play SDK and libraries running as part of apps using it. Most of those apps are closed source as a whole. Using microG does not avoid using closed source Google Play and other code for those apps.

> And privacy gain with less unnecessary data being phoned home.

Not really.

> Which is also security and something reasonable to have in a thread model.

It's less secure.

@tuxayo

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@tuxayo

> Dummy ad and analytics implementations IIUC

There are client side implementations of these in apps, including the full Ads and Analytics libraries. We're fully capable of providing stub implementations of the Play services ones with our existing approach.

We will never use microG and we don't need it to reimplement Google Play APIs ourselves. We can make it so apps with a hard dependency on a small number of Google Play APIs can run without Play services. We already do some of it.

@tuxayo

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 2 mesi fa • •

@tuxayo For example, Pixel Camera and Google Photos run on GrapheneOS without Google Play services installed. We can expand that to apps depending on the location API and much more. There's no reason we can't do that with our approach. We will never use or support microG. We would rather make our own implementation of everything as we already did with our standalone network location implementation not tied to Google Play compatibility and the Google Play location API we reimplement ourselves.

@tuxayo

⇧

GrapheneOS 2 mesi fa • •

GrapheneOS
2 mesi fa • •