Dev.to Security 🔐 Cybersecurity 👁 0 📖 3 min read

Packet Notes #3: Your phone has outbound AI traffic now. Nobody shows you it.

I spend my working hours in firewall logs. Policies, sessions, denies, the usual. Then one evening I pointed the same habit at the device I actually carry, and the thing that stood out was not ads or analytics. It was AI

I spend my working hours in firewall logs. Policies, sessions, denies, the usual. Then one evening I pointed the same habit at the device I actually carry, and the thing that stood out was not ads or analytics. It was AI.

Not "an app has an AI feature". Actual bytes, leaving the phone, going to the endpoints of AI companies.

The permission model never covered this

Android's permission screen answers questions like: can this app read the camera, the mic, the contacts, the location. Good questions. They just stop short.

There is no permission for "this app sends the text you typed to a model hosted somewhere else". The INTERNET permission is granted at install time with no prompt, and once an app has it, where it connects is its own business. The permission screen is a list of maybes. It is not a log.

So the honest answer to "which of my apps talk to AI providers" is: on a stock phone, you cannot tell. Not because it is hidden maliciously, but because nothing in the stack was built to answer that question for the user.

Why this is different from the tracker problem

We have had a decade of practice with trackers. Block a domain list, done. The threat model was mostly "someone is building a profile of me".

AI traffic is a different shape:

  • The payload is usually content, not identifiers. Your draft, your photo, your question, the document you opened.
  • It is often invisible in the UI. An assistant feature can be two taps deep in a menu you never open, and still phone home.
  • The destination is a small number of very large endpoints, which makes it easy to see once you look, and easy to miss if you never do.

A tracker wants to know who you are. An AI backend wants what you wrote. For a lot of people, the second one matters more.

What I did about it

I built a firewall that runs on the phone itself. No root, no account, nothing leaves the device. One screen, AI Radar, does only this: it names the apps that are sending data to AI companies, with the byte counts. A second screen, ExfilMeter, does the same for outbound traffic in general.

The first time I opened it on my own phone, two apps were on that list that I had not thought about that day at all.

I am not going to tell you that is a scandal. It might be completely legitimate. The point is narrower and, I think, harder to argue with: you should be able to see it, and right now the platform does not let you.

Three things you can check without installing anything

  1. Settings, then your data usage per app, over the last week. Sort by background usage. Anything on that list you do not actively use is worth a question.
  2. Open the apps you use most and look for an assistant, summarise, or smart reply feature. If it exists and it is not labelled on-device, it is network traffic.
  3. Check the app's data safety section on Google Play for sharing with third parties under "app functionality". That category covers a lot.

None of that gives you a log. It gives you a shortlist.

The part I keep thinking about

Every year an app ships a feature that quietly turns local content into outbound requests, and the user-facing change is a sparkle icon. The permission model does not move. The privacy label does not really move either, because the categories were drawn before any of this.

I do not think the fix is panic or a ban. I think the fix is boring: a log on the device, readable by the person who owns the device.

What would you want on that screen? Byte counts, destination names, per-app toggles, or the actual request bodies? I genuinely cannot decide where the useful line is, and I am the one building it.

Disclosure and links

I build TacUNS, a free on-device Android firewall. No root, no account, nothing leaves the phone.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.