Text on signature spoofing is misleading

[mar-v-in]

The current text about signature spoofing is misleading:

MicroG is a common alternative to Google Play Services. It is often used to get rid of Google's tracking, but most people do not realise that this can potentially worsen security as it requires signature spoofing support which allows apps to request to bypass signature verification. This subverts the security model and breaks the application sandbox as an app can now masquerade itself as another app to gain access to the app's files. In a system with signature spoofing, it is impossible to know anything — there is no way to trust that an application is genuinely what it claims to be and it is impossible to build a strong security model upon this.

• allows apps to request to bypass signature verification: With signature spoofing, signatures are verified by the OS as usual. If apps implement signature verification themselves (for whatever reason) those would work as usual as well. Signature spoofing pops in after the OS verified the signature as usual when third-party apps ask the OS what the signing certificate of another app is without actually verifying it.
• an app can now masquerade itself as another app to gain access to the app's files: The masquerading of signature spoofing does not extend to the package management. This means that app updates must still be signed using the same key that signed the to-be-updated app - even if that app used signature spoofing. The only situation where an app with signature spoofing might be able to gain access to files that it shouldn't be allowed to get access to, is when other apps on the same system forward private files to another app that they (based on signature) assume to be authorized to receive those files. This is against the best practices outlined in the official Android security guide (which suggests using a signature restricted permission instead, which is managed by the package manager and thus would not be affected by the signature spoofing patch)
• there is no way to trust that an application is genuinely what it claims to be and it is impossible to build a strong security model upon this: First of all, it is trivial for apps to find out if another app has the signature spoofing permission and thus could spoof signature using the widely available signature spoofing patches. It is also possible for apps to verify signatures themselves instead of just requesting them, if it must be assured that the signature is valid and done using a specific key. However, I'm also not completely certain what kind of "trust" you're envisioning here: On a device owned and controlled by the user, apps can't trust that the user did not intentionally modify the device to better fit their own needs. A device where this is possible would not be in control by the user.

I'm here because someone claimed wrong things and linked to your website as a source. While your description is mostly not wrong per se, it is misleading enough for people to read it wrong.

[thestinger]

microG doesn't implement the proper security checks and security model for Play services. The signature checks are security checks and bypassing them is bypassing a security check and reducing the security of the software.

Signature spoofing pops in after the OS verified the signature as usual when third-party apps ask the OS what the signing certificate of another app is without actually verifying it.

The purpose of retrieving it is to verify it and you're being deliberately misleading.

The only situation where an app with signature spoofing might be able to gain access to files that it shouldn't be allowed to get access to, is when other apps on the same system forward private files to another app that they (based on signature) assume to be authorized to receive those files. This is against the best practices outlined in the official Android security guide (which suggests using a signature restricted permission instead, which is managed by the package manager and thus would not be affected by the signature spoofing patch)

You're trying to pretend as if you aren't bypassing security checks by misleading people and claiming that the checks don't follow best practices. Recommended approaches in documentation are not a hard rule and security checks implemented using an approach that's not recommended or considered deprecated are still security checks.

I'm here because someone claimed wrong things and linked to your website as a source. While your description is mostly not wrong per se, it is misleading enough for people to read it wrong.

The site isn't misleading anyone. You're being consistently dishonest in how you misrepresent your software. These inaccurate talking points you push about signature spoofing are more of the same. You also made completely false claims about the privacy and security of CalyxOS and GrapheneOS in order to try promoting the interests of the people giving you resources. You should be aware that we'll be raising your highly unethical and malicious behavior with organizations funding your software and any conferences or other venues where anything about is presented.

The developers of microG have repeatedly engaged in underhanded and malicious behavior. You frequently lie to people about how it works and compares to alternatives. You've engaged in a behind the scenes campaign aimed at promoting projects including it with false privacy and security claims about them and about GrapheneOS. That reflects directly on microG and no one should trust you at this point. You've displayed incredibly despicable behavior and have consistently covered up and lied about the serious privacy and security weaknesses of your software. You directly lied about unpatched privacy and security vulnerabilities to FSFE to project your interests. It's despicable behavior and you can expect a substantial response from GrapheneOS and other parties that you've harmed. You should be aware that your actions have consequences and that we aren't afraid to publish information on your highly toxic behavior on the GrapheneOS site and via journalists. I think they'd be interested to know how you've lied about an OS being 4 months behind on privacy/security patches and how you've consistently covered up privacy and security vulnerabilities beyond that in order to mislead users. It's unfortunate that you don't consider the massive amount of harm you cause with your actions. Promoting your ideology doesn't justify this kind of underhanded, deceitful and malicious behavior.

[735trv]

@thestinger Calm down. The comment doesn't mention CalyxOS or GrapheneOS 🙄

[thestinger]

@735trv I don't need to calm down. @mar-v-in works closely with CalyxOS and has recently been involved in spreading misinformation about GrapheneOS in an attempt to reduce contributions and funding for the project due to it taking a different approach to Google Play compatibility than including his software. He's taking the same underhanded approach here with the same kinds of misrepresentations and outright lies.

[735trv]

How about discussing on a professional level instead of constantly throwing around the terms "misinformation" or "lies"? Just write about the points he writes and drop the other topic. It also doesn't reflect well on you when such terms are used over and over again. (It doesn't mean you are wrong)

[thestinger]

microG isn't just a poor approach and highly insecure. It has untrustworthy developers displaying a pattern of dishonest and malicious behavior. I personally think that's worth noting. A project denying and covering up security weaknesses and even serious vulnerabilities is a seriously bad look and 100% relevant to whether it should be recommended especially in a privacy and security context.

Lying about an OS being 4 months behind on OS privacy/security patches and trying to stop listing GrapheneOS as an OS option is a serious breach of trust and is incredibly underhanded and dishonest behavior. They still haven't even shipped months of Chromium patches so any app using the WebView is vulnerable. That's @mar-v-in approach to privacy and security. He treats it as a branding/marketing issue to be resolved with misrepresentations and dishonest claims as he did with his recent behavior involving CalyxOS. The claims he regularly makes are disturbing coming from someone who would need to have strong knowledge of the platform and privacy/security in order to produce quality software. He even claimed that having a bunch of Chromium vulnerabilities including ones being exploited in the wild was not a problem because people can use a different browser despite every app using the WebView being vulnerable. Look above at his nonsense reasoning about signature spoofing and his claim that it's totally okay to break security checks as long as they aren't following the latest and greatest recommended approach. This is not someone who should be in the trusted position of maintaining any core infrastructure.

[thestinger]

@735trv I don't understand how spreading misinformation, repeatedly lying and trying to harm other projects with behind the scenes trickery is professional. @mar-v-in works closely with people involved in long term abusive behavior including harassment, bullying and doxxing targeting me. Is that professional behavior as long as everyone uses a polite tone on an issue tracker?

[735trv]

microG isn't just a poor approach and highly insecure.

I know, but he didn't mention CalyxOS or GrapheneOS in any sentence. Please focus only on microG.

[thestinger]

It involves his recent actions and is highly relevant to what he's trying to do here. If you don't think it's relevant you're welcome to ignore my comments.

[mar-v-in]

@thestinger First of all, please stop spreading misinformation about me. None of my devices have or had CalyxOS installed. I'm also not working with them at all. The only "cooperation" is that I accepted pull requests from two persons that also contribute to CalyxOS, both of which also contributed to GrapheneOS. I'm basically working as close with CalyxOS as I'm working with GrapheneOS.

I very much appreciate Android distributions taking a stance against Play Services by not shipping it and advising their users to not use them. This includes GrapheneOS. In fact, whenever someone asks me for advice what custom ROM to install on their Pixel devices and they don't need Play Services or microG, I advice them to install GrapheneOS. GrapheneOS is undoubtedly the Android distribution with the highest security standard out there (at least to my knowledge). I never claimed otherwise.

