HN Debrief

Loupe – A iOS app that raises awareness about what native apps can see

  • Privacy
  • Mobile
  • Security
  • Consumer Tech

Loupe is a demo app from Mysk that surfaces the kinds of information an iOS app can read without special permissions. It highlights fingerprinting inputs like volume creation time, pasteboard change count, locale and network details, and limited probing for whether specific apps are installed. The point is not that Loupe itself is dangerous. It is that ordinary native apps can quietly assemble enough entropy to track or correlate users even when they deny obvious permissions.

If you rely on mobile apps for customer or employee workflows, assume app installs create a privacy and compliance surface well beyond camera and contacts prompts. Audit whether your own apps really need unrestricted network access, third-party SDKs, or install-probing features, and expect tighter platform rules if Apple decides these loopholes have become a reputational risk.

Discussion mood

Alarmed and frustrated. People largely accepted Loupe's core point that iOS apps can gather more fingerprinting data than users assume, and many were especially angry that Apple both markets privacy heavily and already ships stronger network controls in China or on adjacent platforms without exposing them broadly.

Key insights

  1. 01

    Installed app probing is capped, not gone

    Apple did not leave a full installed-apps API lying around. It replaced it with a narrower mechanism where apps declare URL schemes they want to query and App Review can reject broad or unrelated lists. That sounds protective until you remember how fingerprinting works. A small, carefully chosen set of apps can still add plenty of entropy, and large SDK distributors can rotate those probes over frequent app updates. The result is not blanket visibility, but still enough signal for profiling.

    If your app uses URL-scheme checks for convenience features, treat them as privacy-sensitive collection and remove anything nonessential. If you buy SDKs, ask whether they probe for other installed apps and make that a procurement question, not just a legal disclosure.

      Attribution:
    • aggregator-ios #1
    • nomilk #1
    • isodev #1
    • microtonal #1
    • saagarjha #1
    • NietTim #1
  2. 02

    Per-app network controls already exist elsewhere

    The striking part is not that commenters want a hypothetical firewall. They pointed out that variants of this control already ship today. China-market iPhones reportedly let users block Wi-Fi or cellular per app, and GrapheneOS and some AOSP-derived systems expose internet permission toggles at install time. That shifts the framing from "too hard for normal users" to "platform vendors deploy this when regulation or product philosophy forces the issue."

    Do not assume current mobile privacy limits are immovable platform constraints. If regulation tightens or public pressure spikes, Apple and Google can ship stronger outbound controls quickly, which would break analytics-heavy assumptions in many apps.

      Attribution:
    • henryhchchc #1
    • ksec #1
    • thewebguyd #1
    • tancop #1
    • Hoodedcrow #1
    • inigyou #1
    • nubinetwork #1
  3. 03

    Domain logs help, but trackers adapt

    Built-in reports and tools like Little Snitch are useful for showing which domains an app contacts, and several people said they had not even known iOS already has an App Privacy Report. But that visibility stops at the network boundary. If developers serve tracking and core product traffic from the same hosts, domain blocking becomes blunt or useless. This is exactly what happened in ad-heavy web services like YouTube. So observability is valuable, but it does not replace hard permission boundaries.

    Use outbound network reports for auditing and vendor reviews, but do not mistake them for effective prevention. If your risk model depends on stopping exfiltration, you need platform enforcement or strict app selection, not just better logs.

      Attribution:
    • Cider9986 #1
    • gyomu #1
    • inigyou #1 #2
    • 360MustangScope #1
    • prime17569 #1
    • fizwidget #1
  4. 04

    Internet permission alone does not isolate apps

    Android examples made the network-toggle idea look attractive, but they also exposed the next layer of the problem. On systems where one app can ask another privileged component to do work, a denied app may still reach the network indirectly through IPC or services such as Play Services. GrapheneOS profiles help by isolating apps more aggressively, but they are heavy for everyday use. That means the real privacy primitive is not just a network checkbox. It is app-to-app isolation plus control over privileged brokers.

    When evaluating mobile privacy claims, ask how apps are isolated from each other and from system services, not just whether there is an internet permission. Product teams building sensitive workflows should assume SDKs and shared services can reintroduce leakage even after obvious permissions are revoked.

      Attribution:
    • reorder9695 #1
    • microtonal #1
    • ignoramous #1
    • saagarjha #1
    • Hoodedcrow #1
    • Cider9986 #1
    • inigyou #1
  5. 05

    Apps are pushed because they track better

    Several comments cut through the familiar "apps are just a better UX" story. Native apps do offer deeper OS integration and smoother commerce, but that same access gives them a much richer tracking surface than the mobile web. Browser users are also more likely to run blockers, while in-app SDK tracking is largely invisible. Apple's own labeling adds confusion because many users read "Allow Apps to Request to Track" as if it blocks all in-app tracking, when it mostly governs one identifier path.

    If your growth strategy leans on forcing users into apps, expect sharper privacy scrutiny from customers, regulators, and enterprise buyers. Be explicit about what extra data the app layer gives you and whether that benefit is worth the trust cost.

      Attribution:
    • camkego #1
    • microtonal #1
    • p-e-w #1
    • paytonjjones #1
    • socalgal2 #1
    • yreg #1
    • inigyou #1
  6. 06

    Uninstall does not necessarily clear identity

    The TikTok example was likely not some exotic fingerprint at all. Commenters pointed to Keychain persistence, which can preserve app-linked secrets across uninstall and reinstall on iOS. That is a legitimate OS feature for some continuity use cases, but from a user perspective it means deleting an app does not always reset your relationship with it. For privacy-sensitive products, persistent storage primitives can be as consequential as fingerprinting APIs.

    If your app uses persistent secrets that survive reinstall, document that behavior internally and decide whether it aligns with user expectations. If you are auditing third-party apps, do not assume uninstalling them severs all continuity.

      Attribution:
    • diebeforei485 #1
    • gene91 #1
    • cute_boi #1

