A New Scan Says 36% of Web Apps Track Before Consent—Trust Breaks Before Install
An install button asks for more than another click. It asks a user to place a web product beside their trusted apps, give it a persistent home on their device, and return without the familiar frame of a browser tab. That makes everything happening before installation part of the product promise.
A fresh scan suggests too many web products are breaking that promise before the user even signs in. Legit.Show’s Privacy Gap report says 36% of the 6,574 launched web services it tested triggered non-essential trackers before consent. The sample included web apps, SaaS products, AI tools and developer services.
That number needs careful handling. This was not a random sample of the whole web, it was not limited to installable PWAs, and the findings have not been independently reproduced. But for founders trying to turn a URL into an app relationship, the report is still a useful warning: privacy behavior is becoming part of install conversion, not merely a compliance task hidden in the footer.
What the scan found
Legit.Show evaluated the public surface users encounter before authentication. Alongside its tracking result, the report says 50% of the scanned services had no terms page reachable by its test, while 38% had no reachable privacy-policy page. It classified 36% as having neither page available through the paths it checked.
Those figures do not necessarily mean the documents do not exist. The report’s method does not count a policy found only behind authentication, on a third-party host or in a PDF. Its tracker detection is also signature-based, so it may miss unfamiliar trackers or code loaded later from application bundles. The authors consequently describe the detected problems as a floor for this particular sample, not a reliable prevalence rate for every web app.
That distinction matters. The headline is not “36% of all PWAs violate privacy law.” The report did not test that proposition, and whether a particular technology requires consent depends on its purpose and the applicable jurisdiction. What it did detect is simpler and commercially important: a substantial share of the products in its launch-oriented sample presented weak public trust signals or contacted services the scanner considered non-essential before a user had made a choice.
Why installable web apps should care more
A conventional website can survive a slightly awkward first visit. An installable web app is competing for a different level of commitment. Its icon may live on a home screen or desktop, its window may open without normal browser chrome, and supported experiences can use service workers, local storage, push notifications and other capabilities under browser controls and user permissions.
Installation does not grant a web app special tracking powers. It does, however, change the user’s mental model. Once a product looks and launches like an app, people reasonably expect app-grade clarity about who operates it, what it stores and how to remove or reset it.
Native stores try to package some of that confidence into centralized review, publisher records and familiar update flows. Open-web distribution offers something more flexible: a product can launch from its own domain without asking a store for shelf space. The tradeoff is that much of the trust proof belongs to the developer. HTTPS and a browser-generated installation prompt establish important technical boundaries, but neither certifies the publisher’s privacy practices.
This is why an install prompt must never be treated as a trust badge. A technically installable app can still have unclear ownership, unreachable policies or analytics that begin before the interface has explained them.
Who should act on the signal
Founders should view privacy hygiene as part of activation. A user who hesitates at installation is evaluating whether the product deserves permanence, not only whether its feature list is useful.
Developers need to validate behavior at the network layer. A polished consent component proves little if an analytics SDK, tag manager or embedded widget sends requests during initial rendering.
Product teams should make privacy controls work in both a normal tab and the standalone installed experience. Users must be able to find disclosures, revise choices and understand deletion without returning to a marketing site they may no longer remember.
Investors and distribution partners can treat pre-consent behavior as a due-diligence signal. It reveals whether a team has moved from demo-stage integrations to deliberate production operations.
A practical pre-install trust check
The useful response is not another paragraph of legal text. It is a short, repeatable product test:
- Inspect a clean first load. Test with a fresh browser profile and record every request made before any privacy choice. Repeat where regional configuration changes the experience.
- Gate optional integrations by behavior. Confirm that analytics, advertising pixels, session-replay tools and non-essential embeds remain inactive until the appropriate choice exists.
- Publish human-readable ownership and privacy information. Make it reachable before sign-in and from the installed app, not only from a campaign landing page.
- Test the standalone context. Verify that consent state, account controls and data-deletion routes remain discoverable when browser navigation is less visible.
- Recheck every deployment path. Tag-manager changes, SDK upgrades and cached service-worker assets can produce behavior that differs from the code a team believes it shipped.
None of these steps requires turning onboarding into a wall of warnings. Good privacy UX is often quiet: optional code waits, the explanation is brief, refusal works, and settings remain easy to find later.
The business payoff is trust that compounds
Installable web apps win when the open web’s low distribution friction does not feel like low accountability. Clear ownership, restrained data collection and reversible choices help close that gap. They also reduce the chance that an installation campaign succeeds at acquisition while creating a support, procurement or reputation problem later.
The report’s sample should not become a universal benchmark. Its value is in making an invisible launch habit visible. Teams routinely measure load time, funnel conversion and install acceptance while ignoring the requests that leave the browser before the first meaningful interaction. That is a blind spot worth fixing even if the exact market-wide percentage remains unknown.
What IndApp watches next
IndApp is watching whether browsers make publisher identity and data expectations clearer at installation, particularly when a web app opens in a standalone window. We are also watching for developer tooling that audits pre-consent network activity as routinely as performance, accessibility and manifest quality.
The bigger opportunity is cultural. Open-web distribution should not imitate every gate imposed by an app store, but it does need recognizable trust signals. An installable app should be able to show who stands behind it, what begins running on first contact, which permissions remain optional and how the user can leave cleanly.
The web’s distribution advantage starts with a link. Its long-term advantage will depend on whether that link can become an app without asking users to trade away clarity first.
Further reading
Recent news