It also speaks very much against you that you claim I do X and Y "behind the scenes" because nobody can verify and there is no way for me to proof you wrong.

Now back to the original topic of signature spoofing:

The purpose of retrieving it is to verify it and you're being deliberately misleading.

After retrieving the package information, apps can also fetch and verify the signature. If they do this properly, signature spoofing does not affect them.

You're trying to pretend as if you aren't bypassing security checks by misleading people and claiming that the checks don't follow best practices.

I was trying to be as transparent as possible here and outlined how signature spoofing could theoretically lead to "another app gain access to the app's files". I wanted to make sure it is understood that with signature spoofing you can not update an app without full signature verification (= the OS verifying that old and new signing certificate match), which is a common misunderstanding and probably let to the "gain access to the app's files" claim. I don't quite understand how me stating a possible attack against apps though signature spoofing can be construed as "pretending to not bypass security checks".

FWIW, I'm also working on a way to use microG without requiring to add the signature spoofing patch to the OS.

[thestinger]

First of all, please stop spreading misinformation about me. None of my devices have or had CalyxOS installed. I'm also not working with them at all. The only "cooperation" is that I accepted pull requests from two persons that also contribute to CalyxOS, both of which also contributed to GrapheneOS. I'm basically working as close with CalyxOS as I'm working with GrapheneOS.

I'm not spreading any misinformation about you. Nothing I've said here is untrue. Neither of those people contributes to GrapheneOS and they are paid employees of Calyx not contributors. Both have been involved in highly abusive behavior towards us. Both are permanently banned from any participation in our community. It reflects on the microG project just as your behavior does. GrapheneOS plans to drop Seedvault due to it being almost entirely taken over by Calyx and not following the original plan we set out for it. We also don't trust code from people who behave the way they do and are unable to have confidence in it going forward.

I very much appreciate Android distributions taking a stance against Play Services by not shipping it and advising their users to not use them. This includes GrapheneOS. In fact, whenever someone asks me for advice what custom ROM to install on their Pixel devices and they don't need Play Services or microG, I advice them to install GrapheneOS. GrapheneOS is undoubtedly the Android distribution with the highest security standard out there (at least to my knowledge). I never claimed otherwise.

Telling people that GrapheneOS doesn't offer the same app compatibility or usability is part of the malicious talking points from CalyxOS which are not the reality. Trying to stop GrapheneOS being listed as an option and covering up privacy and security vulnerabilities in CalyxOS doesn't match how you portray your behavior.

It also speaks very much against you that you claim I do X and Y "behind the scenes" because nobody can verify and there is no way for me to proof you wrong.

We can provide evidence. Is this a denial that you were involved in doing this?

After retrieving the package information, apps can also fetch and verify the signature. If they do this properly, signature spoofing does not affect them.

Again, you're being deliberately misleading.

I was trying to be as transparent as possible here and outlined how signature spoofing could theoretically lead to "another app gain access to the app's files". I wanted to make sure it is understood that with signature spoofing you can not update an app without full signature verification (= the OS verifying that old and new signing certificate match), which is a common misunderstanding and probably let to the "gain access to the app's files" claim. I don't quite understand how me stating a possible attack against apps though signature spoofing can be construed as "pretending to not bypass security checks".

It's straightforward: it bypasses a security check and makes the code think microG is Play services. microG doesn't implement the same checks or security model. In many cases it goes out of the way to not uphold the expectations.

FWIW, I'm also working on a way to use microG without requiring to add the signature spoofing patch to the OS.

GrapheneOS users can choose to install and use GSF, GMS and the Play Store as regular sandboxed apps which are near fully functional via our compatibility layer. They can do the same with microG already even though it isn't designed to work that way and would be limited by not having the integration regardless.

[thestinger]

Clearly signature spoofing bypasses checks they perform for the Google Play app signatures or you wouldn't be doing it. If the checks are done insecurely and don't have meaning, why would you need any patches? Perhaps Google Play should be doing much stricter checks in the SDK in a central place instead of inconsistently applying it in only certain places. It can be reported to them as a vulnerability since it leads to allowing app data to be intercepted on operating systems not bundling Google Play. I don't know if they care about OSes not bundling Google Play but they do have CDD/CTS certification for them and they exist in a meaningful way in their rules for licensing Play.

[735trv]

@thestinger: Could you explain why this point is wrong?

After retrieving the package information, apps can also fetch and verify the signature. If they do this properly, signature spoofing does not affect them.

Again, you're being deliberately misleading.

[thestinger]

microG bypasses the way that the apps perform the signature checks. If they performed them other ways, they would bypass those too. That's the whole point of what it does. It doesn't matter if they don't do the signature checks in the most modern way especially since they are hard-wired checks rather than some kind of API. If they need to change them when they rotate keys, which they started on doing, then it's up to them to fix it. It's not a public API. The fact that the apps do not fetch the keys and check them manually doesn't mean that they aren't bypassing meaningful checks. Have already been through all this with @mar-v-in elsewhere. It's not a disagreement on the facts. It's a disagreement on ideology and whether it's ethical to mislead and lie to push what you think it right.

[thestinger]

Why does it matter if the apps perform the signature checks with one API over another?

The only situation where an app with signature spoofing might be able to gain access to files that it shouldn't be allowed to get access to, is when other apps on the same system forward private files to another app that they (based on signature) assume to be authorized to receive those files. This is against the best practices outlined in the official Android security guide (which suggests using a signature restricted permission instead, which is managed by the package manager and thus would not be affected by the signature spoofing patch)

there is no way to trust that an application is genuinely what it claims to be and it is impossible to build a strong security model upon this: First of all, it is trivial for apps to find out if another app has the signature spoofing permission and thus could spoof signature using the widely available signature spoofing patches. It is also possible for apps to verify signatures themselves instead of just requesting them, if it must be assured that the signature is valid and done using a specific key. However, I'm also not completely certain what kind of "trust" you're envisioning here: On a device owned and controlled by the user, apps can't trust that the user did not intentionally modify the device to better fit their own needs. A device where this is possible would not be in control by the user.

I've seen this multiple times before and I already thoroughly refuted it elsewhere. I don't see the need to refute clearly bad faith arguments repeatedly. It's a whole bunch of words not really saying anything beyond trying to mislead people and distract from the fact that security checks are being bypassed to enable another app to provide the APIs. It doesn't matter if they don't do the security checks in the recommended way. Does @mar-v-in actually want them to perform the checks in a much stricter way which makes the microG approach more difficult and totally useless without spoofing? They aren't currently stopping apps from intercepting data from other apps (not simply 'files') via pretending to be Play services on OSes without Play services. That is a security issue. It would be considered one for another app if their API didn't check that the app providing it is legitimate. Google just hasn't cared up to this point since it's not an issue on other devices. They only inconsistently apply the checks. The checks are not useless or microG wouldn't need to have a bypass included in the OS for full functionality.

[mar-v-in]

@thestinger

I'm not spreading any misinformation about you.

You are. Just to clarify again.

