Loupe – A iOS app that raises awareness about what native apps can see
An open-source iOS app called Loupe is drawing attention to how much identifying data “native” apps can access without explicit permissions, from device setup time and clipboard change counts to the presence of selected other apps. Commenters argue this enables powerful fingerprinting and cross-app tracking that Apple’s current privacy prompts and labels barely address, and note that many services push users into apps precisely because they allow deeper surveillance than the web. Ideas raised range from stricter platform controls—such as per-app network permissions, better sandboxing, and OS-level anti-fingerprinting—to personal tactics like minimizing installed apps, using privacy-focused browsers, or alternative mobile OSes.
Mac and platform scope
- Some want a macOS version; README says it already mostly works on Mac but needs polish.
- Discussion about what “apps” on macOS are, differences between Mac App Store sandboxed apps and non‑store apps with broader access.
Fingerprinting vectors revealed
- Volume/“device last setup or erased” timestamp seen as especially egregious; considered highly identifying when combined with a few more bits (device type, storage, timezone).
- Clarified that this comes from the volume creation timestamp, not a special API.
- Pasteboard change counter and access without an explicit paste disturb some; others note iOS now prompts before reading clipboard contents.
- Some argue many of these leaks (locale, date formats, webview info, network info) are already enough for fingerprinting.
Installed apps and cross‑app tracking
- Surprise that apps can infer presence of other apps and use that for profiling (e.g., dating apps).
- Clarification: iOS can’t freely list all apps; it can only query up to 50 declared URL schemes (LSApplicationQueriesSchemes), but that’s still enough for profiling and can be rotated over updates.
- Concern that third‑party SDKs and data brokers aggregate such per‑app signals into powerful cross‑app and cross‑site tracking.
Native apps vs web / PWAs
- Many see native apps as far more privacy‑invasive than websites, which explains aggressive “install our app” prompts.
- Others argue apps are also technically better (features, OS integration), which includes better fingerprinting capabilities.
- Some push web alternatives (old.reddit, browser anti‑nag features) but note many services intentionally degrade mobile web to force app installs.
OS privacy controls and comparisons
- iOS: sandboxing for App Store apps, ATT toggle only blocks the advertising ID, URL filtering API introduced, App Privacy Report lists contacted domains.
- macOS: MAS sandbox has a network entitlement; iOS lacks an equivalent.
- Android/GrapheneOS: per‑app network permission (sometimes prompted at install), sensor permissions, user profiles to isolate apps; still potential IPC channels for circumvention.
- Mention of TV/other devices unexpectedly joining networks seen as part of a broader “defective by design” ecosystem.
User strategies and their limits
- Common advice: minimize installed apps, favor browser, pick privacy‑respecting or offline‑first apps, use ad/tracker blocking, privacy‑focused OSes, and app‑level firewalls.
- Others feel “just don’t install apps” isn’t realistic due to work and service requirements.
- Some resign themselves to data collection and focus mainly on blocking ads.
Proposed fixes and debates
- Suggestions: randomize/fuzz timestamps and counters, restrict or coarsen pasteboard metadata, require explicit network permission (including on iOS), integrate Little‑Snitch‑like controls and richer capability models, system‑wide private relay.
- Mixed views on feasibility and effectiveness: some think permissions would just become another prompt users auto‑accept; others see them as valuable transparency and pressure on developers.
- Legal dimension: speculation that pervasive in‑app tracking and “pay‑or‑accept‑tracking” may violate GDPR, but outcomes are noted as pending courts.