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.

Thankfully, this particular kind of tracking can be reduced practically to 0 with good informational hygiene: don’t give location permissions to crappy apps. Basically, don’t give it to any app (yes, google apps included), unless you’re absolutely sure this app doesn’t spy on you — or even better — doesn’t have internet access at all. Make it a rule: an app should either access internet or access your location, but never both.

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

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.

PIN code throttling can’t be implemented properly if hardware doesn’t support it. This is the very purpose of the secure element.

It has its own CPU, storage, random number generator and realtime clock. Once a secret (encryption key) is generated inside of it, it can’t get unlocked until this very tiny chip allows it. And the chip uses different kind of protections (in case of weak pins — the most prominent one is throttling using its built-in RTC clock).

If there’s no secure element, then attacker can just extract the memory chip and easily brute force the encrypted key on the much more powerful (and not throttled by RTC) hardware.

And since the PIN codes are so weak, even the strongest key derivation functions won’t help against such bruteforce.

Dude, that’s a pizza cutter…