• Contrary to your claim, there is no cooperation between microG and CalyxOS and there never has been any. microG is free software available to everyone and thus can be distributed as part of CalyxOS as well as any other Android distribution. Contributors to CalyxOS (paid or unpaid) can contribute to microG by opening a pull request just like everyone else. The only contractual relationship between microG and CalyxOS is the Apache 2.0 license that governs their use of microG and this license is granted to everyone. I accept pull requests based on their content, not their author(s) or what they did in other projects.
• Contrary to your claim, GrapheneOS uses code from the very same CalyxOS contributors that also contributed to microG. Seedvault is part of the GrapheneOS distribution and at least 2/3rd of it is written by the very same two (paid or unpaid) CalyxOS contributors that also contributed to microG.
• Contrary to your claim, I don't lie to people. We might have different opinions on various topics, i.e. how to prioritize free software, user control, privacy and security, but that doesn't make my opinion a lie.
• Contrary to your claim, I never said that GrapheneOS with Play Services offers worse compatibility and usability than microG. The opposite is the case: GrapheneOS with Play Services as a user app is very close in terms of compatibility to original Google Play Services. microG (and recursively any Android distribution relying on it, including CalyxOS) will never be able to reach that level of compatibility. Also, even though I never tried GrapheneOS with sandboxed Play Services solution, I have no doubts that its usability is much better than microG, given that the original UX from Google is mostly preserved and they happen to have a big design team instead of just one software developer doing "design".
• Contrary to your claim, I never made any effort to not list GrapheneOS as an alternative Android distribution.

If you can provide evidence for any of these invalid claims, go and publish it. If you can't, stop making such claims.

---

GrapheneOS users [...] can do the same with microG already even though it isn't designed to work that way and would be limited by not having the integration regardless.

I'm curious to know how installing microG without signature spoofing is any good even if it is possible, given that apps will not use it, but that is off-topic here.

---

If it makes you happy, we can also phrase it like this:

Signature spoofing and microG impact the security of the system.

This is entirely true, but obviously is a very incomplete story. I guess we can both get behind this statement, so let's leave it as this and work together for a world where free software, security, privacy and user control go hand in hand instead of fighting each other.

---

Trying to discuss the initial topic I brought up (which is about people wrongly understanding the text presented)

The statement that linked to this text as a source was

