@gvs @cliffwade Their response to corrections to inaccurate claims they made about the sandboxed Google Play compatibility layer and microG is to claim that accurate information is propaganda with no basis since it doesn't align with their views. Simply read the available documentation for the projects involved about how Google Play works and how microG works. Can see that Google Play is still running in each app using it, and that is within the same app sandbox used for sandboxed Google Play.
@gvs @cliffwade @GrapheneOS Most of the google APIs are present in microg. https://github.com/microg/GmsCore
GitHub - microg/GmsCore: Free implementation of Play Services

Free implementation of Play Services. Contribute to microg/GmsCore development by creating an account on GitHub.

GitHub
@officialneige @gvs @cliffwade It only implements a small subset of the overall Google Play APIs. It's missing major parts of the APIs and has major parts simply stubbed out. A lot is only partially implemented or incorrectly implemented. As a particularly problematic example, microG until recently allowed apps to access Location data which should not have been able to access it because they didn't implement foreground and other checks until recently. There are still other issues like that one.
@gvs @cliffwade @officialneige At https://github.com/microg/GmsCore/wiki/Implementation-Status, you can see the warning "Does not honor AppOps!" for the location service. This is because it did not enforce AppOps via the appropriate API but rather only whether the permission was granted. This meant it didn't fully enforce rules restricting the access and leaked location data in cases it shouldn't have been available. We saw changes at least partially fixing this. We aren't sure if it still leaks location data, but it did before.
Implementation Status

Free implementation of Play Services. Contribute to microg/GmsCore development by creating an account on GitHub.

GitHub
@gvs @cliffwade @officialneige We are aware of other issues. Due to their hostility towards us including spreading fabricated stories about our lead developer, endlessly spreading misinformation about GrapheneOS and sandboxed Google Play, etc. we are not going to report known issues to them. This is one of the downsides of a project engaging in harassment and other attacks on privacy/security researchers who uncover problems with their project. They cannot expect to receive help from us anymore.
@GrapheneOS @gvs @cliffwade I understand perfectly. But it's a very good thing to have audited their code. A lot of people (and I was one of them in the past) used microg thinking they have their privacy protected but it's not. It's just an open-source project built with feet and security is not at all at the heart of their program. They, fdroid, bromite and others don't give a damn about the world. It's a scandal!

@officialneige @gvs @cliffwade

Bromite is a dead project.

https://github.com/bromite/bromite/commits/master

They heavily based it on our work including our work on ad blocking which hadn't been landed in Vanadium yet. We also contributed to it. Despite that, they started being hostile towards us and stopped allowing us to use their code under a non-GPLv3 license while knowing we are unable to use GPLv3. GPLv3 isn't compatible with a WebView implementation even if we were willing to include GPLv3 licensed code...

GitHub - bromite/bromite: Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser!

Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser! - bromite/bromite

GitHub

@officialneige @gvs @cliffwade GPLv3 and Apache 2 are incompatible, and Android heavily uses Apache 2. WebView also gets loaded into applications and APIs are used by them, including extensions to the standard WebView APIs inside and outside the web context.

We responded by switching to licensing Vanadium as GPLv2-only (which is GPLv3 incompatible) with additional permissions permitting upstreaming code, Apache 2 compatibility and WebView usage similar to OpenJDK and Linux kernel exceptions.

@officialneige @gvs @cliffwade It's unsurprising to us that it's dead after losing a major source of code and alienating a bunch of their community through their subsequent partnership with abusive people and attacks on us. It's unsafe to use a browser with half a year of missing security patches. One of the developers who we have much less of an issue with is continuing it as a fork that will be rebranded to a different name. We're just going to double down on improving Vanadium much more.
@officialneige @gvs @cliffwade Vanadium will have full state partitioning support comparable to Brave soon along with ad blocking support. We'd be more interested in collaborating with Brave despite the issues with it like dependence on Play services, their ICO / centralized cryptocurrency and various missteps with replacing ads, adding referral links, etc. They still do much better privacy work than other browser projects and we could work with them on things without promoting their browser.