A browser is not a VPN and does not hide your IP address. Tracking protection is list-based and not absolute: known ads, analytics, and social trackers from bundled lists are blocked on the device, but no blocker catches everything. Private Browser Incognito is rated 17+ for unrestricted web access and is intended for adults.
The honest sentence is the one most privacy pages bury. Tracker blocking is not absolute. Lists catch known ads, analytics, and social trackers. New names appear. First-party scripts can look like the site you opened. Per-site exceptions exist because pages break. Fingerprinting can use signals we do not claim to spoof. A product that says 100 percent is selling a feeling, not a rule matcher.
Private Browser Incognito still ships a blocker. Content-blocking rules powered by the open Disconnect lists run on the device. The lists are in the app, not fetched while you browse. This article is about the gap, not a dunk on our own feature. Use the blocker. Do not bet a secret on it. For how the lists are built into the browser, see Ad Blocking Built Into a Private Browser.
What “not absolute” means in practice
A content blocker is a set of rules. A request is allowed or it is not, based on whether it matches. That is a sharp tool for names the list already knows. It is a blunt tool for everything else. The web does not wait for a list update. Hosts are cheap. A tracker can move. A site can copy a beacon into its own domain. None of that is exotic. It is ordinary churn.
We describe three buckets with generic labels. An ad request tries to load a creative or an auction. An analytics beacon reports that a page viewed. A social widget tries to attach a share button or a comment count from a network you did not open as the main page. If a request sits in those buckets and on the list, it can be stopped. If it sits outside, it can pass. There is no fourth bucket called “everything a company might learn.”
The site you typed is still a party to the visit. It sees your IP address, the usual headers, and whatever you type into its forms. Blocking extra companies is a reduction of known noise. It is not invisibility to the destination. Your network operator still sees that a connection happened. A workplace gateway can still log hosts. None of that is fixed by a list file.
We do not publish a catch rate. A number would go stale on the same day we printed it, and it would invite a comparison we cannot police. A demo counter can show that rules fired. It is not a study. If another app shows a precise percentage, ask what window, what page set, and who paid for the test. Then assume the next week’s hosts were not in it.
Why lists lag
Disconnect is a well-known open set of categories. In this app those categories power the rules. The lists ship in the binary. When we release an app update, the copy you install is the copy you browse with. There is no runtime download of a fresher file. That choice keeps a list server out of the path. It also means the ship date is a freeze date. Something registered after that freeze is a miss until the next release.
Lag is not a bug we are hiding. It is the cost of not phoning home. A blocker that updates every hour is a blocker that can see the app is open. Private Browser Incognito has no app server for browsing. The App Store privacy label is Data Not Collected. We would rather miss a new analytics host than run a feed that watches you in order to stay current. That trade is load-bearing. The mechanics of bundled lists are in How On-Device Block Lists Work.
Even a daily feed would miss names that never make a public list. Private trackers, one-off pixels, and first-party copies do not always have a convenient hostname. Rule matching is not a researcher reading the page. iOS content blocking has limits. Treat the feature as coverage of a known set, not as a census of the advertising industry.
First-party code, fingerprinting, and other gaps
A third-party rule looks at the destination of a subresource. If the script is served from the same site you opened, it may not match. Sites fold analytics into their own origin because it survives blockers. That is legal web architecture. It is also why “we blocked trackers” can be true in the third-party sense and false in the “nobody learned that you loaded this” sense. The destination still learned it. Extra companies might not.
Fingerprinting is a different gap. Fonts, canvas, screen size, and other signals can distinguish a device without a named tracker host. We do not sell anti-fingerprinting as a product. We do not claim you are anonymous or untraceable. Saying that plainly is better than implying a shield that closes every side channel. If fingerprinting is your actual threat, this browser is the wrong shopping list.
Logins and payments are another gap people forget. If you sign into a site, that site knows you. If you pay, that site knows the purchase. Blocking a social widget on the same page does not rewrite the account relationship. A forgetful session still holds cookies until you erase. Erase destroys the session. It does not unsay the POST you already sent.
Per-site exceptions are part of the honesty
A blocker that never breaks a page is a blocker that is not matching much. When a video, a comment thread, or a paywall lives on a host the lists also use for ads, the page can fail. Per-site exceptions exist so you can finish the task. Turning an exception on is a local choice. It does not report to us. It does not disable tracking protection everywhere else.
Use exceptions sparingly. Finish. Erase if you do not want that site’s cookies to linger for the rest of the session. One-tap erase closes every tab and destroys cookies, cache, and site data. The exception does not survive as a cloud preference because there is no account. It lives on that device, for that app. That is the same local stance as the lists themselves.
Exceptions are also why “blocked everything” is a bad status line. If you allowed a site through, you allowed it. The UI should not pretend the shield is sealed. We would rather show a gap than invent a perfect score. The related how-to for on-device rules is On-Device Ad and Tracker Blocking on iPhone.
How to use a reduction without believing a myth
The useful posture is small. Keep blocking on. Keep HTTPS-Only Mode on (it is the default; the app asks before HTTP). Keep suggestions off until you want them. Do not log into a site you wanted to be a stranger to. Erase when the session should die. Lock the app if someone else can pick up the phone. None of those steps is absolute. Together they are a local reduction: fewer extra requests, less residue, nothing to trust us with.
| What you wanted | What lists can do | What still happens |
|---|---|---|
| Fewer ad and analytics requests | Stop known names on the device | New or first-party names can pass |
| No extra social widgets | Stop listed widgets | The main site still sees you |
| Hidden IP | Nothing. Not a VPN | Sites and the network still see it |
| A page that always works | Exceptions when it does not | Some modules never load |
Rated 17+ still applies. This is unrestricted web access. You choose URLs. You are responsible for using the app lawfully. Tracker blocking will not make a site appropriate and will not hide you from a network administrator. It will reduce known noise from bundled Disconnect lists that ship on the device. That is a real feature. It is not a cloak. If a listing cannot say the gap out loud, it is not a listing you should trust with the rest of the story either.
Private Browser IncognitoFree on the App Store. No history, on-device blocking, one-tap erase.
Get the app
Frequently asked questions
Is tracker blocking in a private browser 100 percent?
No. Tracking protection blocks known ads, analytics, and social trackers from bundled lists that run on the device. No blocker catches everything. New trackers appear, some requests are not on any list, and per-site exceptions exist when you need a page to work. Treat blocking as a reduction of known noise, not as a guarantee.
Why do some trackers still load on iPhone?
Lists go stale as new hosts appear. A script served from the same site you opened may not look like a third-party tracker. Fingerprinting can use signals we do not claim to spoof. And if you added a per-site exception, that site is allowed to load resources the lists would otherwise stop.
Does list-based blocking hide my IP address?
No. A browser is not a VPN. Blocking a tracker request means that request does not leave the phone. The site you meant to visit still sees your IP address, and your network operator still sees destinations. On-device lists do not assign you a new address.
Can I turn blocking off for one site?
Yes. Per-site exceptions exist when a page needs a blocked resource to function. The exception is local on that device. It does not send a report to us. It does not disable tracking protection on other sites. Use it, finish the task, then erase the session if you want those cookies gone.
What do the Disconnect lists actually catch?
They power content-blocking rules for known ads, analytics, and social trackers. The lists ship inside Private Browser Incognito and run on the device. They are not downloaded at runtime. We describe those buckets with generic labels, not company names. Matching is rule-based, not a human reading the page.