Against the grain

  1. 01

    Most of this is expected platform metadata

    A minority view held that Loupe is more a visibility tool than a revelation. Locale, date formats, webview properties, and basic network details are ordinary runtime metadata, and many of the headline-grabbing items are indirect inferences rather than explicit user data. From that angle, iOS still looks relatively locked down compared with general-purpose desktops, and the remaining leaks are hardening work rather than evidence that the whole model is broken.

    Do not overreact by treating every exposed signal as equally severe. Prioritize the few fields that add durable cross-app entropy, like install probes and setup timestamps, and separate those from routine app environment data.

      Attribution:
    • ololobus #1
  2. 02

    Most real apps genuinely need internet

    Some pushed back on the claim that internet access should be exceptional. For many people's phones, the third-party app mix is mostly social, travel, finance, streaming, shopping, and other service wrappers that simply do not function without backend access. In that world, a mandatory prompt could train users to click through and create friction without delivering much protection unless it comes with stronger platform review and meaningful offline alternatives.

    If you advocate for an internet permission, pair it with a product model for offline capability, system-managed sync, or app-store enforcement. Otherwise you risk adding another consent dialog that users accept automatically.

      Attribution:
    • fizwidget #1
    • dessimus #1
    • nodamage #1

In plain english

AOSP
Android Open Source Project, the base open source version of Android that device makers and custom operating systems build from.
App Privacy Report
An iOS feature that logs some app activity, including domains contacted and sensor or data access events.
App Review
Apple's approval process for apps submitted to the App Store, including checks on policy and allowed behavior.
entropy
In privacy and security, the amount of distinguishing information a signal contributes toward uniquely identifying a user or device.
fingerprinting
Identifying or correlating a device or user by combining many small signals, even without a direct user ID.
GrapheneOS
A privacy- and security-focused version of Android that adds stricter app controls and isolation features.
IPC
Inter-process communication, the ways separate apps or system components exchange data or request work from each other.
Keychain
Apple's secure credential storage system, which apps can use to keep secrets such as tokens and sometimes preserve them across reinstalls.
Little Snitch
A macOS firewall and network monitor that shows and can block outbound connections from apps.
Play Services
Google Play Services, a privileged Android component that provides many common app features such as notifications, location, and account services.
SDK
Software development kit, a package of libraries and tools used to build against a platform or service.

Reference links

Project and demo links

Mobile privacy tools and related projects

Platform behavior and technical references

Tracking, data brokers, and abuse examples

Web and general reference links

  • browsergate.eu
    Mentioned as an example related to sites degrading the browser experience to push app installs
  • xkcd 1105
    Reference for the comment comparing fingerprint uniqueness to the memorable license plate comic
  • HDMI 1.4 overview
    Reference for the claim that HDMI can carry an Ethernet channel between devices