As an example, if you install the YouTube app, the OS will fetch assetlinks.json for the domains it claims to be authorized to handle including m.youtube.com/.well-known/asse for m.youtube.com, etc.

For NewPipe, users need to manually enable app link handling for the domain.

Can disable the Network permission added by GrapheneOS for the Intent Filter Verification Service if you don't want automatic verification for app links.

App link handling changed substantially in Android 12 and has a hard requirement for either verification or user consent now.

We may add a direct toggle for verification in the future rather than only the ability to prevent the verification service from making network requests. It's a low priority since that works fine and it already does extreme throttling for subsequent attempts to verify the links.

Our usage guide now includes a section on Android app link verification:

grapheneos.org/usage#app-link-

This regularly comes up as a question from users monitoring network requests where they'll see the Intent Filter Verification Service verifying app links after installing a new app.

Our app repository client will be included in the OS within a few weeks. It will help a lot with sandboxed Google Play since it will be trivial for users to install it instead of needing to manually download and install apks. We can also include a page for it in our setup wizard.

We'll be adding separate sections in the interface for the app repository client to clearly differentiate between our first party apps, first party builds of other open source apps and our mirror of the official Google Play apps for easily installing sandboxed Google Play.

Our usage guide section on sandboxed Google Play has been updated to cover our added support for Play Asset Delivery, Play Feature Delivery and Play Games Services:

grapheneos.org/usage#sandboxed

Play Games Services works well once you install Google Play Games from the Play Store.

It also provides a detailed explanation on the Play Store providing services used by apps including the newly supported Play Asset Delivery and Play Feature Delivery.

It should now be clearer that Play Store isn't mandatory to use sandboxed Google Play but is a major part of it.

GrapheneOS version 2022011423 released: grapheneos.org/releases#202201.

See the linked release notes for a summary of the improvements over the previous release.

Since our compatibility layer provides support for the Play Store in addition to Play services, we'll be referring to it as sandboxed Google Play instead of sandboxed Play services. Our site is updated:

grapheneos.org/usage#sandboxed

Sandboxed Play services refers to a subset of it.

Next release of GrapheneOS will extend our sandboxed Google Play compatibility layer with support for Play Asset Delivery and Play Feature Delivery.

github.com/GrapheneOS/platform

This is simply an extension of the hooks added for Play Games Services compatibility to the Play Store.

Our compatibility layer already provides full support for installing, updating and uninstalling apps with the Play Store including Android 12 unattended update support by teaching it how to use the unprivileged APIs. Now it will be able to deliver dynamic assets and features too.

Light configuration preserves all the strong baseline security properties. It still has fully out-of-line metadata in a statically reserved region. It still has a separate statically reserved region for each <= 128k size class. It still has a high entropy random base for each.

Core optional security features are still enabled in light configuration: zero-on-free, random canaries with leading zero for <= 128k, randomized guard regions around each > 128k allocation, FIFO + random virtual memory quarantine for > 128k, etc. Still very security focused.

Light configuration has comparable performance to glibc malloc with the thread cache disabled.

It would be easy to offer the option of array-based thread caching but enabling it would break important security properties. It wouldn't be a sensible compromise and isn't planned.

We may add thread-local batched allocation for the smallest size classes via thread-local arrays. It isn't possible to provide batched deallocation without losing important security properties. Using the same cache for both would eliminate even more important security properties.

Packagers shipped hardened_malloc as a dynamic library usable by system administrators are strongly recommended to ship both libhardened_malloc.so with the default configuration and libhardened_malloc-light.so with the new standard `light` configuration.

birdsite.xanny.family/Graphene

Running either `make` or `make VARIANT=default` will create out/libhardened_malloc.so with the default configuration defined in config/default.mk.

Running `make VARIANT=light` will create out/libhardened_malloc-light.so with the light configuration defined in config/light.mk.

Light configuration disables slot randomization within slabs, checking that memory is zeroed on allocation (write after free check) and the slab allocation quarantines (random and queue). It also raises the guard slab interval from between every slab to between every 8 slabs.

hardened_malloc version 10 released: github.com/GrapheneOS/hardened.

See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

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