cd ~/
PrivacyLocalizationSecurityVPSMeta

Privacy-Preserving Visual Localization

How to localize without compromising privacy - on-device processing, feature design, and differential privacy approaches.

Evyatar Bluzer
3 min read

VPS knows where you are, because that is the entire job. The design problem is keeping it from learning anything more than it needs, and making sure what it does learn cannot be turned against the person holding the device.

Privacy Threats

Location history

Sequential VPS queries reveal movement patterns: where you go, when you go there, how long you stay. One query is harmless. A sequence of them is a diary.

Image content

Images sent for localization could reveal the people you are with, the activities you are doing, and private spaces that were never meant to reach a server.

Aggregation

Even anonymous data, once aggregated, reveals patterns: popular locations, traffic flows, gathering patterns.

Defense: On-Device Processing

The first principle, carried over from the Quest integration, is that images never leave the device.

Camera → On-Device Feature Extraction → Features → Cloud
         (full image here)              (no image content)

Features are designed to be non-invertible. They can match against the map but cannot reconstruct the original image, and we test that claim with adversarial image reconstruction attacks rather than taking it on faith. The acceptable leakage is general scene type (indoor versus outdoor), never specific content.

Defense: Minimal Collection

We collect features rather than images, approximate location rather than a precise trajectory, and a session ID rather than a user ID. Retention follows the same logic. Query features are deleted immediately after localization, aggregate statistics are retained for service improvement, and no personal location history is stored anywhere.

Device edge boundaryA highlighted vertical line splits two columns of text: five rows on the left list what reaches the server, five rows on the right list what it never learns, with a muted footnote under each column.the device edgeWHAT REACHES THE SERVERWHAT IT NEVER LEARNSNon-invertible features (scene type only)Approximate locationA session IDLocation counts plus calibrated noiseMatch score plus noiseThe image: people, activities, private spacesA precise trajectoryA user IDWhether any one person was presentPrecise timing from the matchQuery features deleted right after localizationNo personal location history stored anywhere
What crosses the device edge to the server, row by row against what it replaces: non-invertible features instead of the image, an approximate location instead of a trajectory, a session ID instead of a user ID, and noisy aggregates instead of anything about one person.

Defense: Differential Privacy

Calibrated noise prevents individual identification; this is the differential privacy line item from the global mapping plan, now with a formula attached. For location aggregates:

True count + Noise(scale=ε) = Published count

The guarantee: you cannot determine whether any individual was present. For feature matching:

True match score + Noise = Reported score

This blocks precise timing inference while keeping localization functional.

Defense: User Control

Users need control that actually works: clear opt-in for VPS features, easy opt-out without losing device function, data download so you can see what we have, and data deletion that removes all traces.

Why should users believe any of this?

Claims about privacy are cheap, so we back them with things outsiders can check: regular third-party privacy audits, open-source privacy components where possible, a bug bounty for privacy vulnerabilities, and transparency reports on data requests.

The Performance Trade-off

None of this is free. On-device processing uses more battery, differential privacy reduces accuracy, and limited collection rules out some features we could otherwise build. We accept those costs on purpose.

Regulation

GDPR, CCPA, and the rules still being drafted shape the design directly: data minimization (collect the minimum necessary), purpose limitation (use it only for the stated purpose), storage limitation (delete it when it is no longer needed), and user rights to access, correct, and delete. It is far easier to design for these constraints from the start than to retrofit them after the architecture has hardened. The headset version of this argument was about what the sensors see; the VPS version is about where you are.

Comments