Yes, for small, especially non-IT businesses, it’s really hard. But thank you again for the article, I think we might (unfortunately) need such setup for different other things in the near future too.

There’s only one thing you can do: stop using it, stop giving them [an opportunity to use your data for] money. Everything other solution is mediocre at best. Thanks for sharing, though.

No, they’re just morons and sadists.

Fuck them.

No, the actual AI runs locally, on the phone. What MLKit does is two things:

1. Downloads the actual AI models from Google’s servers — not sure, but maybe they can be bundled or downloaded from other sources.

2. Send the usage analytics about those models — again, don’t remember exactly what’s being sent but the actual prompts/source images/model responses shouldn’t be sent in normal operation.

Why I highlighted the normal operation thing is because Google is kinda famous for collecting data it shouldn’t be collecting, e.g. read this README for example: https://github.com/PlqnK/magisk-supl-replacer

Not to bash them or something, but just FYI: I got interested in how they’ve implemented AI client-side, and they use Android MLKit in their Android app for that.

The problem with MLKit is that it phones back to… ta-dam!.. Google, even if it’s not actually used by the app, and that telemetry can’t be legally (and neither in any convenient and reliable way te technically) disabled, even by the app developer.

It doesn’t seem to be sending any sensitive information in that telemetry, but I don’t know Rick: changing Google for… Google?

Yes, with something like OpenRouter (or Mistral’s own API) you should be able to integrate it everywhere. Also, OpenRouter, while being a US company AFAIK, seems to be pretty transparent and lets you evaluate a lot of models from different developers and running on different platforms.

I’ve used their devstral (latest one) + goose for a side project. It worked pretty decently, on par with Claude 3.7-ish Sonnet, maybe even better. And it’s not the largest: 123B. If you can have access to their larger models, that should be even better.

No. Sorry, Microslop.

No, that might hurt someone’s feelings, so if you do that you’ll be banned from the platform, your data will perish and your whole online personality will be canceled eventually. Welcome to the modern internet :)

Fuckers.

It’s also useful to have a look at this great resource: https://eylenburg.github.io/android_comparison.htm

GrapheneOS pretty much solved the closed device trees issue you’re referring to. They don’t need them anymore and use their own toolchain to workaround the issues.

The problem with Pixel 10 was different: it was released with Android 16 QPR1 out-of-the-box, but this very QPR1 hasn’t been pushed to AOSP until a couple of weeks ago. This is why the GrapheneOS build for Pixel 10 was not possible: they could not/didn’t want to port the older Android 16 OS to Pixel 10’s hardware, and they didn’t have the source code of the QPR1 to build GrapheneOS on top of it.

Now the QPR1 (and currently even the QPR2) has been pushed to AOSP, so GrapheneOS has released Android 16 QPR1-based GrapheneOS both for older phones and for Pixel 10.

who we can trust with our personal data

Well, the answer to that question is extremely easy: “no one” :)

But that’s a nice article, thanks for sharing.

Yes, unfortunately. It’s their con, but also their pro at the same time. It’s bad because they end up isolated from everyone else playing nice with each other, and then no one wants to deal with them, but they also don’t agree on compromises that might hinder security or the stability and development of their project. And I respect that. That is partly a reason why they created probably the most secure and private AOSP distrubution nowadays.

They can, but it’s not their goal. Their goal is to have control over 99% of Android phones produced and not let their users install adblock or NewPipe, or torrent app or whatever.

There’s GrapheneOS that I think would try to address this problem — secure, proper architecture, compatible with some major app stack (e.g. Android apps). It’s AOSP-based, but they’re already thinking ahead up to a point where they would be forced to fork it and even work with OEMs to create their own phone hardware for it. There are a couple of threads on their Mastodon.

I don’t know how much they would be able to achieve, but I would pay for such system.

This. And obviously to ban all the things like adblockers, NewPipe, custom browsers, etc that give people any kind of relief from Google’s digital slavery.

It has nothing to do with KeepassXC, it’s still early development and you won’t be able to backup or extract your passkeys because it stores them in the hardware secure element on the phone (if it’s available), but it works: https://git.noisruker.de/Juhu1705/open-passkey-authenticator

Dude, that’s a pizza cutter…