Pingo by YallaAi
Legal

Privacy Policy

Last updated: 4 September 2026

Pingo is a network toolkit for Android, published by YallaAi. There is no account, we do not collect, store, sell or share your personal information, and the only thing you ever send us is feedback you choose to send.

1. What reaches us: feedback, and nothing else

There is no sign-up and no Pingo account. We run no server that Pingo reports to in the background, and nothing about you or your network is sent to us as you use the app. There is exactly one thing you can send us, and it takes typing a message and tapping send: feedback. Where it is stored and who handles it is set out in full in section 6. Beyond it, there is:

  • No analytics and no usage tracking.
  • No advertising, and no advertising identifiers.
  • No selling or sharing of data with data brokers or with anyone else.

What that does not mean. "Nothing is sent to us" is not the same sentence as "nothing is sent", and this policy will only ever make the first one. Pingo is a network tool, and some of its checks ask a public internet service a narrow question. A few of them do it the moment you open the app. None of those services is us, and none is given anything personal unless you type it in yourself. Section 4 names every one of them, says which start on their own, and points at the switch that stops them.

2. Your data stays on your device

Scan results, saved connections, test history, settings, and the crash log described in section 6 are stored only on your device. You can erase all of it at any time by clearing the app's data or uninstalling it. Android's automatic cloud backup is switched off for Pingo, so these files are not copied to your Google Drive.

Credentials you enter for remote-access tools, and any optional API keys, are held in Android's encrypted storage on your device and are used only to make the connection you asked for.

3. When Pingo scans

Opening the app discovers devices on the network you are connected to, so the home screen has real readings rather than empty cells. That discovery happens on your local network. It can be turned off: Settings, under Measuring, has a switch called "Let Pingo check on its own".

Scanning a network reveals other people's devices as well as your own. Please only scan networks you own or are authorised to test.

4. Connections Pingo makes

Pingo is a network tool, so making connections is what it is for. Most stay on your own network: device discovery, port scan, speed-to-gateway, uptime checks, camera discovery, the new-device guard, and any SSH, SFTP or iperf session, which goes to the address you type and nowhere else.

Ping, traceroute and the uptime monitor go wherever you point them, which may be a public address rather than one on your own network. That is your choice each time, and the address is shown on screen while it runs. The ping screen also offers five suggestions to save typing: google.com, facebook.com, amazon.com, bing.com and apple.com. Tapping one pings that host, exactly as if you had typed it. Nothing is sent to any of them beyond the probe itself.

The rest of this section is about the connections that leave your network. It is meant to be complete: every third-party host Pingo can reach on the public internet is named below. If you find one that is not, that is a defect in this policy and we would like to hear about it at [email protected].

4a. What Pingo contacts on its own

An earlier version of this policy said these connections happen "only when you run that feature". That was not true of all of them, and this is the corrected version. Some run when the app opens, because a network tool that shows empty cells until you press something is not much use. They are all controlled by one switch, in Settings, under Measuring, labelled "Let Pingo check on its own". It is on by default. Turn it off and Pingo sweeps nothing and looks nothing up until you tap a scan, a test or refresh; each screen then says what has not been measured rather than showing you an old reading as a live one.

  • api.macvendors.com: when the devices sweep runs, the maker of each device it does not already recognise is looked up. Only the manufacturer prefix of that device's hardware address is sent: the first three bytes, padded with zeroes. The device-specific half never leaves your phone.
  • ipinfo.io: to show your public IP address and the name of your ISP on the home screen. As with visiting any website, your public IP is what the service sees, and it is what it answers with.
  • 1.1.1.1, port 443 (Cloudflare): the home screen times the round trip to the internet once a second while it is on screen, and the diagnostics pass uses the same anchor. It opens a connection, times it and closes it without sending anything.
  • connectivitycheck.gstatic.com, falling back to www.gstatic.com: Google's standard "am I behind a hotel login page" check. A bare request, no payload.
  • cloudflare-dns.com, falling back to dns.google then dns.quad9.net: to check DNS is answering and to time it against a public control. It resolves a small fixed set of unchanging names and nothing else: example.com, wikipedia.org, cloudflare.com and mozilla.org, one per pass in rotation, for the timing; cloudflare.com and google.com for the is-it-answering check. Never a name you looked up, and nothing about you or your network.
  • Google Play Integrity / Firebase App Check, at start-up on release builds that have it compiled in: a token attesting that this is a genuine, unmodified copy of Pingo, so that only the real app can submit feedback. No account, no network data, nothing you typed. It is, however, the one place Pingo hands over something that belongs to this installation rather than to you, so it is spelled out here rather than left implied. Google Play services on your phone produces an integrity verdict about this device and this exact copy of the app; Pingo sends that to firebaseappcheck.googleapis.com, and Google returns a short-lived App Check token, which Pingo stores on your device and attaches to a feedback submission. Treat that as an installation identifier. The verdict is produced by Google's own software from this install on this handset and it is Google that reads it, so Google is in a position to tell one installation of Pingo from another. We cannot see inside the token and will not pretend it is nothing. It exists to keep forged clients out of the feedback collection and is used for nothing else. It is not an advertising identifier; it is not used for advertising, profiling, analytics or any measurement of you; it is never joined to a name, an account, an email address or anything you typed; and it says nothing about who you are. Nor is it a Firebase installation ID: Pingo does not include the Firebase Installations component, Firebase Analytics, or any crash-reporting or advertising SDK. Uninstalling Pingo, or clearing its data, throws the stored token away, and a fresh install starts again from nothing. This is what the "Device or other IDs" line on Pingo's Play Store data-safety card refers to.