By allowing signature spoofing, you are allowing anyone to push an update, via any channel, onto your device, and use any signature (because signature doesn't matter at this point). They now have complete access to your data and any privacy gains are negated.

Do you think this is a correct statement or do you think there is some misunderstanding here? Do you think that it makes sense to improve the text to better educate people?

[akc3n]

🤥

[thestinger]

Contrary to your claim, there is no cooperation between microG and CalyxOS and there never has been any. microG is free software available to everyone and thus can be distributed as part of CalyxOS as well as any other Android distribution. Contributors to CalyxOS (paid or unpaid) can contribute to microG by opening a pull request just like everyone else. The only contractual relationship between microG and CalyxOS is the Apache 2.0 license that governs their use of microG and this license is granted to everyone. I accept pull requests based on their content, not their author(s) or what they did in other projects.

You're regularly working with them and we are well aware you are spreading false claims about CalyxOS to promote it as part of an attempt to not just promote it but to avoid GrapheneOS being recommended to people. You're acting as if we don't know what you were involved in.

Contrary to your claim, GrapheneOS uses code from the very same CalyxOS contributors that also contributed to microG. Seedvault is part of the GrapheneOS distribution and at least 2/3rd of it is written by the very same two (paid or unpaid) CalyxOS contributors that also contributed to microG.

This is not contributing to GrapheneOS. In fact, we are dropping Seedvault due to their involvement as explained above. They are Calyx employees not contributors. Seedvault was originally created for use in GrapheneOS but they essentially took over the project and we no longer want to use it but need to migrate away from it. That is being dealt with and doesn't mean they contribute to us...

Contributing to an app that we made the mistake of bundling due to a misunderstanding of who was going to be in charge of the project and developing it is not contributing to our project. Seedvault is not our project. It's a very buggy and unreliable backup system based on our initial concept for it which has strayed far away from what we intended.

The inclusion of an app being used to try to attack us on many occasions by CalyxOS and other collaborators in their attacks on us like yourself is a great reason to avoid the app too. Apps with substantial contributions from malicious / abusive people aren't going to be included in GrapheneOS. Seedvault started out well but they ruined it and we haven't removed it to avoid breaking backwards compatibility but we're quite wary of the changes being made to it and don't plan on including it over the long term.

Contrary to your claim, I don't lie to people. We might have different opinions on various topics, i.e. how to prioritize free software, user control, privacy and security, but that doesn't make my opinion a lie.

Yet that's what you're repeatedly doing and you've engaged in what we consider highly malicious behavior to push CalyxOS.

Contrary to your claim, I never made any effort to not list GrapheneOS as an alternative Android distribution.

This isn't true.

If you can provide evidence for any of these invalid claims, go and publish it. If you can't, stop making such claims.

They aren't invalid claims and I will continue making them including far more publicly. If you won't ban highly abusive people from involvement in your project and are going to continue spreading misinformation to promote their OS and microG then you can expect severe consequences for your reputation.

I'm curious to know how installing microG without signature spoofing is any good even if it is possible, given that apps will not use it, but that is off-topic here.

I never said it was good or worked well but some apps simply work if GSF is present. Google Camera and Google Photos work fine with only GSF installed despite it not really doing anything. It's something we document in our usage guide since some people simply want to use apps which doesn't actually require GMS and just need the interfaces defined. We recommend using GSF as simply an extension of the libraries in the apps for those rather than microG but people do use microG on GrapheneOS for this. We've even heard that certain services do work since signatures do not appear to be globally/consistently checked right now which should likely be fixed.

This is entirely true, but obviously is a very incomplete story. I guess we can both get behind this statement, so let's leave it as this and work together for a world where free software, security, privacy and user control go hand in hand instead of fighting each other.

I can't work with people who are in collaboration with people involved in highly abusive behavior towards myself and others. I also can't work with people that are making false claims about privacy and security. My issues with you are recent, not something long term.

Do you think this is a correct statement or do you think there is some misunderstanding here? Do you think that it makes sense to improve the text to better educate people?

CalyxOS and microG supporters spread misinformation about GrapheneOS and attacks on our project members across almost every post about GrapheneOS across platforms. There's rarely any major post on Hacker News, Twitter, Reddit, etc. about it without those people showing up. madaidan hasn't made false claims about microG or CalyxOS unlike how CalyxOS has pushed tons of false claims about GrapheneOS themselves and their close associates have put out vicious malicious attacks on us. If you're going to be accepting their contributions, money or working with them in any other way including promoting their OS and trying to cover up it not having privacy/security updates for 4 months for the OS (recently resolved) and browser engine (including for the WebView, which is NOT resolved) then you're an enemy too. You should also be aware that we intend to be extremely aggressive in our response to the attacks on us going forward, far more than I have been here. They have spent years trying to destroy my project and my reputation. I intend to do the same to them and the people supporting them but I don't have to go around spreading misinformation and lying about you folks. If you don't want to be part of that then you can choose to not be part of it. Ban them from participation in your project, stop promoting their OS and stop spreading false claims about it.

[thestinger]

I fully intend to respond by bringing this to any conference, project or other event / organization where they receive funding or contribute. There is nowhere that you can participate where this conflict won't become part of it. If CalyxOS or the people they work with is involved in a conference, I'll have our community contact the people running the conference about it and if necessary the conference hosting abusive people will be disrupted through protest. Our response will be scaled up more and more due to the escalating attacks and libel targeting us and the severe harm that has been caused to us. I consider microG to be an extension of the CalyxOS project at this point. You could choose to stop working with them. I also consider /e/ to be on bad terms with us now due to recent events we became aware of involving FSFE and the fact that they provide funding to you. I contacted their project leader and let them know my feelings on it. Didn't go anywhere useful and while we have no active conflict with /e/, I would no longer be willing to work with them unless they stopped funding you.

[thestinger]

I do not consider CalyxOS and their collaborators to be on the same side of us but rather enemies doing far more harm to mobile privacy and security than almost anyone else through their sabotage and underhanded tactics. I'm certainly not going to be working with them but rather figuring out how to push everyone involved out of a space where they don't belong. Any projects or communities collaborating with such malicious people can expect consequences. Escalating to publishing the 1 hour hit piece video targeting me in April 2021 and then following that up with a bunch of additional libel and attacks on the project was a mistake. There will be years of consequences for everyone involved in that and the people who collaborate them. I'll make sure that there can be no participation in any prominent spaces for the people who orchestrated it without it becoming entirely about this. There is no coming back from what has been perpetrated against myself and GrapheneOS by CalyxOS and their associates.

I have zero problem responding to attacks with counter-attacks going forward. CalyxOS has chosen to support and encourage people telling me to kill myself, doxxing me, and fabricating stories about me as part of their endless attacks. None of you is in any place to complain about anything we have done in response which has so far been incredibly mild and restrained. It's not going to remain that way though.

Maybe it doesn't come across how incredibly angry I am about what has been done. I'm literally willing to invest hundreds of thousands of dollars in retaliation, whether that ends up being legal action, paying for negative advertising or paying people to work full time countering the attacks and making counter-attacks.

[mar-v-in]

FWIW, You did not provide any proof for your false claims and are just repeating them. I'll try to ignore them and stick to the interesting parts of your messages.

We've even heard that certain services do work since signatures do not appear to be globally/consistently checked right now which should likely be fixed.

This is not going to be "fixed". I you want I can explain to you why, but I'm not very motivated right now...

madaidan hasn't made false claims about microG

I never claimed they did. I quoted an individual that, based on the information on madaidan's website concluded wrong things and that thus I think the information is misleading and suggested it could be extended / more detailed to not cause this again. If madaidan feels like this is no issue, they're invited to say so and close this issue.

They have spent years trying to destroy my project and my reputation.

I feel sorry for this. Be assured that your reputation and the reputation of GrapheneOS aren't bad at all. The only negative thing I heard about you is that discussions with you are sometimes not very friendly, which I guess this is just another instance of.

You could choose to stop working with them. None of you is in any place to complain about anything

From my perspective, you are attacking me for no good reason. Your reason seems to be some involvement with CalyxOS that simply doesn't exist. So this is why I think I'm in a place to complain. I guess I can share with you the fact that Calyx at some point in 2020 asked me if I was willing to assist them with microG integration and I didn't. What else do you expect me to do? Not accepting their ready made code in pull requests?

[thestinger]

FWIW, You did not provide any proof for your false claims and are just repeating them. I'll try to ignore them and stick to the interesting parts of your messages.

I'm not making any false claims...

I never claimed they did. I quoted an individual that, based on the information on madaidan's website concluded wrong things and that thus I think the information is misleading and suggested it could be extended / more detailed to not cause this again. If madaidan feels like this is no issue, they're invited to say so and close this issue.

In which case your project must be spreading tons of misinformation for your community to be attacking us non-stop across platform all days and harassing us.

I feel sorry for this. Be assured that your reputation and the reputation of GrapheneOS aren't bad at all. The only negative thing I heard about you is that discussions with you are sometimes not very friendly, which I guess this is just another instance of.

I don't think the behavior of the people involved in your project and community is at all friendly and most of the GrapheneOS community feels the same way. It's not our community making attacks on your project across platforms whenever it comes up including attacks on developers and attempts to portray them as crazy/deranged. If you'd like that can quickly change. Do you want the top result for your name on YouTube to be a hit piece attacking you with misinformation because I can fund for each and every person involved in CalyxOS and the people they associate with in retaliation for them doing that to me.

From my perspective, you are attacking me for no good reason. Your reason seems to be some involvement with CalyxOS that simply doesn't exist. So this is why I think I'm in a place to complain.

I guess I can share with you the fact that Calyx at some point in 2020 asked me if I was willing to assist them with microG integration and I didn't. What else do you expect me to do? Not accepting their ready made code in pull requests?

Your association with CalyxOS is only an additional factor. It's based on a recent event where I discovered that you were spreading misinformation behind the scenes. You haven't denied any of that.

And yes I do expect that projects do not accept the involvement of people that are behaving incredibly maliciously and are involved in vicious harassment and doxxing.

They went after our sources of funding and contributions. They've tried to cut off support for GrapheneOS through spreading endless inaccurate talking points and going after me personally with vicious attacks. You're happily taking their contributions and voicing support for them along with covering up problems with their OS unrelated to your project.

I consider you part of that group of people now since what I found out recently. Shouldn't associate with terrible people if you don't want to be considered one of them regardless. They're more than happy to permit people from Kiwi Farms and other despicable places and regularly talk to and encourage them despite them openly harassing me. They also directly contribute to that. If you choose to associate with that then don't be surprised if it becomes part of your reputation too. I fully intend to substantially retaliate against the attacks on us. There's a 1 hour hit piece targeting me with a whole bunch of fabrication / misrepresentations from a YouTube influencer who has closely worked with them. Why shouldn't there be a 1 hour video about each of the people involved in CalyxOS ruining their reputation? I fully intend on making that happen and also far more than that. Believe me after spending a year having them try to portray me as crazy / deranged / schizophrenic and directing harassment/bullying towards me there is not much that I'm unwilling to do in retaliation. I've had threats sent to where I live after they leaked my address.

[735trv]

@thestinger

microG bypasses the way that the apps perform the signature checks. If they performed them other ways, they would bypass those too. That's the whole point of what it does.

Okay, thank you. I didn't know that when an app does it itself, it also bypasses it. I didn't have an app that required Google Play Services. So I have no experience with microG or Google Play Services in general.

It's based on a recent event where I discovered that you were spreading misinformation behind the scenes.

I consider you part of that group of people now since what I found out recently.

Can you share this information with us as well? I would be interested in that.

[thestinger]

@mar-v-in Whether or not you want to acknowledge your involvement in malicious attacks on GrapheneOS, we're aware that you have been. If you're going to continue working with abusive people and engaging in spreading misinformation yourself then you can expect an ongoing response to begin. If you choose to collaborate with CalyxOS and to attack us, then be aware that anything that group has done to me is entirely fair game in response. I'll give you folks 4 weeks to start retracting the inaccurate attacks on us and beginning to repair the harm caused to us. At that point, anything done to us by your group is fair game in response.

Can pretend all you want that you aren't involved with them and that you weren't involved in anything sketchy involving FSFE and other organizations but it won't make a difference because I know better.

[mar-v-in]

@thestinger I choose to continue not collaborating with CalyxOS or the Calyx Institute. As I already mentioned, I did not decide to work with them when they asked once.

As you mention FSFE here again: I do know several people working/volunteering for the FSFE and also am a supporter of the FSFE. Sometimes FSFE folks ask me for input on their Android related campaigns. The only occasion where GrapheneOS popped up in my conversation history with them, we a mention related to the Upcycling Android compaign. The Upcycling Android campaign is about extending the lifetime of devices by installing an alternative OS with a newer Android version and thus reducing the waste related to smartphone use. While in most cases, updating to alternative OS also increases the security of the system, high security is not a primary concern of the campaign. In this context, I mentioned that GrapheneOS does not support any devices beyond manufacturer support (official updates from Google). This was true at the time and I think is still true today - the oldest device listed as supported by GrapheneOS is the Pixel 3 (tagged as legacy), which also got Android 12 directly from Google. This statement may have ultimate resulted in GrapheneOS not being listed on the page (or it was due to GrapheneOS only supporting apps that require play services though installing proprietary software, which the Free Software Foundation Europe might be not a fan of). If GrapheneOS intends to support the Pixel 3 and the other currently supported devices beyond manufacturer support, I'm happy to correct my statement and let the responsible people at FSFE know about this.

[thestinger]

You made numerous completely false claims about GrapheneOS and about other operating systems. You falsely claimed that other operating systems continue providing proper security updates past EOL when they do not. You falsely claimed that GrapheneOS drops devices as soon as the vendor does. You made numerous false claims about CalyxOS and tried to come up with excuses for them not shipping security updates for 4 months for the OS and browser. CalyxOS is being misrepresented there and it's very clear that there's substantial bias. The page pushes misinformation, as do you. It's a consistent pattern that you have a combination of being thoroughly clueless about how the platform works and about privacy/security. The alternative explanation is that it's dishonesty and manipulative behavior. I think it's quite clearly a mix of both. Regardless, it hasn't gone unnoticed. This was the latest in a series of incidents which have now led to a substantial and ongoing response being planned and put in motion.

Using microG to run apps including the proprietary Play services SDK is also using proprietary service. microG itself includes and uses proprietary services and software. Perhaps they wouldn't be advertising it if they had a better understanding of what it provides and how it works because it goes far against what they usually enforce.

You folks have tried to cut off our funding, contributors, users, etc. on many occasions across many platforms. You've chosen to be one of them and will be treated as such. You work with highly abusive people and engage in spreading misinformation about your own software, theirs and ours. You can expect retaliation over the next few years. I'm willing to put substantial resources into specifically retaliating against microG and any contributors to it.

[thestinger]

What devices actually need to extend their lifetime is proper maintenance including bug fixes and privacy/security updates. An unstable upgrade to a new major release of the OS which doesn't come anywhere close to passing the CTS/CDD and doesn't provide privacy/security updates is not a solution. A device could be properly supported for 3 years on the same major release of the OS as long as there was vendor support. Pixels with ongoing support were upgraded to Android 12. There was immediately no longer support for Pixels running Android 11. There were not privacy/security updates or bug fixes for that anymore, and CalyxOS did not work around that. They went 4 months without privacy/security updates. They did 2 very incomplete partial updates and then missed the next 2 months. You tried to cover for that, and misrepresented what had happened. You did the same for their lack of browser engine updates and made it seem as if people could simply use a different browser, while they'd still have an out-of-date exploitable WebView. Several of the vulnerabilities in question have been detected as being exploited in the wild. It isn't theoretical that those vulnerabilities were being mass exploited. It's known. What's not known is how far beyond those few caught by Google and others being exploited in the wild were also used in both mass attacks and targeted attacks far less likely to be caught.

GrapheneOS provided a year of extended support for the Pixel 2 and will be providing at least a year for the Pixel 3. This extended support is something we discourage people from using, because it is no longer secure and therefore can't be considered private either. You won't see us misleading people into thinking that. We could continue providing extended support releases for another 2 years beyond that with an increasingly small subset of the patches since only AOSP patches would be available. I don't see how you can claim we don't provide extended support. We're just a lot more honest about it (something in short supply with you folks) and we don't set a dishonest security patch level as operating systems like LineageOS do to cover up that they do not have the latest Android security patch level despite shipping the latest AOSP patches. They have only half the updates, and the whole point of the patch level is that it's a simple holistic timestamp.

I don't particularly want GrapheneOS listed on a page presenting CalyxOS as somehow being security focused when it literally fell 4 months behind on security updates, covered up the severity of it, and makes a bunch of ill advised changes breaking the OS and app security model. Same goes for all the other misinformation there. Doesn't mean I'm okay with the fact people are spreading misinformation about GrapheneOS and in support of a malicious project (CalyxOS). That page ended up being thoroughly inaccurate, but it does promote your software. The part that I consider important is that I see you've sided with them, chosen to work with them, chosen to promote their software and cover up the flaws in it and are spreading misinformation harmful to us.

No clue why CalyxOS would be listed there if the point is supposed to be bringing extended support to devices and yet you don't consider the extended support we provide as qualifying. As usual, some very strange and self-serving claims, just as you're doing with Play services.

[mar-v-in]

You falsely claimed that GrapheneOS drops devices as soon as the vendor does.

As I stated, I'm happy to report to FSFE if GrapheneOS makes a public statement that they plan to support devices longer than the original vendor. All the devices currently supported by GrapheneOS still receive updates by Google.

microG itself includes proprietary software.

The source code to build microG is fully available. I invite you to point me where microG includes proprietary code, as I'd be glad to learn about this to get rid of it. Of course, microG may be used to execute proprietary code on user request, but it shouldn't include such.

---

In many of your statements, you are apparently referring to an e-Mail I sent to FSFE regarding CalyxOS. This e-Mail wasn't public, you were none of its recipients. Also the e-Mail was in German, so I guess you either got a bad summary, a bad translation or statements used completely out of context that caused this misunderstanding.

You falsely claimed that other operating systems continue providing proper security updates past EOL when they do not.

No, I described that AOSP security updates are currently provided for Android versions 9 to 12 but even with those one still lacks device specific files like drivers and firmware if there is no update from the vendor itself. I explained that this applies to almost all devices supported by LineageOS.

You made numerous false claims about CalyxOS and tried to come up with excuses for them not shipping security updates for 4 months for the OS and browser.

I merely said that CalyxOS, even when they lacked 2 months of AOSP updates and 2 additional months of device specific updates, was still probably more secure than LineageOS. Remember that this was in context of the Upcycling Android campaign which at the time mentioned CalyxOS, LineageOS and Replicant OS and the question was if, for security reasons, one should remove CalyxOS. Given that at the time the question came up (Jan 7), CalyxOS already announced they'll have the Android 12 available in short time and given that neither LineageOS and Replicant OS can be considered a more secure alternative, I advised to not remove CalyxOS at that point.

What devices actually need to extend their lifetime is proper maintenance including bug fixes and privacy/security updates.

I totally agree, but unfortunately, the majority of devices don't receive proper maintenance and only a few very expensive ones do. Those devices already exist and trashing them would already be a waste of resources. Some people think that keeping those insecure devices around is worse it for the benefit of environment. Your opinion may differ. When buying new devices, one should obviously prefer sustainable devices that receive maintenance, but unfortunately, those are often priced to high for many people.

Pixels with ongoing support were upgraded to Android 12. There was immediately no longer support for Pixels running Android 11. There were not privacy/security updates or bug fixes for that anymore

That's not entirely correct. While there were no updates for the device specific files like drivers or firmware, AOSP itself still got security updates and those could easily be used with Pixel devices.

You did the same for their lack of browser engine updates and made it seem as if people could simply use a different browser

I merely stated that one should not rely on the browser of the OS and instead source the browser from somewhere else to get timely security updates. This was a general suggestion, unrelated to CalyxOS.

No clue why CalyxOS would be listed there if the point is supposed to be bringing extended support to devices and yet you don't consider the extended support we provide as qualifying.

CalyxOS provided an update with latest AOSP 11 for the Pixel 2 and Xiaomi Mi A2 just 3 days ago. Yes, this update does not include any device specific security updates (due to them being not available from the vendor), but it does have a recent version of AOSP and includes AOSP related security updates. I'm not directly involved with any decision making of the Upcycling Android campaign, but I guess this could be a reason.

[thestinger]

As I stated, I'm happy to report to FSFE if GrapheneOS makes a public statement that they plan to support devices longer than the original vendor. All the devices currently supported by GrapheneOS still receive updates by Google.

This is untrue as was already explained. We already state that we provide extended support releases from EOL until the next major release at minimum. That's already there and has been for a long time. I just explained that we provided a year of extended support for the Pixel 2 and that we're well until doing that for the EOL since October 2021 Pixel 3...

The source code to build microG is fully available. I invite you to point me where microG includes proprietary code, as I'd be glad to learn about this to get rid of it. Of course, microG may be used to execute proprietary code on user request, but it shouldn't include such.

It uses proprietary services, uses proprietary code itself and does not change that the apps using it are using proprietary Google libraries. The entire purpose of microG is using proprietary code, just as the purpose of our sandboxed Google Play compatibility layer is to make proprietary code compatible. We don't include the proprietary code in the OS, and as is we don't provide a way to obtain it in the OS since our app repository client isn't integrated, which will have a separate section for those mirrored apps.

No, I described that AOSP security updates are currently provided for Android versions 9 to 12 but even with those one still lacks device specific files like drivers and firmware if there is no update from the vendor itself. I explained that this applies to almost all devices supported by LineageOS.

This was not their account.

I merely said that CalyxOS, even when they lacked 2 months of AOSP updates and 2 additional months of device specific updates, was still probably more secure than LineageOS. Remember that this was in context of the Upcycling Android campaign which at the time mentioned CalyxOS, LineageOS and Replicant OS and the question was if, for security reasons, one should remove CalyxOS. Given that at the time the question came up (Jan 7), CalyxOS already announced they'll have the Android 12 available in short time and given that neither LineageOS and Replicant OS can be considered a more secure alternative, I advised to not remove CalyxOS at that point.

In January they were missing to the October, November, December and January patches. They didn't ship the October and November security patches, just a subset of them. They didn't bother with incomplete December and January patches and didn't bother updating Chromium anymore since while they won't admit it, they realize that totally incomplete security patches missing half the updates have dubious utility. Even now they have not fully addressed these issues.

In many of your statements, you are apparently referring to an e-Mail I sent to FSFE regarding CalyxOS. This e-Mail wasn't public, you were none of its recipients. Also the e-Mail was in German, so I guess you either got a bad summary, a bad translation or statements used completely out of context that caused this misunderstanding.

I don't think there's any misunderstanding.

I totally agree, but unfortunately, the majority of devices don't receive proper maintenance and only a few very expensive ones do. Those devices already exist and trashing them would already be a waste of resources. Some people think that keeping those insecure devices around is worse it for the benefit of environment. Your opinion may differ. When buying new devices, one should obviously prefer sustainable devices that receive maintenance, but unfortunately, those are often priced to high for many people.

Misleading people about security makes things worse and contributes to users not buying devices with 5+ or 4+ years of support from the beginning. They wrongly think they can get the security updates through one of these aftermarket OSes which are not providing half of them and are misleading users.

That's not entirely correct. While there were no updates for the device specific files like drivers or firmware, AOSP itself still got security updates and those could easily be used with Pixel devices.

Which is only half of the updates and doesn't result in increasing the security patch level, which requires all security updates, since anything short is woefully inadequate and accomplishes little.

I merely stated that one should not rely on the browser of the OS and instead source the browser from somewhere else to get timely security updates. This was a general suggestion, unrelated to CalyxOS.

The OS provides the WebView used by many apps including many browsers.

CalyxOS provided an update with latest AOSP 11 for the Pixel 2 and Xiaomi Mi A2 just 3 days ago. Yes, this update does not include any device specific security updates (due to them being not available from the vendor), but it does have a recent version of AOSP and includes AOSP related security updates. I'm not directly involved with any decision making of the Upcycling Android campaign, but I guess this could be a reason.

It's missing far more than that. CalyxOS also didn't provide many of the security updates released for the vendor for the Xiaomi Mi A2. They make misleading and outright inaccurate claims about security just like LineageOS.

[thestinger]

Device-dependent security updates are literally half of the security updates or more since it covers the entire SoC platform. Those vulnerabilities are broadly exploitable, not something niche.

[735trv]

@thestinger

I'm willing to put substantial resources into specifically retaliating against microG and any contributors to it.

I don't think that's a good idea. It turns you from a victim into a perpetrator. I think your time is better invested in the development of GrapheneOS.

I think it would be good to have a overview of these things on the GrapheneOS website. There you can document all incidents with links to tweets and screenshots. Then the community can judge and you don't have to waste so much time.

No surprise that now our rooms (...)

Which rooms?

[thestinger]

I don't think that's a good idea. It turns you from a victim into a perpetrator. I think your time is better invested in the development of GrapheneOS.

I think it would be good to have a overview of these things on the GrapheneOS website. There you can document all incidents with links to tweets and screenshots. Then the community can judge and you don't have to waste so much time.

Posting information on our site and then sharing that in many places would be retaliation.

Which rooms?

Our chat rooms are now being raided due to this thread.

[thestinger]

These attacks are supported by CalyxOS and they've refused to ban people from their community who openly participate in them and encourage them. It's no coincidence that multiple people start cycling through accounts raiding our rooms with their usual nonsense once this thread becomes active. It hasn't happened for days. Not interested in hearing excuses about why a group which refuses to address abusive behavior and even openly encourages it isn't responsible for their community doing what they want them to do. It's not our community being raided and having the channel disrupted all the time which is the problem here.

[mar-v-in]

EOL since October 2021 Pixel 3

You are probably aware that Google provided an update for the Pixel 3 just a few days ago.

The entire purpose of microG is using proprietary code

This is entirely incorrect. Don't claim what the purpose of a project is that you are not involved with. As I already explained to you, microG is not only the service, but also the client library, so that apps can decide to not use the proprietary Google libraries while still being compatible with them. CCTG (fork of German CWA for Exposure Notifications based contact tracing) use microG to provide an enitrely free software variant to an app normally only available with proprietary Google services and libraries. This is the purpose of microG: go with as little proprietary code and services as possible.

I don't think there's any misunderstanding.

If there is no misunderstanding, do you agree that with respect to security: GrapheneOS > CalyxOS > CalyxOS lacking 2 months of AOSP and 4 months of device security updates > LineageOS (with > meaning the left side is providing better security)? Because I never said something else.

If you deduct from me arguing CalyxOS > LineageOS that I think CalyxOS > GrapheneOS, then this is entirely your fault and nothing you can blame me for.

Our chat rooms are now being raided due to this thread.

While I do feel sorry for you having issues with people in your chat rooms, I'd like to point out that I have not asked you to comment here. We could have easily had this conversation in private using e-Mail or XMPP. Also, people linking to this thread should be in your favor, because I repeatedly said that it is my opinion that GrapheneOS provides better security than CalyxOS.

[thestinger]

You are probably aware that Google provided an update for the Pixel 3 just a few days ago.

Seemingly unlike you, I'm aware that it was not a security update and is just a carrier-specific release. It helps to know the subject matter you're talking about. You constantly bullshit, fabricate and manipulate. This is yet another example. You shouldn't be in this industry. You've caused massive harm to users already and continue doing it.

This is entirely incorrect. Don't claim what the purpose of a project is that you are not involved with. As I already explained to you, microG is not only the service, but also the client library, so that apps can decide to not use the proprietary Google libraries while still being compatible with them. CCTG (fork of German CWA for Exposure Notifications based contact tracing) use microG to provide an enitrely free software variant to an app normally only available with proprietary Google services and libraries. This is the purpose of microG: go with as little proprietary code and services as possible.

microG uses proprietary services, proprietary code and is called from proprietary code. It has untrustworthy developers engaged in underhanded attacks, constantly spreading misinformation and harassment. You've picked an example where you were involved in unnecessarily using your own code as another form of self-promotion. It makes absolutely no sense to unnecessarily tie it to your project.

If there is no misunderstanding, do you agree that with respect to security:

I won't engage in a strawman argument with no relevance to any of this.

While I do feel sorry for you having issues with people in your chat rooms, I'd like to point out that I have not asked you to comment here. We could have easily had this conversation in private using e-Mail or XMPP. Also, people linking to this thread should be in your favor, because I repeatedly said that it is my opinion that GrapheneOS provides better security than CalyxOS.

GrapheneOS provides far better privacy and broader app compatibility. I'm not interested in the CalyxOS and microG misinformation narrative where you pretend to be supportive while trying to harm us and trying to portray it as a niche OS not usable by regular people. We're not the ones making hobbyist software with fake privacy/security features which depends on a few groups doing the same thing supporting/promoting each other without merit based on nepotism. That's all you.

[735trv]

@thestinger I think that attacks are not helpful, no matter from which party. I think GrapheneOS is really interesting project, but the way you write here. This aggressive way doesn't seem professional and doesn't help anyone. If you want to do something, do this overview. An uncommented collection of links of evidence.

I've worked as a developer for a long time and I know that politics is difficult for developers. I struggled for a long time to choose the right words for customers, but the way you write here. No, sorry that's not okay. :-1:

[mar-v-in]

microG uses proprietary services, proprietary code and is called from proprietary code

microG only uses proprietary services on user demand. microG only executes proprietary code on user demand (and this specifically is mentioned to the user before it happens). microG is only called from proprietary code, if the user decides to install proprietary apps. None of this has to happen when the user decides they don't want to and microG will still have a purpose.

You've picked an example where you were involved in unnecessarily using your own code as another form of self-promotion. It makes absolutely no sense to unnecessarily tie it to your project.

Google's Exposure Notification implementation consists of two proprietary parts:

• The client library that is embedded into the app using it (CWA in this example)
• The service running inside the Play Services com.google.android.gms application

microG provides a free software implementation of those two. This means that the CWA using the proprietary library can use the microG implementation of com.google.android.gms as a service and a fork of CWA that uses the microG client library can work with the original Play Service com.google.android.gms or the microG version.

CCTG took both parts and merged them into the CWA, so that no com.google.android.gms package is required at all. Of course one could have created an implementation of Exposure Notifications that does not the same splitting of Google, but it also doesn't hurt to do so. Because it is about re-implementing proprietary Google apps and libraries, it totally matches the goal of microG.

GrapheneOS provides far better privacy and broader app compatibility.

Not using a phone provides even better privacy and using original Google OS provides even better app compatibility. None of this is the point.

microG is a way to run less proprietary code and expose less personal data to Google than using the original Google Play Services without having too much negative impact on app compatibility. Of course some apps will not work as expected with microG. Of course some personal data can still end up with Google, especially when optional features like push notifications are used.

I'm fine with you calling microG what it is: a hobby project. It doesn't have commercial quality like Google's Play Services and never will. I guess every user of microG is aware that it is an open-source hobby project and did not undergo stringent security testing. That also isn't its objective. If you are aware of any security issues (outside the obvious ones related to signature spoofing and taking over the com.google.android.gms package name without app developers consent), for sure you can raise them.

clueless about how the platform works

I guess we have different understanding about how a mobile OS platform should work. This is independent on how it works today. You are saying that microG is against the principles of the platform because it allows to change how apps work against the will of the app's developer. That's a fair point. I'm saying the platform should prefer user interests over app developer interests. Just like adblocker extensions modify browsers to prefer user interests over website owner interests.

---

I agree with @735trv. Please put up a list of malicious activity of CalyxOS. I'll happily forward this list to those that suggest CalyxOS. I'm already putting resources into allowing users to fully use microG without signature spoofing, so GrapheneOS users that will be able to use microG with only minimal restrictions, if they want so.

[thestinger]

I think that attacks are not helpful, no matter from which party. I think GrapheneOS is really interesting project, but the way you write here. This aggressive way doesn't seem professional and doesn't help anyone. If you want to do something, do this overview. An uncommented collection of links of evidence.

We're not the ones engaging in underhanded attacks. I don't need your input about the tone of my response to that.

[735trv]

We're not the ones engaging in underhanded attacks.

That's not the point.

I don't need your input about the tone of my response to that.

Well, okay then not. Was just a suggestion, because your tone is really bad. If you do not care, okay. Do what you want.

---

@mar-v-in If you get such a list, I would be happy if you write it here or let me know otherwise. I would be very interested in this list.

[thestinger]

If my tone gets across the fact that I'm extremely pissed off then everything is as it should be right now.

[735trv]

I don't know who benefits from that. Well then, congratulations?

[thestinger]

microG only uses proprietary services on user demand. microG only executes proprietary code on user demand (and this specifically is mentioned to the user before it happens). microG is only called from proprietary code, if the user decides to install proprietary apps. None of this has to happen when the user decides they don't want to and microG will still have a purpose.

Which is another way of saying that microG uses proprietary services, proprietary code and is called from proprietary code particularly when almost anyone that is ever going to use it will use it that way. The main reason people want it is using apps with the Play services SDK, which are largely entirely proprietary, and nearly all of them want features like FCM to work or they wouldn't be using microG.

What if the Play services SDK simply included a fallback implementation of FCM and other services? That's exactly what they do for many components like the Ads SDK. Since they don't do it themselves, GrapheneOS made a compatibility layer to coerce it into working that way inside the app sandbox. The compatibility layer has the sole purpose of making apps using the proprietary Play services SDK work properly. It has no use for anything else. I don't see how what we do is somehow bad but your way isn't. In reality everything people want to use with it is using proprietary Google Play code regardless. We don't see a reason to reimplement their services rather than not allowing them to get any additional data than the client libraries. Redirection of APIs to other implementations is something we already implement as an option. Our goal is getting their proprietary client SDK working and running the service side in the same app sandbox is the obvious way to do it without trusting them more. If people absolutely don't want to use Play, they can't use those apps anyway. From our perspective we're just fixing a problem they should be forced to fix themselves with fallback code in Play services to make it work without privileges, and perhaps also in more libraries to make them work without it. We would prefer not having to do anything and that is what we want long term.

CCTG took both parts and merged them into the CWA, so that no com.google.android.gms package is required at all. Of course one could have created an implementation of Exposure Notifications that does not the same splitting of Google, but it also doesn't hurt to do so. Because it is about re-implementing proprietary Google apps and libraries, it totally matches the goal of microG.

Which is unnecessarily tied to microG instead of being a standalone implementation used by microG and this app. It doesn't use microG beyond working around the way this was written. Shared code with another project in a convoluted way, sure.

microG is a way to run less proprietary code and expose less personal data to Google than using the original Google Play Services without having too much negative impact on app compatibility. Of course some apps will not work as expected with microG. Of course some personal data can still end up with Google, especially when optional features like push notifications are used.

Many apps don't work properly. Privacy also isn't only from Google. It's also from other apps, other services and attackers. Those apps are entirely capable of using Google services without Play services, and many of those libraries know how to do it. Having Play services as a regular app doesn't grant Play any more access than it has via being included as a library in an app.

I guess we have different understanding about how a mobile OS platform should work. This is independent on how it works today. You are saying that microG is against the principles of the platform because it allows to change how apps work against the will of the app's developer. That's a fair point. I'm saying the platform should prefer user interests over app developer interests. Just like adblocker extensions modify browsers to prefer user interests over website owner interests.

We don't include spoofing because it coerces apps into trusting microG which does not implement all of the same security model and security checks. This isn't only a security issue but also a privacy one. There's a difference between trusting Google with certain data like Google account credentials vs. trusting people reverse engineering their protocols who are focused on getting stuff working and don't care much about the security model of the platform or those services.

Please put up a list of malicious activity of CalyxOS.

I'm not providing a list of ready to go attacks on GrapheneOS and myself to share. Information is published on our site and in our community when it makes sense. When we've finished up winning the current legal conflict then we'll shift focus to a very calculated and coordinated effort to win this currently one-sided war waged against us. I'm not going to make it easy to come up with excuses and talking points in advance.

[mar-v-in]

The main reason people want it is using apps with the Play services SDK, which are largely entirely proprietary, and nearly all of them want features like FCM to work or they wouldn't be using microG.

There are multiple features provided by microG that are realized without using the Google services normally contacted. Vision SDK (barcode scanning), Maps SDK (microG uses OpenStreetMap instead), Network-based locations (microG can use Mozilla or local database instead), to just name the most important ones. FCM and registering microG with the Google servers are entirely optional features.

What if the Play services SDK simply included a fallback implementation of FCM and other services? That's exactly what they do for many components like the Ads SDK.

Google is not going to move any relevant parts of Play Services SDK into the apps itself. If the implementation runs in the App itself, it's much harder to combine data across apps for better tracking. Ads SDK are exceptions because they also wanted to monetize users that don't have Play Services (like in China). Some of the older Firebase SDKs are also available with fallback inside the app, because Firebase was originally not part of Play Services (as it wasn't owned by Google).

Which is unnecessarily tied to microG instead of being a standalone implementation used by microG and this app.

This is a standalone implementation that is developed by me, mostly for microG. But it is available as a standalone maven library that can be used by everyone. Again: microG is about open source re-implementations of proprietary Google SDK featues. It's not a requirement that it's accessed via the com.google.android.gms or any other package name. We do this to allow easy drop-in and full compatibility, but it's not required.

Those apps are entirely capable of using Google services without Play services

The question is not always what apps and libraries could do, but more what they actually do. Every ad blocker could be bypassed, but in practice they are still rather effective.

We don't include spoofing because it coerces apps into trusting microG

That's totally fine. You did a decision for your operating system to allow apps to decide whom to trust. I prefer to allow users to be able to force their decision on whom to trust on apps, but that obviously opens the door for security issues. Again this is like browser extensions: they can actually modify the browser to send all web requests with all their private data and credentials to a third party without the websites knowing. The user decides which apps they want to trust and give the permission to modify all other apps behavior.

the current legal conflict

Which apparently doesn't involve me (as I haven't received any letters from any lawyers recently). This makes it impossible for me to defend against your accusations as I don't really know what the accusations are.

[thestinger]

There are multiple features provided by microG that are realized without using the Google services normally contacted. Vision SDK (barcode scanning), Maps SDK (microG uses OpenStreetMap instead), Network-based locations (microG can use Mozilla or local database instead), to just name the most important ones. FCM and registering microG with the Google servers are entirely optional features.

I don't see why any of this needs to be exclusive from being able to use Play services as a regular app. Not the approach we're taking to reimplementing APIs.

It's entirely optional for someone to use Google services with sandboxed Google Play since they can toggle off Network access and it works fine. Many apps also work with GSF alone and don't require GMS anyway.

This is a standalone implementation that is developed by me, mostly for microG. But it is available as a standalone maven library that can be used by everyone. Again: microG is about open source re-implementations of proprietary Google SDK featues. It's not a requirement that it's accessed via the com.google.android.gms or any other package name. We do this to allow easy drop-in and full compatibility, but it's not required.

In which case the app is not using the Play services API and could be using any other library for this instead. There's no particular reason it needs to be an incomplete implementation of a Play services SDK API. Many improvements could be done through not sticking to that. If they didn't actually start with the Play services API then I don't see why that would be used. Very few apps are interested in using something else, even just different client libraries, and very few do it.

The question is not always what apps and libraries could do, but more what they actually do. Every ad blocker could be bypassed, but in practice they are still rather effective.

They use tons of other libraries and SDKs too. You address one of them in a special way and it's very incomplete. Why isn't there a microG equivalent for Facebook SDKs and tons of other libraries/SDKs? I don't see how it's a viable approach in general, especially when apps are often simply using APIs directly either in their app or from their server where you don't get to change how they work. Google is entirely capable of teaching the SDK to stop using alternate implementations and also of adding fallback code for more of the APIs within apps.

I don't know why you're so sure that they aren't going to update the signature checks and fix them so that they apply to everything instead of only certain things. Also don't see why you're so sure they aren't going to decide they want functionality working elsewhere. If they benefit from people using their services such as they do with the Ads SDK, then why wouldn't they make more of it work for everyone? I would bet that they are even going to be forced to start decoupling these things from an anti-competitive licensing model cracking down on alternatives. Their mostly all or nothing approach clearly isn't going to last.

I prefer to allow users to be able to force their decision on whom to trust on apps, but that obviously opens the door for security issues. Again this is like browser extensions: they can actually modify the browser to send all web requests with all their private data and credentials to a third party without the websites knowing. The user decides which apps they want to trust and give the permission to modify all other apps behavior.

It's not only the user who can do this. It's also not at all implied they take everything into account and truly consent to what's happening just because they set it up.

Which apparently doesn't involve me (as I haven't received any letters from any lawyers recently). This makes it impossible for me to defend against your accusations as I don't really know what the accusations are.

