We're going to be pushing out Beta releases of GrapheneOS for Android 11 in the near future. It's almost ready for broader testing. A bunch of our hardening features are going to be missing in the initial Beta releases. Still need a lot of the low-level hardening ported over.
Please use the Stable channel if you can't tolerate getting updates with serious bugs. It's extremely helpful to have people using the Beta releases and reporting problems or providing additional information. Please use the issue tracker and check for existing issues though.
If you're unsure about whether an issue should be filed or need help, please use the #grapheneos IRC / Matrix channel. Please don't directly contact specific developers report issues. The issues need to be reported to the development team as a whole, not only specific developers.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@RichFelker@GrapheneOS Treble makes it possible to easily run AOSP or GrapheneOS on any hardware providing an implementation of Android vendor APIs which have a stable versioned ABI with backwards compatibility for a few major versions of the OS. It provides an easy way to support any Android phone.
@RichFelker@GrapheneOS AOSP has official support for a few development boards with an entirely open source implementation of the vendor HALs based on Mesa, etc. It's entirely possible for a phone to provide that and Pixels will likely trend towards that and away from the Exynos tech due to Tensor SoC.
@RichFelker@GrapheneOS Treble makes it so that you can run the portable userspace portion of the OS on top of any underlying drivers, services, kernel, kernel modules, etc. used to support the hardware. GKI brings this to the kernel where any GKI kernel build can be used on any device supporting GKI.
I know several people working as software engineers at Cloudflare. According to one of them, this incident (blog.cloudflare.com/the-mistake-th…) was hardly a mistake. Cloudflare is including block lists sourced from far right evangelical groups as part of their 'family friendly' DNS service.
Cloudflare is aware their 'family friendly' DNS (1.1.1.3) isn't blocking sites like Kiwi Farms (kiwifarms . net) or Daily Stormer (stormer-daily . rw). It's a deliberate decision, despite their blog post claiming their filtering is meant to mimic SafeSearch, which filters them.
Cloudflare has not stopped using block lists sourced from hateful groups. They only stopped including the subsets explicitly marked for that purpose. Easy to see why getting porn block lists from groups producing LGBTQ block lists results in continuing to "mistakenly" block more.
Cloudflare drops sites from their service on a daily basis for having content they dislike. They remove sites with adult content, support for sex workers, etc. They also drop sites they deem to be posting spam. Cloudflare's censored 1.1.1.3 DNS blocks lots of LGBT content, etc.
They're too cowardly to stand behind their decisions so they won't mention sites like Kiwi Farms by name. Their official accounts and executives all have their replies disabled on Twitter to shut down dissent. Their free speech act is a ridiculous sham. They drop lots of sites.
Cloudflare does FAR MORE content moderation than required by law. They aren't a free speech host. They remove speech they disagree with every day. They host Kiwi Farms because they support the content on it. They dropped sites used by sex workers because they consider it immoral.
@burnt_disk@MishaalRahman It's problematic that they expose those directly. They either require user consent on a case-by-case or one-time basis despite not being runtime permissions or they have no real privacy model. Low-level permissions exist for static analysis of what apps can request at runtime.
@burnt_disk@MishaalRahman For example, request install packages allows the user to allow it as an app source and then approve app installations on a case-by-case update. Only thing that can be done without case-by-case consent is updating an app again after the user authorized an install initial/update.
@burnt_disk@MishaalRahman Another example is that QUERY_ALL_PACKAGES has no actual privacy model at this point. It would mislead users into thinking that apps without it can't query all the user installed apps when they can if they list queries for common intents like the one used for launcher activities.
@IntelTechniques It's unfortunate that you're giving a platform to someone making numerous false claims about both CalyxOS and GrapheneOS to promote CalyxOS. They're spreading misinformation about our project and are misleading people about multiple privacy and security topics.
@IntelTechniques The article in unredactedmagazine.com/issues/003.pdf by Zachary McIntosh should be corrected. They're misleading people about sandboxed Google Play and microG along with falsely claiming that the CalyxOS approach does not use Google services, when in fact CalyxOS always does.
@IntelTechniques It makes numerous inaccurate claims about CalyxOS, misleading people in a harmful way. It presents AOSP features as ones added by CalyxOS and makes inaccurate claims about the CalyxOS features. Many claims there are inaccurate marketing talking points about it.
nginx configuration enforcing rate limit based on a value in request body to implement a rate limit for Flarum's forgot password API based on email instead of only based on source IP of the request:
Could move some directives to http {} to reuse more.
nginx's limit_req runs very early in the request and $request_body only exists much later. That variable also only exists if you use a reverse proxy via proxy_pass, fastcgi_pass, etc. Have to get the value out of request body with map, add as a header and reverse proxy to itself.
Since it's a header, it can implement a rate limit with the email as the key for the rate limit zone once it proxies it to itself. Flarum treats the email value as an exact string so it can't be bypassed by adding whitespace, etc. Only problem is that 1r/m is the lowest rate.