4b. What Pingo contacts only when you run that feature

  • Speed test, and the bufferbloat test: speed.cloudflare.com, and nothing else. Generated filler bytes, downloaded and uploaded, for throughput. Your public IP is visible to that server, as with any website.
  • VoIP readiness: outlook.office365.com, on port 443. Pingo opens a connection, times how long it took and closes it again, forty times over, and reads the spread of those timings to judge whether the network would hold up a call. Nothing is sent: no audio, no account, no message, no payload of any kind. That address is used because it is a well-known, dependably reachable endpoint of the sort a real call would traverse, not because the check has anything to do with your mail or your Microsoft account.
  • DNS & WHOIS, and the domain grader: data.iana.org for the registry list, then that domain's registry or registrar RDAP server, or rdap.org as a fallback; and the DNS-over-HTTPS resolvers above for the records. What is sent is the domain you typed.
  • IP lookup: data.iana.org for the registry list, then the regional internet registry's own RDAP server for that block, or rdap.org as a fallback; ipinfo.io for the location claim; and cloudflare-dns.com, dns.google or dns.quad9.net for the reverse name. What is sent is the IP address you typed, in full, to each of them, and any of them can log it. Whether the address is public at all is worked out on your phone first, and for a private, carrier-grade-NAT, loopback, link-local, multicast, documentation or otherwise reserved address nothing is sent anywhere. ipinfo.io also appears in 4a for a different reason: there it answers with the public IP of your connection and is told nothing, and here it is handed an address you chose.
  • Microsoft 365 check: login.microsoftonline.com. The domain you typed, in a synthetic address of the form user@yourdomain. Not your own address.
  • VirusTotal reputation: virustotal.com, and only if you have supplied your own API key. The URL, domain, IP or file hash you typed. Without a key Pingo makes no request at all.
  • Breach check, password: api.pwnedpasswords.com. The first five characters of a SHA-1 hash of the password, and nothing else. Your password does not leave the device.
  • Breach check, email address: cavalier.hudsonrock.com (Hudson Rock) every time, and haveibeenpwned.com only if you have supplied your own paid key. Your full email address is sent in plain text. See the note below.
  • Breach check, domain or IP address: for a domain, cavalier.hudsonrock.com, crt.sh, internetdb.shodan.io, and whichever of cloudflare-dns.com, dns.google or dns.quad9.net answers first (the domain is resolved to an address so that address can be looked up on Shodan); for an IP address, internetdb.shodan.io. What is sent is what you typed.
  • Any other guided diagnosis you start (slow network, cannot connect, and so on): the same anchors as the automatic pass, plus 2606:4700:4700::1111, Cloudflare's IPv6 resolver, on port 443, for the IPv6 reachability check. It opens a connection and closes it, and sends nothing.
  • The security-risk check: a published set of test hosts, listed in 4c.
  • A device maker's support link: opens that manufacturer's own site in your browser. Pingo itself fetches nothing.
  • Feedback: Google Cloud Firestore, and from there Resend. See section 6.