Legal action against the people involved in the more recent attacks hasn't started yet, but it will.

[thestinger]

It's entirely optional for someone to use Google services with sandboxed Google Play since they can toggle off Network access and it works fine. Many apps also work with GSF alone and don't require GMS anyway.

Of course, apps can and do just use Google APIs themselves.

[thestinger]

Meanwhile, the raids on our rooms have continued and escalated. Multiple people involved are part of the CalyxOS community and welcomed there. What isn't seen from the context of this thread is the spam in our rooms telling me to kill myself repeatedly and pushing the usual inaccurate talking points. After dealing with this all day for multiple days I do not expect why the other side would expect civility. Our community is not spamming your chat rooms, issue trackers, etc. but maybe they should be when we have dealt with it for years.

[735trv]

@thestinger

I'm not providing a list of ready to go attacks on GrapheneOS and myself to share. Information is published on our site and in our community when it makes sense.

Has anything ever been published?

When we've finished up winning the current legal conflict (...)

Which legal conflict?

I do not expect why the other side would expect civility.

It's not the other side that expects civility. I expect civility from a leader. If anyone want respect, then be civil and professional.

What isn't seen from the context of this thread is the spam in our rooms telling me to kill myself repeatedly and pushing the usual inaccurate talking points.

Did you take screenshots of it or record it in some other way?

