We couldn't find a managed DNS provider with DNSSEC, TLSA, traffic steering and unmetered queries.

Could improve the DNS by using buyvm.net/anycast-vps/ for basic anycast but it's a dead end beyond NA/EU. We avoid using metered services so there aren't a lot of viable options.

If OVH had anycast IPs and the Sydney / Singapore data centers weren't metered, we could put together a decent enough DNS setup to use it for everything.

It's unfortunate nearly every host has unbounded costs via metered traffic. Not viable due to DDoS and underhanded attacks.

We now have 2x 2Gbit EU update servers on OVH with self-hosted GeoDNS steering traffic to them for releases.grapheneos.org.

Current DNS setup is very barebones (ns1 in NA, ns2 in EU, no anycast) so it's only being used for releases.grapheneos.org and staging.grapheneos.org.

GrapheneOS 2021.07.26.20 release: grapheneos.org/releases#2021.0.

See the linked release notes for an overview of the changes since the previous release.

GrapheneOS infrastructure status pages:

* nodeping.com/reports/statuseve (production)
* nodeping.com/reports/statuseve (staging)

Can click through to individual checks for detailed information.

It posts in the :grapheneos.org Matrix room when services go down or come back up.

This provides external monitoring of the services not integrated into the servers. Each of the normal checks is performed every minute.

Each service has at least one 'worldwide roam' check using randomized location each time. Other checks are set to use NYC for latency tracking.

The issue has been resolved with a rebuild. The firmware images are identical, as is every single file in each of the OS images other than an expected signing metadata difference. Only actual difference is /firmware_mnt somehow wasn't created in the vendor image for broken build.

This is an example of where reproducible builds are helpful. This is literally the only difference better the broken build and a rebuild and is obviously the cause of the observed problem of modem firmware (which provides cellular, Wi-Fi and Bluetooth) not being loaded by the OS.

It's very difficult to see how it possibly could have failed to create the /firmware_mnt directory. Since the directory wasn't created, there are further differences in the generated ext4 filesystem metadata when comparing the binary images. We've never seen this kind of issue.

Beta release for Pixel 3a XL is delayed due to some kind of strange data corruption of the release build. This is going to require investigation. It's possible that it's time to retire the 2016 workstation for serious things and make the release builds on Ryzen 5950X machine.

Play services client libraries can include functionality themselves. For example, ad library includes code in the client and works without Play services. There's a special lightweight version with a hard dependency:

developers.google.com/admob/an

Most of Play could work as a library.

GrapheneOS is bypassing the anti-competitive approach of requiring invasive OS integration to use Google services by giving these Play apps proper error handling and fallback code. They could be regulated to require they implement it like any other service provider has to do it.

All we're doing is providing shims teaching it how to work without the privileged APIs and special SELinux MAC/MLS policies.

These shims can either act as a no-op and return placeholder values or implement it in an alternative way via unprivileged APIs available to normal apps.

Shims stop it from trying to use an API that a fully sandboxed app isn't allowed to use. This stops it from getting SecurityException errors it doesn't handle. The shims can also sometimes replace the required privileged functionality with a standard unprivileged implementation.

For example, we have a work-in-progress implementation of replacing privileged background app install API used by Play with asking the user. Could use developer.android.com/referenc in Android 12.

Similar approach is needed to get dynamite modules working for many more APIs to work.

On GrapheneOS, installing the Play services apps is the same as installing any other app. Normal sandboxed apps without special privileges. All we're doing is teaching them not to crash.

Any app using Play includes Play client side libraries. This provides no additional access.

twitter.com/GrapheneOS/status/

Play compatibility layer is now much closer to fully working for secondary users. Likely needs more shims for user management and INTERACT_ACROSS_USERS APIs returning placeholder data instead of throwing SecurityException. Same as nearly all the others.

birdsite.xanny.family/Graphene

GrapheneOS 2021.07.19.18 release: grapheneos.org/releases#2021.0.

See the linked release notes for an overview of the changes since the previous release.

Replying to @GrapheneOS

Logic error vulnerabilities are much harder to defend against in a systematic way. We do have a lot of improvements that are still relevant.

It's a lot harder to get RCE on the device than it is to escape from the app sandbox. Media and Chromium site sandboxes are stronger.

Replying to @GrapheneOS

They would usually need to decide to target GrapheneOS and invest more resources into making their exploit chains portable to it.

Local privilege escalation exploits also usually involve memory corruption, but it's more common for them to use logic errors than remote code exec.

Show older
Aspie Chattr

A federated social network for aspies and other NDs to be themselves. Chat to others with ASD, ADHD, etc. Connect to the fediverse to bring in content from a whole network of niche sites and follow people who share your interests. Strict yet flexible privacy controls for your content with no ads or tracking.
This site is ready for the future with full IPv6 support