About the email address, plainly. If you run a breach check on an email address, that address is sent in full and in the clear to Hudson Rock, and, if you have configured a key, to Have I Been Pwned. The partial-hash protection described above covers the password check only. An earlier version of this policy implied it covered the email check too, and named neither company. Both of those were wrong. If you would rather not share an address with them, do not run the email check.

4c. The security-risk check, in full

This one gets its own list, because it deliberately makes requests that look alarming in a firewall log, and it is why several unfamiliar names appear above. It runs only when you choose the "check for obvious security risks" diagnosis. It is not part of the automatic pass. What it does is try to fetch things your network protection should stop, and report what got through. Everything it requests is a published, purpose-built test resource:

Two things are true of the whole list. Each of these names is also looked up through the DNS-over-HTTPS resolvers named in 4a, because the check works by comparing what your network's resolver answers against what a public one answers. Without that control there is no way to tell "blocked" from "broken". And none of these requests carries anything of yours: no address you typed, no device from your network, nothing you scanned.

  • secure.eicar.org and amtso.eicar.org: the EICAR anti-malware test file and the AMTSO test set. These are harmless test files published for exactly this purpose. No real malware is downloaded, and nothing fetched is written to storage.
  • www.amtso.org: AMTSO's phishing-page test.
  • malware, nudity, anonymizer, cryptomining, gambling, filesharing, newdomains and commandandcontrolandbotnet .testcategory.com: Cloudflare's published category-filter canaries.
  • internetbadguys.com, examplemalwaredomain.com and exampleadultsite.com: Cisco Umbrella's published phishing, malware and adult-content canaries. Each is looked up and then requested, to see whether your resolver or your network stops that category. They are test domains published for this purpose; nothing real is downloaded.
  • blocked.test.on.quad9.net and notblocked.test.on.quad9.net: Quad9's matched pair. Only the names are looked up. One is meant to be refused and the other is not, and it is the difference between the two answers that tells a filtering resolver apart from one that is simply broken.
  • urlfiltering.paloaltonetworks.com: Palo Alto's published URL-filtering canary. A plain request for its test path, to see whether something is inspecting URLs on the way out. Nothing real is downloaded.
  • nic.ir: the operator of the .ir domain registry, used as a benign reachability canary to see whether your network refuses destinations in embargoed countries. It is looked up and requested like any other site. The choice is technical, not political: it is simply a stable host in that region.
  • 128.31.0.39, port 9131: a Tor directory authority, to test whether anonymiser traffic is allowed out.
  • portquiz.net: which outbound ports your network permits.
  • 1.1.1.1 and 9.9.9.9 on port 853, and use-application-dns.net: encrypted-DNS posture.
  • test.nextdns.io: whether a filtering resolver is in front of you.
  • httpbin.org and example.com: request-echo and reachability controls, so that "blocked" can be told apart from "the internet is down".
  • www.cloudflare.com and dns.google: two well-known sites, fetched so their certificates can be inspected. If something on your network is decrypting your traffic, the certificate it presents will not be the real one, and that is what this looks for. Nothing about the connection is sent onward.

The data-loss checks in this suite post fabricated synthetic values, test card and identifier patterns that belong to nobody, to the echo host, to see whether they are inspected. Nothing real, and nothing of yours, is used.

4d. What none of them are given

None of the services above receives your name, an account, an advertising identifier, your Wi-Fi network's name, its password, the list of nearby networks, the list of devices on your network, your scan history or your test history. There are two exceptions, and both are described above rather than buried here. The one piece of personal information any of them receives is an email address you typed into the breach check yourself, and the message you typed into feedback, described in section 6. The one identifier tied to this installation that leaves the phone is the Play Integrity / App Check attestation in 4a, and it goes to Google and to nobody else. With those two exceptions these are the same public services a technician would query by hand, and Pingo automates the request rather than adding to it. Each of them has its own privacy policy governing the request it receives.

5. Diagnostics run on your device