[akc3n]

@735trv

It's not the other side that expects civility. I expect civility from a leader. If anyone want respect, then be civil and professional.

If you were in his shoes, and this had been going on against you, while you were developing one the most advanced and hardened mobile OS's, face hurdle after hurdle from every which way that is not even relevant to the challenges that come with the coding and the project - while giving it out for free, - how would you feel?

I'd say that he has done an amazing job at pushing forward and overcoming all of these things, both as a human and as a developer.

I would not wish that - what is going on to Daniel - even on to my own worst enemy's (mostly bullies from elementary and middle school days! ya, ya its a long ago, but still haunts me and I'm in my late 30s).

Did you take screenshots of it or record it in some other way?

Yes, of course.

Just like all the evidence over the last year+ too - that everyone keeps saying to show proof of. No need for us to do so! Why would we? That makes no sense at all.

We aren't adolescents.

This will be dealt with professionally and legally.

[735trv]

@akc3n

If you were in his shoes (...) how would you feel?

I struggle with that too, but I let my work and the results speak for themselves. I was a simple developer and am currently a freelancer. There I have to do also with very strange customers. But mostly everyone is satisfied with the results. I don't have time for that kind of nonsense. I can take the time for it, but why?

Just like all the evidence over the last year+ too, that everyone keeps saying to show proof of. No need for us to do so, why would we? That makes no sense at all.

Of course, that makes sense. As an external party, you currently only have the word of one party. Nowadays, you need evidence more than usual.

[thestinger]

Has anything ever been published?

Yes, it has, but I have no interest in trying to prove something to malicious trolls.

[thestinger]

It's not the other side that expects civility. I expect civility from a leader. If anyone want respect, then be civil and professional.

Their leadership is involved in harassment and bullying. @mar-v-in is involved in spreading misinformation and making underhanded attacks. Don't expect the response to all of this to be gentle. They don't belong in the industry.