GrapheneOS developers/moderators are being impersonated across different platforms (Matrix, Telegram, Reddit) as part of the attacks on the project.

They're copying our display names, avatars and usernames. Make sure to confirm it's one of our accounts and not someone malicious.
This is one of the tactics being used to cause harm to GrapheneOS. See github.com/bromite/bromit… for a particularly damaging past incident where they impersonated Bromite's developer.

Happening more frequently now and multiple developers/moderators are being targeted this way.
People have fallen for this trick repeatedly and a lot of harm has been caused with it. It's not going to keep working for them when they're doing it so frequently.

It's unfortunate CalyxOS/Techlore have encouraged their communities to engage in these relentless attacks on us...
They're developed a bunch of dishonest talking points their community spreads about GrapheneOS across multiple platforms every day. It happens on most prominent posts discussing GrapheneOS. It's not simply their communities doing it. They've taught them to do it and encourage it.
It's our rooms being raided, so it's our rooms which end up being a mess from the endless trolling.

We regularly refute the misinformation they spread with fact-based responses. Their response to that has been playing the victim and pretending defending ourselves is aggression.
CalyxOS/Techlore are involved in increasingly intense harassment and bullying targeting our developers.

Henry (Techlore) and Nicholas Merrill have both been extensively involved in pushing the narrative that our lead developer is crazy to direct harassment/bullying towards them.
This is not simply their communities doing something without their approval. They not only approve of it and encourage it but have been the ones crafting most of the malicious talking points. They regularly encourage attacks on us and pretend us refuting those makes them victims.
We've been building archives of the underhanded by CalyxOS leadership/developers who claim to be uninvolved in it and by people they welcome in their rooms despite extensive involvement in harassment.

They welcome people who have publicly told our developers to kill themselves..
They've seriously crossed the line in the past few months and we're starting to more actively defend ourselves beyond just countering misinformation now and then. They can expect this to be brought up in any organization/project/conference any of them ever has any involvement in.
That's what the archive of the attacks is being used for rather than fruitlessly trying to convince their toxic community to stop attacking us.

They don't realize it but these underhanded attacks on us have cost them substantial funding/support already and will cost a lot more.
Further raids, impersonation, and harassment/bullying will directly result in posting threads like this one about what's happening. Each time there's another escalation of attacks, we'll be contacting multiple organizations, etc. about what's happening. There are consequences.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GrapheneOS

GrapheneOS Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GrapheneOS

13 Sep
microG does NOT provide an open source implementation of Play services. Apps using Play services integrate the closed source Google libraries which are fully capable of contacting Google services regardless of whether Play services is present, and also do so in practice too.
The implementation of the services is also still closed source. It's only an open source middleman and the Google libraries are perfectly capable of communicating with the Google services without it. It doesn't provide better privacy or security and doesn't make Play open source.
It's not as secure as the official Play services implementation and doesn't provide comparable privacy for user data. It leaks user data across apps, doesn't properly enforce the API security model and doesn't provide comparable transport security via pinning and other measures.
Read 20 tweets
11 Sep
Auditor (attestation.app/about) uses very dense QR codes for response from the Auditee device to the challenge from the Auditor device. It relies on specialized certificate chain compression with a pre-shared DEFLATE dictionary for the attestation to fit into a QR code at all.
In order to improve security of chaining trust from hardware attestation to the app, Auditor uses the very niche android:useEmbeddedDex="true" feature to disable on-device ahead-of-time compilation for the app's Kotlin/Java code. It makes the QR scanning harder on GrapheneOS.
Android uses a mix of on-device ahead-of-time (AOT) compilation and just-in-time (JIT) compilation for Java/Kotlin.

GrapheneOS disables JIT to improve security. It compensates by using full AOT compilation which results in better overall Java/Kotlin performance and battery life.
Read 5 tweets
8 Aug
GrapheneOS is just as focused on improving privacy as security. A few of the many added features:

* Sensors permission toggle
* Network permission toggle
* Wi-Fi anonymity (per-connection MAC randomization, anonymous DHCP, anonymous IPv6)

See grapheneos.org/features for more.
App sandbox on GrapheneOS also leaks significantly less data to apps. Most of our privacy improvements are under the hood and don't require user-facing interfaces.

Our improvements requiring configuration are natively integrated into the Settings app and match the standard UI.
Sensors/Network toggles are part of the standard permission UI.

Sensors toggle disables access to all sensors not covered by existing permissions and returns zeroed data.

Network toggle fully disables both direct network access and indirect via APIs requiring the permission.
Read 7 tweets
18 Jul
@GrassFedBitcoin @CalyxOS GrapheneOS is heavily focused on security enhancements making exploitation significantly harder:

grapheneos.org/features

Those other operating systems don't improve resistance against exploitation and won't provide more resistance against an exploit working against AOSP/stock.
@GrassFedBitcoin @CalyxOS The vast majority of remote code execution exploits are based on memory corruption bugs. Defending against those is a major focus of GrapheneOS. A lot of the bugs won't be exploitable beyond denial of service. In most cases, the exploits will need substantial changes at minimum.
@GrassFedBitcoin @CalyxOS If they specifically target GrapheneOS and put work into adjusting their exploit chains and finding new bugs as necessary, then they could certainly develop an exploit working against GrapheneOS. Costs will be higher and they'll usually need to specifically take it into account.
Read 7 tweets
18 Jul
GrapheneOS 2021.07.16.19 release: grapheneos.org/releases#2021.….

See the linked release notes for an overview of the changes since the previous release.
This release adds an experimental version of the highly anticipated feature for running Play services and friends as sandboxed apps without any special privileges.

Details are at grapheneos.org/usage#sandboxe….

Secondary user support and dynamite module compatibility is coming soon.
Once dynamite module compatibility is implemented, nearly all the APIs will be working. This doesn't work yet because it has no special SELinux MAC/MLS policy due to being in the normal app sandbox. We need to add shims on both ends sending the modules via standard file sharing.
Read 4 tweets
1 Jul
Play services compatibility layer in active development and an early prototype has the basics working.

It will allow users to install Play services as a regular app in specific profiles without granting it any special privileges. Most functionality can work with this approach.
Play services won't be bundled with the OS. It will be up to users to choose to install Play services in a profile.

It won't be part of the upcoming July security update release but there will likely be an initial experimental implementation ready for testing by the end of July.
This approach will be drastically more maintainable than attempting to reimplement the APIs. It will be much easier to port to new major OS versions and will provide much more of the functionality. It will also have all the usual security checks and component/server key pinning.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(