Pingo's guided diagnosis works through a fixed set of checks on your device and reports what those checks measured. Your questions and your network's details are not sent anywhere to be interpreted.

6. If you send feedback

Feedback is the one place where you send us something on purpose. When you submit it, your message, the category you chose, an optional reply address, and the crash log only if you switched it on for that message, are stored in a Google Cloud Firestore database in our Firebase project, so that we can read and answer it. Google acts as our processor for that hosting, under its own privacy terms. As with any internet request, Google's infrastructure sees the connection it arrives on, including your IP address, in order to deliver it; we do not store your IP address alongside the message.

Our own server-side code then forwards a copy by email to our support inbox, so that a person reads it rather than it sitting in a database. That email carries the same things and nothing more. It is sent through a transactional email provider, currently Resend (Resend, Inc., United States), which therefore handles your message and your reply address in transit and acts as our processor under its own privacy terms. If you did not give a reply address, the email says so plainly and contains nothing that could be used to contact you.

The crash log stays on your phone unless you choose to send it. Pingo keeps a record of its own errors, on your phone only. When something inside the app throws, it writes down the time, the error's type, its text, and the first few lines of where it happened, and it keeps the last twenty. It masks IP addresses, MAC addresses and quoted network names out of that text before it saves any of it, so no detail of your network is in the record. Nothing uploads it: Pingo has no crash reporter and sends no crash report anywhere in the background. The switch that attaches it to a support message is off every time you open the Support screen, and switching it on attaches the log to that one message and no other. Before sending, you can read the exact text that would go, and clear the log, from that same screen.

Nothing else is attached to the message: no app or Android version, no scan results, no network details, and no identifier of yours. The request that carries it does carry the App Check attestation described in section 4a. That is what proves the message came from a real copy of Pingo and not from a script. That token goes to Google, belongs to the installation rather than to you, and is not stored alongside your message. Leaving the reply address blank means we have no way to identify who sent it. Nothing is sent unless you tap send, and if sending fails Pingo tells you so and offers your own email app instead; it never reports a message as sent when it was not.

We keep feedback only as long as we need it to answer you and to act on what you reported. To have yours deleted, email [email protected] from the reply address you gave, or quote the message.

7. Permissions

  • Precise location, while the app is in use. Android will not return Wi-Fi scan results, and will not even return the name of the network you are already connected to, to an app that does not hold this permission. There is no narrower one that works for it. Pingo asks for it on your first run, after the first screen has been drawn and behind its own explanation, never before. Decline and Wi-Fi scanning, the network name and the signal readings switch off, each screen that needed them says so, and everything else in the app carries on; Settings has a Wi-Fi scanning row that brings the question back. The same permission covers the AP locator's true-distance mode, which times radio round trips to an access point and which Android will not allow without it on any version.
  • Pingo does not collect, store or transmit your location. It has no code that reads a position, a coordinate or an address. The only thing it asks the location service is whether the master switch is on, so an empty scan can be explained rather than shown as "no networks nearby". It never requests background location.
  • Camera. Used in one place, the QR scanner in the VirusTotal tool, so you can scan a link instead of typing it. Frames are decoded on your device and are neither stored nor transmitted.
  • Notifications and a foreground service. Used only if you turn on the live speed meter in the status bar. The service reads this device's own cumulative byte counters every two seconds and redraws the notification. It opens no connection and sends nothing anywhere.
  • Network and Wi-Fi state. Used to read your connection and run the tools that are the app's purpose.
  • Run at boot. Used only if you turn on the new-device guard, so its periodic check survives a restart. That check stays on your own network.

Not in this release. An AI assistant and an app-traffic monitor were built and are held back from this version. Neither is in the app you can install: the assistant sends nothing to Google because it cannot be reached, and the monitor's usage access permission is not declared at all, so there is nothing to grant. If either returns, this policy is updated in the same release.

8. Children

Pingo is a technical utility intended for general and professional audiences. It is not directed at children and does not knowingly collect information from children.

9. Security

Because your data stays on your device, its security is tied to your device's own protections. Sensitive items are held in Android's encrypted storage. Uninstalling the app removes its data.

10. Changes

If this policy changes, the date above will change with it, and the current version will always be available at this address.

11. Contact

[email protected]