Conceptio › Archive › arXiv CS

arXiv CSopen access

CityOS: Privacy Architecture for Urban Sensing

2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

operating-systems virtualization

operating systems, kernel, virtualization

arXiv:2605.02886v1 [cs.OS] 4 May 2026

CityOS: Privacy Architecture for Urban Sensing Giorgio Cavicchioli

Mark Chen

Navid Salami Pargoo

Columbia University USA

Rutgers University USA

Shuren Xia

Xiaotian Zhou

Roxana Geambasu∗

Rutgers University USA

Columbia University USA

Jason Nieh

Jorge Ortiz

Columbia University USA

Rutgers University USA

Abstract

sensor-equipped smart poles illustrate the global expansion of urban sensing infrastructure [28]. While some high-profile projects have failed amid privacy concerns – Sidewalk Labs in Toronto [39] – many incremental deployments continue to grow with limited oversight or consistent governance. The core risk is not any single deployment but the trajectory: without structured interfaces governing how sensing data is accessed and aggregated, backend collection becomes the default and, once entrenched, is difficult to reverse. The web illustrates this pattern. For decades, advertising measurement relied on cross-site tracking – third-party cookies, fingerprinting, and backend data exchanges – largely because browsers offered no structured alternative. Recent efforts, such as the W3C Attribution API [78], embed privacy constraints into platform interfaces via encrypted reporting and differentially private aggregation. Whether such approaches can displace tracking remains uncertain, but their difficulty underscores the importance of early intervention. Physical-world sensing faces a similar inflection point. Pervasive cross-context tracking is not yet the norm in most environments, and some legal constraints have begun to emerge [55]. This creates an opportunity to define structured data-access models before tracking becomes entrenched. We introduce such a framework. Inspired by the web’s recent move toward structured, privacy-conscious interfaces, we present CityOS, a privacy architecture for urban sensing that separates data access into distinct classes, each exposed through a purpose-built API with privacy protections calibrated to its risk. CityOS is a privacy-enforcing runtime deployed at the edge – at intersections or other instrumented locations – where it hosts untrusted applications in sandboxed containers and mediates all access to local sensor data through a three-tier API. API 1 (On-Scene) provides realtime, ephemeral access with outputs confined to the immediate locality – reflecting that momentary, local observation is qualitatively different from persistent recording. API 2 (Single-Locality Aggregation) supports longitudinal statistics at a single location through differential privacy (DP) – addressing the risk that even single-site data accumulates into a sensitive behavioral picture over time. API 3 (Cross-Locality

Cities are rapidly deploying sensing infrastructure – cameras, environmental sensors, and connected kiosks – that continuously observe public spaces, yet they lack a system architecture governing how applications access, aggregate, and retain this data, creating privacy risks and preventing consistent policy enforcement. We present CityOS, an operating system for urban sensing that mediates application access to sensor data through a three-tier API inspired by structured, privacy-conscious web interfaces. The tiers expand the spatial scope of data access while imposing progressively stronger privacy constraints: On-Scene supports real-time sensing with raw data confined to the local context; Single-Locality Aggregation enables differentially private longitudinal statistics at a fixed location; and Cross-Locality Aggregation supports citywide analytics via aggregation across locations, with user devices enforcing per-user privacy budgets. CityOS runs as an edge runtime that executes untrusted applications in ephemeral containers, enforcing these policies and providing transparency via broadcasts of differential privacy loss. We implement CityOS and applications across all tiers – including pedestrian safety alerts, real-time and forecast parking availability, traffic dashboards, and subway trajectory measurement – and show that it supports practical streetscape applications while enforcing strong privacy.

Introduction

Cameras, audio sensors, and other sensing infrastructure are increasingly deployed across public and semi-public urban spaces, yet their data-access practices are governed by few consistent rules. New York City illustrates the problem: LinkNYC kiosks have been found to violate privacy policies, including failures to anonymize device identifiers [40, 47]; Wegmans collects facial-recognition data without disclosing retention practices [29, 48]; and CitiBike ride data can be re-identified at high rates using minimal auxiliary information [69]. These patterns extend beyond a single city. Deployments such as Singapore’s Smart Nation and Barcelona’s ∗ Also currently partly with Google, formerly partly with Meta. Work done

exclusively in the context of Columbia research. 1

Aggregation) enables citywide analysis mediated through user devices with per-user privacy budgets – ensuring that cross-location measurement, the most surveillance-prone capability, never relies on infrastructure tracking individuals directly. This tiered structure was developed by systematically mapping levels of data access identified on the web to their physical-world counterparts – an analogy we develop in §2 and list among our key contributions. As a cross-cutting design, CityOS provides privacy transparency. Each node wirelessly broadcasts its DP loss, enabling nearby devices running a CityOS mobile app to track cumulative privacy exposure as users move through instrumented spaces. This per-user accounting – combining losses from API 2 broadcasts and API 3 participation – gives individuals a continuously updated measure of their total privacy expenditure across all CityOS-instrumented locations. A critical question is whether this web-inspired privacy architecture can support useful smart-city applications. We prototype fiveapplications: (1) an object detection and tracking service that monitors the local scene and disseminates bounding boxes to nearby consumers (e.g., autonomous vehicles) to improve safety (API 1); (2) a pedestrian safety app built on (1) that detects imminent pedestrian-vehicle collisions and triggers audio alerts (API 1); (3) a parking app that provides real-time availability locally (API 1) and modelbased predictions for distant locations (API 2); (4) a traffic dashboard reporting per-locality pedestrian and vehicle statistics (API 2); and (5) a method for estimating subway route popularity – typically requiring tap-in/tap-out systems, but absent in NYC – without tracking people (API 3). Overall, we make the following contributions: a web-tosmart-spaces privacy analogy that maps canonical web dataaccess levels – in-session use, first-party longitudinal data, and cross-site data – to their physical-world counterparts, providing a reference model that motivates the API structure and grounds its privacy protections in a platform that has confronted tracking at scale (§2); the design of a structured API for urban sensing, based on this analogy, that separates functionality into three tiers with risk-tailored privacy protections (§3); new system mechanisms enabling this architecture, namely ephemeral containers, localized release, ephemeral DP continual release, bounded tracking contexts, relevance self-identification, and device-side privacy accounting – a subset of which address key gaps in the analogy (§4); a prototype implementation and fiverepresentative applications demonstrating support for practical smart-space functionality (§5); and an experimental evaluation showing that CityOS provides good utility for these applications while enforcing privacy (§6). We release all code.

and how platforms can avoid this through purpose-built, privacy-preserving interfaces. 2.1 Background on Web Privacy Browsers were designed around origin-based isolation: the same-origin policy restricts how content from one site can access data from another. But advertising measurement – one of the web’s dominant workloads – is inherently crossorigin, requiring linking ad impressions on content sites to conversions on advertiser sites. Because browsers offered no structured API for this task, the ecosystem defaulted to tracking. Third-party cookies enabled persistent identifiers across sites; when some browsers blocked them, tracking shifted to fingerprinting and backend data exchanges, such as first-party cookie sharing. The pattern is general: when platforms lack structured support for a required function, applications reconstruct it through tracking. The web is now attempting to correct this through a combination of regulation, platform interventions, and standards. Mechanisms such as Apple’s Private Relay [5] and browser fingerprinting resistance [6, 51] introduce technical barriers, while regulation (e.g., GDPR [24]) and platform responses such as Apple’s ATT [4] require tracking to be surfaced and permissioned. New U.S. state laws [71–73] further grant users the right to opt out of backend data sharing; this right is now being operationalized via W3C’s Global Privacy Control [32, 77], making it increasingly enforceable. These efforts create resistance to tracking but, without a structured alternative for advertising measurement, are unlikely to suffice. The W3C’s Attribution API draft standard [75, 78] introduces such an alternative: a structured browser interface for privacy-preserving advertising measurement. Content sites register ad impressions with the browser; advertiser sites request encrypted reports linking conversions to prior impressions; and only DP aggregates across many users are released via secure multiparty computation or trusted execution environments. Differential privacy (DP) bounds the influence of any individual on an output, with privacy budgets limiting cumulative exposure over time [20]. In Attribution, privacy is enforced on-device via per-epoch budgets, an enforcement architecture we ourselves developed in [75]. In essence, Attribution provides a cross-origin interface with privacy guarantees that approximate same-origin isolation. Whether it will ultimately displace tracking remains uncertain, but it demonstrates that viable alternatives exist. The broader lesson is clear: without structured interfaces, tracking becomes the default and hard to reverse. We apply this lesson to urban sensing by designing structured, privacy-by-design interfaces for different data-access types. 2.2 Why the Web as a Reference Designing a privacy architecture for a new domain without a reference model is extremely challenging. What should the data-access model be? What privacy policies are appropriate? How should one navigate the inevitable tradeoffs between

Web-to-Smart-Spaces Privacy Analogy

We use the web as a reference model for designing privacy in urban sensing: its trajectory shows how tracking becomes entrenched in the absence of structured support, 2

privacy and functionality? And how can these choices be explained to diverse stakeholders to achieve acceptance and adoption? These questions are difficult not only technically, but also from the perspective of building consensus around a new system design. These challenges are particularly acute in smart cities and public-space sensing. Such systems differ fundamentally from traditional platforms: they passively observe people who may not carry devices, do not establish sessions, and cannot be prompted for consent. As a result, the notice-andconsent model [61], common in traditional platforms, does not readily apply. Even when attempted [2, 7, 11, 41], it is widely recognized as insufficient [70]. Modern platforms such as browsers are therefore beginning to move away from notice-and-consent by embedding privacy protections directly into their interfaces (e.g., Attribution). In the absence of a widely accepted reference model, however, it remains difficult to develop credible proposals, justify tradeoffs, or build agreement across stakeholders. We propose the web as that reference. Despite differences in interaction models, functionality, and data types they handle – the web handles virtual activity while smart spaces handle physical activity – both domains share a common structure: applications rely on a small set of canonical dataaccess patterns with distinct privacy risks. This makes the web a useful foundation for designing structured interfaces for urban sensing, allowing us to transfer its lessons – both good and bad – to inform a principled design that avoids repeating its mistakes.

and outputs are ephemeral and confined to the local context. Level 2: Single-context, longitudinal aggregation. On the web, first-party sites collect user activity over time (e.g., visits, interactions, preferences), typically via first-party cookies. While useful for personalization, this accumulation produces increasingly sensitive behavioral profiles yet it is largely unconstrained by browsers. In smart spaces, the analogue is single-locality aggregation: collecting data over time at a fixed location (pedestrian counts, traffic statistics). Although data remains local, accumulation increases privacy risk. The web shows that, left unchecked, parties combine data across contexts, leading to progressively broader collection. Here, CityOS diverges: rather than relying on self-regulation, it applies DP to bound each individual’s contribution, limiting longitudinal inference and the impact of future compromise. Level 3: Cross-context aggregation. On the web, the most sensitive functionality is cross-site tracking, historically implemented via third-party cookies or fingerprinting. Recent efforts such as Attribution replace tracking with privacypreserving measurement. In smart spaces, the analogue is cross-locality measurement: linking observations across locations to estimate flows, trajectories, or system-wide patterns. While valuable, this poses the highest privacy risk by enabling reconstruction of individual movement. CityOS adopts and adapts Attribution to the physical world: rather than infrastructure tracking individuals, cross-locality queries are mediated via user devices, which generate encrypted reports and enforce per-user privacy budgets.

3 2.3 Web-to-Smart-Spaces Analogy Our analogy is based on a common set of canonical dataaccess patterns, each with distinct privacy risks. These range from in-session, single-origin access to cross-origin access on the web, and from on-scene sensing at a single location to cross-location trajectory data in smart spaces. Broaderscope access enables richer functionality but also increases privacy risk, requiring stronger controls. CityOS structures data access and privacy around these patterns. Level 1: In-context, short-term data use. On the web, this is real-time first-party use of in-session data (e.g., a user’s current query or page activity), which browsers largely permit. In smart spaces, the analogue is real-time, on-scene access to ephemeral sensor data for immediate functions such as obstacle detection, safety alerts, or parking availability. In both cases, data is used in context and need not be retained or linked across contexts, resulting in low and intuitive privacy risk. When visiting a website, you expect the site to observe your actions within that session; what you may not expect is them to retain this data or share it with other sites. Similarly, when entering an instrumented public space, you expect momentary observation for local functionality, but not persistent recording or tracking across the city. CityOS mirrors this expectation at this tier by ensuring that data

CityOS Overview

Referencing the web, CityOS organizes data access into three levels with distinct privacy risks, in which broader access along some dimensions – spatial scope, temporal scope, or fidelity – is balanced by tighter constraints on the outputs derived from that access. API 1 (On-Scene) provides the richest access to raw, high-fidelity data, but strictly confines computation and outputs to the immediate physical and temporal context in which the data is produced. API 2 (Single-Location Aggregation) relaxes temporal locality by allowing aggregation over time within a single location, while restricting access to aggregate statistics rather than raw data. API 3 (Cross-Location Aggregation) further relaxes spatial locality of the data by supporting cross-location measurement, but only through a constrained interface in which the user’s device controls their privacy exposure. This progression mirrors the web’s evolution from insession, single-origin access to cross-origin aggregation: as the scope of data use expands, the platform imposes stronger structural constraints to limit what is revealed. In this sense, CityOS maps geographic locality in physical space to origin locality on the web, giving rise to a same-location policy – a physical analog of the same-origin policy – under which data and computation remain local by default, with structured exceptions for broader access. API 2 occupies an intermediate 3

point that has no direct analogue on the web – a gap we view as a design flaw that enables unbounded accumulation of first-party data and that we avoid in physical sensing.

from its own location, but not with data from others. However, nodes may be temporarily compromised; we minimize retained state to limit exposure but do not defend against advanced persistent threats. Applications run on nodes and implement sensing functionality. We do not trust their data practices and assume that, without enforced structure, they would default to backend data collection. The architecture therefore bounds what applications can observe or export through sandboxing and API restrictions. Applications may additionally be subject to policy or contractual constraints imposed by the operator. Mobile devices receive localized outputs broadcast by nearby nodes and participate in privacy-budgeted aggregation for cross-locality queries. Each user trusts their own device but not others’. We assume that most devices do not run software designed to systematically collect and exfiltrate nearby nodes’ outputs – in effect, that what is broadcast at an intersection largely remains there. This assumption may be reinforced through policy and regulation (§4.1). Role of policy. CityOS enforces structural constraints technically (brief retention, locality-scoped outputs, structured aggregation APIs), but as on the web, effective privacy also requires legal or organizational constraints. Our goal is to enforce as much as possible technically while keeping the remaining policy assumptions explicit and narrow. Limits of anonymization. Data cannot be fully anonymized and remain useful [20], and individuals can often be reidentified through gait, body shape, clothing, or spatiotemporal patterns. We reject anonymization as justification for unrestricted backend collection and instead make structural constraints the default (§4.1). Scope. We do not aim to defend against all forms of surveillance. Broad government surveillance is out of scope, including adversaries capable of tapping many nodes or compelling broad access to system state. Similarly, large companies with ubiquitous access across mobile devices are assumed to be disincentivized from large-scale surveillance when privacypreserving APIs are available, in part by regulation and consumer pressure. Compromise of a single node may still be harmful, particularly at sensitive locations. Our claim is not that CityOS eliminates surveillance risk, but that it can prevent tracking and backend collection from becoming the default practice for physical-space applications. We assume attackers may compromise some applications, nodes, or mobile devices, but cannot maintain persistent visibility across a large fraction of locations for extended periods. Under this assumption, CityOS limits the scope and retrospective value of compromise by minimizing rawdata retention, restricting infrastructure-based tracking and mediating broader measurements with private interfaces.

3.1 API Example Consider an organization seeking to improve streetscape safety using video from cameras already deployed at city intersections. It plans three functions: (1) real-time alerts warning pedestrians and cyclists of approaching vehicles; (2) a dashboard showing hourly pedestrian and vehicle counts at each intersection; and (3) a citywide analysis of pedestrian flows between neighborhoods. Without architectural constraints, the natural approach is to stream camera feeds to a backend, store them, and run all three functions on the collected data. The organization might apply basic anonymization, such as blurring faces, but such techniques are fragile: individuals can often be re-identified through gait, body shape, clothing, or spatiotemporal patterns, especially when data is retained or linked across locations. CityOS restructures this. Real-time alerts run on-scene via API 1: the application processes the local feed in an ephemeral container, emits warnings to nearby devices, and retains nothing. The per-intersection dashboard uses API 2: the node releases DP hourly counts, never exposing individual observations. Citywide flow analysis uses API 3: rather than tracking pedestrians across intersections, participating users’ devices contribute encrypted reports that are aggregated without revealing individual trajectories. The same functionality is supported, but no persistent, city-scale record of individual activity is ever created – and privacy does not rest on the hope that anonymization holds up. 3.2 Threat Model Deployment model. CityOS targets deployments in which sensing and computation occur at many distributed locations (e.g., intersections, CityOS CityOS parking lots, transit stops, or retail spaces). Fig. 1 illustrates this setting: nodes CityOS CityOS are placed at intersections, each equipped with sensors (e.g., cameras) and hosting CityOS CityOS one or more applications. People move through the Fig. 1. Deployment model. environment, some carrying mobile devices, others not. Trust assumptions. Nodes are trusted runtimes that mediate all application access to local sensors and enforce API restrictions. Where possible, nodes at different locations are independently administered so that compromise of one location does not extend to others. When nodes are operated by a single administrative domain, we assume – enforced via policy – that they do not exchange data outside the system interfaces. Accordingly, each node is trusted with data

3.3 Architecture Design principles. In designing CityOS, we follow several key principles derived from the web-based same-location 4

CityOS Node App Backend Clouds

CityOS Applications

Trusted System Services

App a

App b

Object Detection & Tracking (API 1-3)

App c

App d

Ephemeral DP Continual Release (API 2) Node-User Coordination (API 2-3)

API 1: On-Scene

API

API 3 encrypted reports

API 2: Single-Locality Aggregation

API 3: Cross-Locality Aggregation

User Device API 2 aggregate releases

Mobile App b

CityOS Mobile Device-Side Privacy Accounting (API 2-3)

"Kernel" CityOS Runtime (system params: maxECapp≪ maxECsys) Ephemeral Container (App a)

Output Controller

Cloud (public) release →

C1 active C2 shadow C1 tear down C2 active C1 App a

C2 App a

minEC ≪ maxEC ≤ maxECapp

Localized release →

Sensors Contexts input frames app outputs

API 1 outputs; API 2 privacy losses; API 3 tracking requests

Relevance Self-Identification (API 3)

Unmodified Android / iOS

Streetscape Actuators API 1-based actuation

Neighboring nodes →

camera 1 camera 2

(b) Pedestrian safety app (visual intuition).

Attribution (API 3)

Input Frame Formation

API 1 outputs (bounded-hop sharing)

other sensors

Neighboring CityOS Nodes

Unmodified Linux

(a) CityOS architecture

Fig. 2. (a) CityOS architecture; (b), (c) running-example applications.

User device side. Some user devices run a CityOS mobile app alongside ordinary apps on Android or iOS. The CityOS app incorporates: an open-source implementation of Attribution [15] for privacy-budgeted API 3 participation; a Relevance Self-identification module that communicates with the node to determine whether the user is relevant to ongoing API 2 or API 3 measurements at a location; and a Privacy Loss Accounting module that accumulates API 2 and API 3 losses. In addition to this core app, each CityOS application may have companion mobile apps that leverage locally emitted signals. For example, a parking application may query nearby nodes for live availability and notify users when a spot is available near their destination (§5).

analogy: (1) functionality that requires raw sensing, and the outputs it produces, remains local to where it occurs; (2) functionality that requires information beyond a single moment relies on aggregation interfaces that bound what individual observations reveal; and (3) functionality that requires crosslocation information is mediated by user devices rather than by infrastructure tracking individuals across space. In addition, we adopt a data-minimization principle from our threat model: (4) both applications and the system itself minimize state accumulation, so that even if a node is temporarily compromised, the information exposed remains limited. Node-side architecture. Fig. 2a shows the CityOS architecture. CityOS is structured like a traditional OS, with a kernel, system services, and an API layer, but everything runs in user space over unmodified Linux. Applications run in sandboxed containers and access sensor data exclusively through the three-tier API. System services – including Object Detection, DP Continual Release, and Node-User Coordination – are trusted components that implement parts of the API. They operate atop the kernel’s abstractions and within constraints similar to untrusted applications, but with selectively expanded privileges as needed. The kernel provides the execution environment and I/O substrate: it assembles raw sensor data into input frames (the basic input unit) and groups them into temporally bounded contexts, the unit at which CityOS enforces ephemerality and output localization. An Output Controller governs all data leaving the node, routing outputs based on the API tier that produced them.

3.4 Execution Example We illustrate CityOS’s key mechanisms by tracing the three functions from §3.1 through the architecture. §5 describes our own implementations of these functions on CityOS. The real-time pedestrian alert runs as an API 1 application inside an ephemeral container. To the application, this appears as a continuously running container with access to sensor frames, but CityOS restricts this view to a sliding window of the last minEC frames. This provides sufficient temporal context to detect events such as collision courses, which cannot be inferred from a single frame. More precisely, CityOS guarantees that the container always holds at least minEC frames and never more than maxEC (older state is automatically expunged). The container emits outputs – here, collision warnings – through the Output Controller’s local5

ized release, either to nearby mobile devices or to a connected alert device. Fig. 2b visualizes our implementation. The per-intersection dashboard runs as an API 2 application. Each ephemeral container emits hourly pedestrian and vehicle counts into an aggregation window, whose duration is application-specified. At the end of each window, the kernel clamps each container’s contribution to a bounded sensitivity, sums the clamped values, and adds calibrated noise to produce a DP release – the only API 2 output that leaves the node, forwarded via cloud release to the backend. The associated privacy loss is broadcast locally so nearby devices can update their privacy loss accounting. Fig. 2c gives a screenshot of our implementation. Finally, citywide flow measurement uses API 3, implemented primarily on the mobile side. The node’s User-Device Coordination service emits annotated bounding boxes tagged with tracking or reporting requests. Nearby devices use the Node-User Coordination module on their side to determine whether they are relevant to the measurement. E.g., if the analysis concerns pedestrians, only devices carried by pedestrians self-identify as relevant, track locally, and later report encrypted, privacy-budgeted trajectories following W3C Attribution. The organization receives only aggregate flow statistics. §5 describes a related application we built on CityOS.

another sensor (e.g., audio). A frame may span multiple sensors captured at approximately the same moment and typically covers much less than one second. An ephemeral context is a bounded-time unit containing all input frames in a time window, any non-DP state derived from them, and any outputs produced from that state. CityOS enforces two parameters on every ephemeral context: maxEC, which bounds how far into the past outputs may depend on frames, and minEC, which ensures enough temporal context for correct execution. Applications choose minEC and maxEC values subject to minEC ≪ maxEC ≤ maxECapp , where maxECapp is a system-wide bound for unprivileged applications. CityOS also defines a larger bound, maxECsys , for privileged system services such as those used by API 2. We generally think of maxECapp on the order of seconds to a few minutes and maxECsys on the order of days. Ephemeral containers. CityOS realizes ephemeral contexts via ephemeral containers: sandboxed execution environments, implemented as a sequence of Docker containers, with no network access, persistent storage, or output except through the Output Controller. The lifetime of the output buffer is tied to the ephemeral context that produced it. To the application, execution appears continuous: it observes a stream of frames and always has access to at least the last minEC of context. Internally, CityOS enforces ephemerality via container rotation. As the active container approaches maxEC − minEC, CityOS launches a shadow container, feeds it the same incoming frames, and switches once it has accumulated minEC of state. The old container is then torn down and its memory destroyed. Thus, applications always receive the required minEC context for utility and should be structured to rely only on it (e.g., operate on a sliding window of size minEC), while never accessing more than maxEC, for privacy. From a privacy perspective, therefore, all API 1 outputs depend on at most the last maxEC data. This guarantee, however, holds only within the node: once outputs leave the node, CityOS can no longer control their lifetime. API 1 therefore couples ephemerality with localized release. Localized release. API 1 outputs leave the node only through the Output Controller’s localized release channel, the sole channel enabled by default. Conceptually, this is a boundedrange broadcast: outputs are sent to devices in the immediate vicinity of the node and are not forwarded to backend clouds or remote infrastructure. In practice, such scoping could be implemented over mechanisms such as private 5G [1], whose coverage area naturally limits dissemination (Appendix A). The Output Controller enforces two additional constraints. First, outputs inherit the ephemerality of the context that produced them: they are evicted from the node’s output buffer on the same schedule as the producing container’s teardown. Second, forwarding to neighboring CityOS nodes requires explicit administrative permission and a bounded hop count. This permits carefully scoped extensions – e.g.,

Design

Fig. 3 shows the detailed architectures of APIs 1 and 2; API 3 is illustrated in Fig. 4 in the appendix, though our description does not depend on it. We describe each API in turn, focusing on the key novel systems mechanisms needed to implement them. Security, privacy, and utility analyses appear in the appendix (§A, §B, and §C for APIs 1, 2, and 3, respectively). 4.1 API 1: On-Scene API 1 supports functions that require access to current sensor data to assess the present state of a space and act on it. Examples include extending a traffic signal’s green phase for a pedestrian with disabilities, spotting nearby parking, identifying safe delivery stops, and providing autonomous vehicles with an “eye-in-the-sky” perspective. These functions share a common access pattern: the application observes the current scene, makes a decision, and moves on. Some temporal context is needed – enough frames to understand the scene – but there is no inherent need to retain data or export it to a backend. Without architectural constraints, however, developers will be tempted to collect anyway, much as web and mobile applications routinely repurpose raw-data access for backend uses such as advertising, recommendations, or model training. API 1 is designed to preempt that default. Fig. 3(a) shows the API 1 architecture, which exposes three abstractions: input frames and contexts, ephemeral containers, and localized release. Input frames and contexts. A frame is the basic unit of sensor input: one or a few consecutive video frames from a camera, or the corresponding short sampling interval from 6

Ephemeral Container (App a)

Output Controller

(N = maxECsys/AWQ)

(minEC := maxECsys/2 ; maxEC := maxECsys)

(minEC ≪ maxEC ≤ maxECapp)

camera 1

camera 2 other sensors

Input Frames & Contexts

⓪

③

①②

time

output buffer

DP Continual Release Query Q (Query Q, ACQ)

Cloud (public) release OFF

(params: AWQ (=TC here); σQ) s in r Q ate s fo icip ase t r e a l x p 1) re 17±σQ2 + gN 5 12 (lo

Container 2 App a Container 1 App a

input frames

minEC (enforced for utility)

maxEC ≤ maxECapp (enforced for privacy)

Localized release ON

Neighboring nodes PERM

5±σQ2

input frames

t0 x

(minEC := 0; maxEC := TC)

(a) Architecture of API 1 (On Scene)

12±σQ2

TC #1

TC #2

…±σ2Q

Cloud (public) release ON

18±σQ2 3

3±σQ2

15±σQ2

released values (for utility)

35±σQ2

5 bikes 12 bikes 3 bikes 15 bikes

Object Detection & Tracking (API 1-3)

Output Controller

Ephemeral DP Continual Release

TC #3

time

TC #4

maxECsys

Query API (streaming COUNT | SUM | AVG)

Localized release ON

privacy losses for all releases from each query in Neighboring each TC nodes (for privacy ON transparen cy)

(b) Architecture of API 2 (Single-Locality Aggregation)

Fig. 3. Detailed design. (a) API 1 (On-Scene) architecture. (b) API 2 (Single-Locality Aggregation) architecture. API 3 (Cross-Locality Aggregation) is illustrated in Fig. 4. Key mechanisms: API 1: ephemeral containers, localized release; API 2: ephemeral DP continual release, bounded tracking contexts; API 3: relevance self-identification; and cross-cutting: device-side privacy accounting.

letting a parking application notify drivers of available spots one intersection ahead – without turning localized release into general cross-city dissemination. Sniffing risk and the maxEC tradeoff. Localized release assumes that API 1 outputs largely remain near the node that produced them, but nearby devices could collect and forward them to a backend. Shorter maxEC reduces the amount of history any such sniffer can recover, at the cost of greater container-rotation overhead and less temporal context for applications. We evaluate this tradeoff – privacy vs. utility vs. overhead – in §6.1 and find that for reasonable parameters, CityOS provides acceptable overhead and meaningfully limits small-scale sniffing. Against large-scale sniffing, ephemerality and localization alone do not suffice. Here CityOS follows the web’s emerging response to third-party tracking: it combines technical and regulatory defenses. API 1 defaults applications to anonymized inputs – bounding boxes, object classes, and tracking IDs from the trusted Object Detection and Tracking service – which reduce, though do not eliminate, reidentification risk. Beyond that, regulation should constrain systematic collection, retention, and resale of localized outputs that cannot be fully prevented technically.

CityOS splits aggregation into two APIs following the same-location principle (§3). API 2 handles single-locality measurements (e.g., per-intersection dashboards, parking occupancy prediction), implemented as a centralized DP computation at each node. API 3 handles cross-locality measurements, as discussed in §4.3. Architecture. Fig. 3(b) shows the API 2 architecture. A trusted system service (Ephemeral DP Continual Release) evaluates streaming queries over a local event stream and periodically emits differentially private aggregates. Events are produced by the trusted Object Detection and Tracking service running at the node. Released values are treated as public outputs and routed through the Output Controller to application backends. The associated privacy loss is broadcast locally so that nearby devices can track their cumulative exposure. All non-DP internal state lives inside an ephemeral container and is discarded upon rotation; the container parameters that make this work are described below. Query API. API 2 exposes a streaming query interface over a continuous event stream, inspired by classic streaming engines [16]. The default stream is produced by the trusted Object Detection service, which emits tuples of the form ⟨objectID, objectType, features, speed⟩. Applications register queries using the following template.

4.2 API 2: Single-Locality Aggregation Longitudinal statistics at a single location, such as traffic counts over hours, parking-demand forecasts, and near-collision frequency, are among the most common workloads in urban sensing. Without a structured interface, the path of least resistance is to stream raw video to a backend and run queries there, accumulating the kind of persistent behavioral record that CityOS is designed to prevent. API 2 exists to break that default. It provides a streaming aggregation interface that releases only DP statistics, never raw observations.

{COUNT | SUM | AVG} OVER stream WHERE objectType ∈ 𝑇 ∧ features |= 𝜙 WINDOWED BY AW 𝑄 WITH SIGMA 𝜎𝑄

where AW 𝑄 is the aggregation window and 𝜎𝑄 is the standard deviation of the noise added upon each release for DP. To enable efficient multi-scale aggregation, AW 𝑄 is restricted to dyadic intervals of the form maxECsys /2𝐾 . Ephemeral DP continual release. API 2’s central challenge is reconciling continual release with data minimization. Stan7

dard continual-release mechanisms [17, 64] maintain state across an unbounded stream so that interval queries can be answered with bounded noise. CityOS’s data-minimization principle (§3.3), however, requires all non-DP state to be discarded within maxECsys , even for trusted components. Resolving this tension is API 2’s core contribution. We support two continual-release mechanisms, binary tree [17] and Toeplitz [64], offering better bounds under different DP regimes (binary tree for pure DP, Toeplitz for approximate DP). Our evaluation (§6) uses the latter, but we explain the former for simplicity. Let 𝑁 = maxECsys /𝐴𝑊𝑄 denote the number of aggregation windows per ephemeralcontainer lifetime. In the binary tree mechanism, each aggregation window corresponds to a leaf in a complete binary tree of 𝑁 leaves, and internal nodes represent unions of contiguous dyadic ranges. At the end of each window, the system releases the noisy leaf and any newly completed internal nodes. Each leaf contributes to log2 𝑁 + 1 releases, and any query over a contiguous interval ≥ 𝐴𝑊𝑄 can be answered by combining at most 2(log2 𝑁 − 1) noisy nodes (for 𝑁 ≥ 4), yielding bounded error [17]. Fig. 3(b) illustrates this with the query COUNT DISTINCT

proach of propagating per-user contribution bounds through query operators [9] cannot be applied directly. CityOS addresses this by exposing two modes for operators to choose on the formality–utility spectrum. Untrusted mode (formal, high noise). Following prior work on DP analytics over untrusted video pipelines [13], the untrusted mode treats all events in an aggregation window as potentially originating from a single individual. This yields a sound DP guarantee without any identity assumption, but at the cost of high sensitivity. Counting queries become bounded-sum queries whose noise scales with a declared count range (e.g., 100 to be able to count up to this many people). The result is formal but often impractical for finegrained measurements, since the noise can overwhelm the signal. Moreover, counting an unexpectedly large crowd may fail altogether if the true count exceeds the declared range. Trusted mode (empirical, low noise). For applications whose queries can be expressed in terms of the set of objects supported by our trusted Object Detection and Tracking service, CityOS recovers a limited notion of per-person identity through bounded tracking contexts (TCs). A TC is a short, system-defined time window (on the order of minutes) within which the trusted service tracks objects using BoT-SORT [3] as they move through, exit, and re-enter the scene. Each detected object receives a unique ID that we use to bound its contribution to queries within that TC. The service runs in an ephemeral container with maxEC = 𝑇𝐶 and minEC = 0; identifiers are scoped to a single TC, reset across contexts, and never persist beyond it. If tracking were perfect, the sensitivity of a count-distinct query would be exactly 1. In practice, tracking errors (ID switches due to occlusion, re-entry, or appearance changes) may assign multiple IDs to a single individual; we empirically characterize these errors on standard benchmarks and derive a conservative per-person contribution bound (§6.2). Concretely, we benchmark a production YOLOv26n + BoT-SORT pipeline on four static-camera MOT17 sequences and find that 56.5% of individuals receive exactly one ID, with p90=4, p95=5, p99=7, and a worst-case maximum of 9. Setting Δ=9 covers every individual in the benchmark and yields an ≈11× noise reduction over the untrusted mode. The trusted mode’s guarantee is therefore empirical, resting on an assumption about tracker fidelity rather than a worst-case bound. This is analogous to how real-world DP deployments (e.g., DP-SGD for ML training) routinely rely on empirical assumptions about privacy units. More importantly, the design surfaces a new problem at the intersection of computer vision and DP, namely, developing tracking models whose error bounds can be formally incorporated into privacy guarantees (e.g., folded into the failure probability of approximate DP). We leave this to future work. Under either mode, CityOS enforces (user, TC)-level DP at each node (proofs and parameters in §B), maintaining

... WHERE objectType = bicycle WINDOWED BY 60s WITH SIGMA 1. Assuming each bicycle contributes at most once

per 60-second interval, the system computes the distinct count each minute and releases the noisy leaf plus newly completed internal nodes. A dashboard then estimate counts over coarser intervals by summing released nodes; e.g., the count over 𝑡 1 –𝑡 3 uses 𝑡 1 –𝑡 2 and 𝑡 2 –𝑡 3 , with variance 2𝜎𝑄2 . To enforce ephemerality while preserving utility, we host the release service in an ephemeral container with maxEC = maxECsys and minEC = maxECsys /2. This ensures that any interval of length at most maxECsys /2 is fully contained within at least one container instance, so queries over such intervals can be answered from a single tree with noise comparable to the vanilla binary tree. For longer intervals, we characterize utility in §B, deriving coefficients for the linear growth in error with the number of ephemeral contexts spanned. Because shadow containers do not release outputs, the design introduces only one additional noisy node compared to a tumbling-window baseline (log2 𝑁 + 2 versus log2 𝑁 + 1 releases per container lifetime), yielding a fixed-utility guarantee over sliding windows of size maxECsys /2 with modest additional privacy loss. Privacy unit and sensitivity. DP requires bounding how much any single individual can influence released aggregates. On the web, this is straightforward. Sessions, cookies, and account identifiers give first parties a natural way to group and cap per-user contributions [9]. In public-space sensing, the infrastructure is passive, observing individuals without explicit interaction, and thus lacks stable per-person identifiers. This is a fundamental challenge of the domain, not specific to CityOS, and means the standard DP-SQL ap8

(7) batch of encrypted reports

app1.ex (App 1 cloud)

(8) Secure Aggregation

Architecture. Fig. 4 shows the API 3 architecture, which splits responsibility between infrastructure and user devices. Applications register measurement tasks with CityOS nodes in the target region, specifying simple device-side actions such as recording entry time or reporting elapsed time upon exit. Nodes store these tasks and broadcast them locally to nearby devices. Devices that receive a task execute it locally, recording minimal state while the user is in the region and, upon exit, generating encrypted reports that encode bounded statistics (e.g., time spent, or coarse trajectory summaries). These reports are sent to the application backend, which aggregates them across users using secure aggregation (e.g., MPC or TEE) and releases only DP results. Throughout, infrastructure never observes individual trajectories; nodes determine when and which measurements to perform, but all sensitive state and privacy enforcement remain on devices. This workflow mirrors Attribution’s own primitives adapted to physical space; §C gives an intuitive mapping, based on which we claim CityOS’s API 3 DP guarantees; a formal mapping and analysis are pending work at the time of this writing. Privacy model. Unlike API 2, where privacy is enforced at the node, API 3 enforces and accounts for privacy entirely on-device. Each device maintains an individual DP (IDP) budget over coarse-grained epochs. Each report consumes budget; once exhausted, further contributions are suppressed. CityOS reuses Attribution’s on-device IDP accounting and composes it with API 2 losses, exposing a unified privacy-accounting interface. API 3 therefore provides strong per-device, per-epoch guarantees without requiring infrastructure to maintain per-user state. Subpopulation disambiguation. The design above assumes measurements over all users in a region. In practice, applications often require subpopulation-specific statistics, such as pedestrians vs. cyclists or trucks vs. passenger vehicles. On the web, Attribution supports such distinctions because the querier interacts directly with the user (e.g., via an HTTPS session at conversion time) and can assign reports to measurement classes. In CityOS, nodes have no such direct interaction with devices; absent additional mechanisms, devices would participate based only on location, not on the querier’s intended population. This is a utility challenge rather than a privacy one, and it requires a coordination mechanism that does not itself create new tracking vectors. This raises a core systems question, namely, how to coordinate infrastructure and user devices to recover this capability without introducing new privacy-leakage channels. Node-user coordination. CityOS addresses this through a two-sided mechanism that combines local broadcast with on-device inference. On the node side, the Node-User Coordination service runs alongside the Object Detection and Tracking service within a bounded tracking context. For each detected object, the node attaches metadata indicating which

MPC/TEE

(9) DP aggregated results (6) encrypted reports

(1) register API 3

(5) encrypted

measurement

report

(2) CityOS Node registered API 3 measurements [;]

[;]

JSON

Object Detection & Tracking (API 1-3) Node-User Coordination (API 2-3)

from others

(3) locally broadcast API 3 measurement requests (saveEvent; sendReport)

CityOS Mobile

(4) (3)CityOS Mobile Attribution (API 3) report generation

Device-Side Privacy Accounting (API 2-3) Relevance Self-Identification (API 3)

(minEC=0; maxEC=TC, same container as API 2)

Fig. 4. API 3: Cross-Locality Aggregation. Key concepts: device-mediated federated measurement, on-device IDP enforcement, and node-user coordination for context-aware participation.

per-TC budgets that bound total privacy loss per individual. Device-side privacy accounting. Shorter TCs better align with our limited-tracking principle and allow more frequent releases, while longer TCs provide a more meaningful privacy unit. We address this tension by keeping TCs short and enabling coarser-grained composition on user devices. At the beginning of each TC, the node assigns it a unique identifier (tcId) and computes the maximum privacy loss 𝜌 any individual present during that TC may incur, accounting for all relevant releases across all queries, including those in future TCs. The node then continuously broadcasts ⟨tcId, 𝜌⟩ locally and we assum that if an individual can be sensed, the individual also hears the broadcast. Devices record this loss once per TC. Thus, although API 2 enforces privacy separately at each node and over short TCs, devices compose losses into a longitudinal, city-wide view of privacy cost. 4.3 API 3: Cross-Locality Aggregation Cross-location analytics, such as pedestrian flows between neighborhoods, transit origin–destination estimation, and how infrastructure changes affect foot traffic, rely on centralized pipelines that reconstruct individual trajectories from mobile-location data [74]. API 3 replaces these pipelines with a federated interface adapted from W3C Attribution, where user devices produce encrypted, privacy-budgeted reports and infrastructure never observes individual trajectories. Use cases. API 3 supports measurements over spaces that span multiple CityOS nodes and have well-defined entry and exit boundaries, such as commercial corridors, transit systems, or highway segments. While users remain within such a region, their devices locally record limited state (e.g., entry time or coarse trajectory features); upon exit, they generate encrypted reports that are aggregated with DP. This model supports estimating pedestrian flows between neighborhoods, measuring transit-route popularity, and evaluating the impact of infrastructure changes without persistent identifiers or infrastructure-based tracking. 9

API 3 measurements are relevant (e.g., a bicycle-only measurement is attached only to bicycle detections; a corridorentry measurement only to objects observed entering the region). These per-object annotations are broadcast locally using the same localized-release channel as API 1. On the device side, upon receiving annotated signals, the device determines whether any of the broadcast tracks correspond to the user carrying it. It does so using onboard IMU data to classify coarse activity (pedestrian, cyclist, driver) and, when finer disambiguation is needed, to match its motion trace against nearby object tracks via cadence or motion-pattern analysis. The device then participates only in measurements for which it identifies itself as relevant. We call this process relevance self-identification and it is performed by an on-device homonymous component (Fig. 2a). In simple cases, activity classification alone suffices; in more complex ones (e.g., entry vs. exit, or truck vs. car), track matching leverages infrastructure as a source of disambiguating context that mobile sensing alone cannot provide, while all identification logic remains on-device.

small number of hops), enabling (iv) nearby users running the companion mobile app to receive real-time availability. In parallel, the API 2 workflow is: (v) the app registers a counting query with the DP Continual Release service to obtain DP estimates of parking occupancy over an aggregation window (e.g., one hour). (vi) These DP releases are sent to the application backend, which trains a simple predictive model (e.g., based on time of day and day of week). The mobile app can then request availability forecasts while the user is still far from the destination. Dashboard App (API 2). (Fig. 2c) Provides per-location traffic statistics for city planners. The application registers counting queries for pedestrians, vehicles, and bicycles with the API 2 DP Continual Release service (§4.2), which aggregates events over time and forwards differentially private counts to the backend, where the dashboard visualizes them as hourly breakdowns with confidence intervals. Subway Trajectories (API 3). Estimates the popularity of subway routes without tracking riders. The NYC subway lacks accurate route-level statistics because riders tap in but do not tap out, forcing reliance on indirect, per-station estimates. The workflow is: (i) CityOS nodes deployed at turnstiles (entry/exit points) broadcast measurement requests to nearby devices; (ii) devices record entry location and time upon entering the system; (iii) upon exit, devices submit encrypted, privacy-budgeted reports encoding entry location and elapsed time; and (iv) the backend aggregates these reports with DP to estimate route popularity and travel times. Devices use node-user coordination to self-identify as entrants or exiters and execute the appropriate actions. This enables route-level measurement without persistent identifiers, tracking, or face recognition, relying instead on devicemediated, privacy-bounded reporting.

Prototype and Applications

We implement CityOS in ∼4,100 LoC of Go, ∼530 LoC of Python, and ∼2,300 LoC of Rust, and build fourapplications, plus the Object Detection and Tracking service, itself an API 1 app. We describe the fourapplications below, two of which are illustrated via workflow visualizations in Fig. 5. Pedestrian Safety (API 1). (Fig. 5a) Provides real-time alerts for imminent pedestrian-vehicle collisions. The workflow is: (i) raw input frames are processed by (ii) the trusted Object Detection and Tracking service, which produces pedestrian, cyclist, and vehicle tracks; (iii) the pedestrian safety application, running in an API 1 ephemeral container, uses these tracks to estimate collision risk based on distance and relative velocity over time. Collision detection requires temporal context, as distinguishing a true collision course from momentary proximity requires several seconds of motion history. The application thus requests minEC = 2s, with maxEC ≤ maxECapp enforced by the system. When risk exceeds a threshold, the application (iv) emits alerts via localized release to nearby streetscape devices (e.g., speakers). Parking App (API 1+API 2). (Fig. 5b) Spans two API tiers: (1) to provide real-time spot availability to nearby users via a companion mobile app (API 1); and (2) to provide future availability predictions by training on DP aggregates of parking occupancy (API 2). The API 1 workflow is: (i) raw input frames are processed by (ii) the trusted Object Detection and Tracking service, which outputs bounding boxes with object classes; (iii) the parking app maps detected vehicles to predefined parking-spot polygons (shown in the figure using an aerial view of the lot), identifying occupied and available spots based on position. The result is a per-frame list of spot IDs marked available or occupied. This information is broadcast locally (and, with administrative permission, within a

Evaluation

We evaluate CityOS primarily at the API-mechanism level, using a representative workload per tier to measure the privacy-utility tradeoffs induced by each abstraction. These workloads exercise the core mechanisms that underlie the prototype applications in §5: ephemeral localized execution (API 1), DP continual release (API 2), and device-mediated cross-locality aggregation with self-identification (API 3). We evaluate: how effectively maxEC limits sniffing attacks and at what latency cost (API 1), whether DP continual release preserves useful counting accuracy (API 2), and whether cross-locality aggregation recovers useful statistics under per-device privacy budgets, and how self-identification quality affects that utility (API 3). All node-side experiments run on an Nvidia Jetson AGX Orin edge GPU, representative of embedded edge accelerators; we also benchmark API 1 on a desktop 5060 Ti (§D.1). Our primary accuracy metric is RMSRE (root mean square relative error [33]), the RMS of per-bin relative deviations from ground truth. We use Toeplitz for DP continual release. 10

(ii) Object Detection and Tracking (trusted system service)

CityOS node side (i) Raw input frames

(ii) Object Detection

User device side (iv) CityOS-Parking mobile

(iii) CityOS-Parking app

API 1

CityOS Parking

actual screenshot

(i) Raw input frames

real-time spots localized release (car-to-parking spot mapping; EC: minEC=30s; maxEC=maxECapp)

API 2 DP aggregation noised counts (iii) Ped Safety App (EC: minEC=30s; maxEC=maxECapp)

(iv) Streetscape Actuator: Audio signal alarm (visualization)

DP counts cloud release

(v) DP Continual Release

predictions

App cloud trains models

(vi) CityOS-Parking cloud

(b) Parking application

(a) Pedestrian Safety application

Fig. 5. CityOS application workflows. (a) Pedestrian safety (API 1). (b) Parking app (API 1+API 2).

Methodology details (hardware configuration, dataset preprocessing, noise parameters) are in §D.

mode. The trusted mode has empirical but tight sensitivity; the untrusted mode provides sound but high sensitivity. Empirical sensitivity. Trusted-mode sensitivity Δ equals the maximum track-ID multiplicity a single person produces per release period (𝜌 track in our formal model, §B). We benchmark the production YOLOv26n + BoT-SORT pipeline on four static-camera MOT17 sequences [49] (3,012 frames, 191 matched identities; pipeline and matching details in §D.2). Fig. 6b summarizes the distribution. The median is 1 ID per person (56.5% receive exactly one), with p90=4, p95=5, p99=7, and a worst-case maximum of 9. We conservatively set Δ=9 so the DP guarantee holds for every individual in the data. Using p95 (Δ=5) reduce noise 1.8× while still covering 96.9% of individuals; p99 (Δ=7) covers 99% with 1.3× less noise. For the untrusted path, Δ=100 (operator bound), yielding an ≈11× sensitivity gap that propagates linearly into noise. Counting accuracy. We evaluate on 30 days of 15-minute bicycle counts from the Williamsburg Bridge Eco-Counter [56], aggregating over windows from 1 to 12 hours and reporting average RMSRE over 1,000 Monte Carlo trials. Fig. 6c shows the results across three configurations: trusted at 𝜀=1, trusted at 𝜀=0.1 (a 10× stricter budget), and untrusted at 𝜀=1. The untrusted mode incurs a fixed ≈11× penalty across all release periods, reflecting the linear scaling of noise with sensitivity. Aggregation dominates accuracy: at 𝜀=1, trusted RMSRE drops from 2.77 (1 hour) to 0.29 (6 hours) to 0.08 (12 hours), a ∼35× improvement at fixed privacy cost. At p95 (Δ=5) these values would be 1.8× lower. Even with a 10× smaller 𝜀=0.1, the trusted path (RMSRE 2.84 at 6 hours) still beats untrusted at 𝜀=1 (RMSRE 3.21), because trusted mode reduces sensitivity by ≈11×, more than compensating for the tighter budget.

6.1 API 1 On-Scene API 1’s main knob is maxEC, the ephemeral context’s lifetime. Shorter ECs reduce what a nearby sniffer can recover from any one location, but they also increase container-rotation overhead. We therefore evaluate both sides of this tradeoff, namely privacy exposure under sniffing attacks from §4.1 and latency overhead in Object Detection and Tracking services. Sniffing Attack with maxEC. We simulate a small-scale sniffing adversary traversing Midtown Manhattan and, upon reaching an intersection, reads the API 1 output buffer and saves it. We maliciously grant the attacker the full buffer contents at arrival. We vary maxEC across {30 s, 1 min, 2 min, 3 min, 4 min, 5 min} and report the fraction of total city-wide person-activity captured over one hour. We consider four attacker profiles that traverse the evaluated perimeter at different speeds, namely a pedestrian, a cyclist, a car, and a static device planted at Times Square (speeds in Fig. 6a). Fig. 6a shows that maxEC is an effective privacy knob against mobile sniffers. For the fastest attacker (car), capture rises from 0.11% of city-wide person-activity at maxEC=30 s to 0.95% at 5 min (∼9×); pedestrians and cyclists follow the same trend, rising from 0.05% to 0.41% and from 0.09% to 0.84%, respectively; the car visits roughly 147 of the ∼540 intersections (27%) yet captures under 1% of city-wide activity. A static attacker captures ∼0.1% regardless of maxEC, since it observes only one location. Together, these results show that ephemerality primarily limits what mobile sniffers can accumulate across locations, while localization confines any static compromise to its immediate vicinity. Performance overhead. On a desktop 5060 Ti, frame drops reach near-zero by maxEC≥10 s; the Jetson AGX Orin plateaus near ∼17% drops due to slower container startup (Fig. 8; details in §D.1).

6.3 API 3 Cross-Location Aggregation API 3 is the strongest test of the architecture, aiming to recover cross-location statistics without allowing infrastructure to track individuals. We evaluate two questions. First, how much utility is lost when devices enforce per-user privacy budgets and stop reporting after exhaustion? Second, how sensitive is that utility to imperfect self-identification? We use the subway origin-destination (OD) estimation ap-

6.2 API 2 Single-Locality Aggregation API 2 replaces raw longitudinal collection at a node with DP continual release. The key question is whether releases remain useful. We compare trusted mode against the untrusted 11

0.6%

# track IDs / person

0.4% 0.2% 0%

½1

maxEC

(min)

Mean Median p90 p95 p99 Max

1.92 1 4 5 7 9

=1 ID ≤2 IDs ≤3 IDs ≤5 IDs

56.5% 77.0% 88.5% 96.9%

Untrusted ( =100), =1 Trusted ( =9), =0.1 Trusted ( =9), =1

Untrusted ( =100), =0.1 omitted: RMSRE 303 9

1 2

10 12

1-hour batch 1-day batch 1-week batch

1.25 1.00 0.75 0.50 0.25 0.00

1 2 3 4 5 6 7 8 9 10

Aggregation Window (hours) (b) API 2 sensitivity study

(a) API 1 sniffing attack

30 25 20 15 10 5 0

RMSRE

0.8%

Car (13.4 m/s) Cyclist (5.4 m/s) Pedestrian (1.3 m/s) Times Sq (0 m/s)

RMSRE

Activity Sniffed (%)

per device per week

(d) API 3 subway OD accuracy

0.4 0.2 0.0 0.0

Accuracy F1 (macro)

0.5

1.0

1.5

2.0

Noise level (× feature std)

0.6 0.4 0.2 0.0 0.0

2.5

5.0

7.5

0.6 0.4

Number of distractor tracks

2 1

0.2 0.0

10.0

RMSRE

0.6

Match F1 (micro)

Score

Fig. 6. Evaluation of CityOS APIs. (a) API 1 sniffing-attack effectiveness under time-scoped, localized outputs. (b) API 2 empirical sensitivity study. (c) API 2 DP counting accuracy (trusted vs. untrusted). (d) API 3 subway origin-destination (OD) accuracy vs. per-device budget. 1.0 1.0 1.0 p=0 p = 0.5 0.8 0.8 0.8 3 p=1

Smoothing window size

(a) Phase 1 IMU activity classification (b) Phase 2 matching with distractors (c) Phase 2 matching with smoothing

0 0.00

0.25

0.50

0.75

1.00

Self-Identification F1 Score (d) Subway OD utility

Fig. 7. API 3 self-identification evaluation. (a)–(c) Accuracy of our two-stage self-identification pipeline. (d) Impact of identification errors on subway OD.

plication from §5. We answer the first question here and the second in the subsequent section. We use the Hangzhou Metro smart-card dataset (29.2 M trips by 4.97 M riders across 80 stations over 25 days). Each entry event is stored on-device, and each exit generates a report charging 𝜀 rep =0.5 against a weekly device budget 𝜀. Reports are DP-aggregated per exit station to produce an OD histogram. We vary 𝜀 across {1, . . . , 10, ∞} and batch lengths of one hour, one day, and one week, reporting RMSRE. Fig. 6d shows three regimes. First, weekly batches isolate the effect of budget exhaustion. Because bins are large (∼1,140 trips/bin), the DP noise floor is tiny (RMSRE 0.0025), so error is driven mainly by how many riders exhaust their budgets. RMSRE drops sharply from 0.81 at 𝜀=1 to 0.083 at 𝜀=5 and to 0.020 at 𝜀=10. This reflects the rider distribution, since 93% of riders make at most 10 trips per week and are therefore fully covered once 𝜀 ≥ 5. Second, daily batches trade some accuracy for finer time resolution. RMSRE falls from 0.88 at 𝜀=1 to 0.13 at 𝜀=5, 0.042 at 𝜀=7, and 0.028 at 𝜀=10, approaching the daily noise floor of 0.016, accurate enough for ranking high-volume corridors without constructing infrastructure-side trajectories. Hourly batches are noise-limited (RMSRE 0.32 even at 𝜀=∞ with ∼9 trips/bin), placing the operating point at daily-to-weekly aggregation.

stage self-identification pipeline and (2) how identification errors affect cross-locality utility. Non-vital methodological details for each experiment are in §D.4. Stage 1 activity classification from IMU. We classify device activity (walking, driving, cycling) from IMU signals using a gradient-boosting model trained on standard IMU datasets spanning pedestrian, vehicle, and cycling traces [43, 65, 79]. To measure robustness, we inject additive Gaussian noise scaled by the per-feature standard deviation of the test set (x-axis, so 0.0 is clean data, 1.0 adds noise with the same spread as the original features, and 2.0 doubles it), retraining at each scale. Fig. 7a shows that Stage 1 is highly accurate and robust to noise. On clean data, it achieves 99.7% accuracy and 99.2% macro F1, with per-class F1 of 99.9% (Walking), 99.8% (Driving), and 97.9% (Cycling). With noise-augmented training, it retains 98.1% accuracy (97.8% F1) at noise equal to one feature standard deviation, degrading gracefully to 78.0% accuracy at 2× noise. This places the system in a high-F1 regime under realistic sensing conditions. Stage 2 bounding-box to IMU matching. Stage 2 matches pedestrian phones to visual tracks by comparing walkingband (0.7–3.0 Hz) power spectral densities of each phone’s IMU signal and each track’s visual motion, forming a pairwise cosine-distance matrix, and solving the assignment with the Hungarian algorithm. An adaptive null-assignment penalty routes unmatched tracks to a dummy, so extra visual tracks do not force incorrect pairings. We evaluate using window-level micro-averaged F1 on outdoor pedestrian traces from Vi-Fi [43]. With no distractors, Stage 2 achieves

6.4 API 3 Self-Identification The preceding section assumed that devices can determine whether they are relevant to a measurement (e.g., whether they are entering vs. exiting a subway station). We now evaluate this assumption, studying (1) the accuracy of our two12

Privacy and governance. Anonymization techniques do not compose under linkage [20]. Legal frameworks [21, 24, 25, 54] specify obligations but not enforcement; federated learning [62] protects training data but not inference flows. The closest precedent, W3C Attribution API [75, 78], replaced cross-site tracking with differentially private measurement; CityOS applies this principle to physical sensing.

F1 of 0.72. Fig. 7b shows that injecting up to 10 distractor tracks degrades F1 gradually. Fig. 7c shows that temporal smoothing over 5–7 windows further improves stability by correcting transient mismatches. This demonstrates that cross-modal matching remains reliable in crowded scenes. Impact on API 3 utility. We evaluate how self-identification quality affects the subway OD measurement from §6.4, which assumed perfect classification. In practice, transfer passengers may be misclassified as exiters, injecting spurious reports. We reuse the Hangzhou Metro dataset and infer 13.6 M transfer events. We model self-identification with recall 𝑎 ∈ [0, 1] and false positive rate 1−𝑎, vary station geometry via 𝑝 ∈ {0, 0.5, 1} (the fraction of transfers near exits), and report weekly RMSRE including the analytic noise floor (0.0025). Fig. 7d shows that classification quality directly determines OD utility. At F1=1, all curves collapse to the noise floor; at F1=0.5, RMSRE reaches 2.14 in the worst case (𝑝=1) versus 1.35 with no transfer traffic (𝑝=0), showing that false exits dominate the error budget. Missed exits reduce counts in bins that already carry signal, but false exits both inflate counts and introduce nonzero entries in zero-valued bins, producing disproportionately large relative errors. Station layouts that separate transfer paths from exits (low 𝑝) suppress the more damaging error mode. Degradation is gradual. At F1=0.9, worst-case RMSRE is 0.49, sufficient for corridorlevel rankings. Since Stage 1 achieves 97.8% F1 under realistic noise, the system operates in a regime where RMSRE approaches the noise floor, showing CityOS supports accurate OD estimation without infrastructure-level tracking.

Conclusion

We presented CityOS, a privacy architecture for urban sensing grounded in a web-to-physical-world data-access analogy, with three API tiers enforced by ephemeral containers, localized release, DP continual release, and node-device coordination. Five prototype applications demonstrate practical smart-space functionality with privacy guarantees.

Acknowledgments This work was supported by the National Science Foundation (NSF) and Center for Smart Streetscapes (CS3) under NSF Cooperative Agreement No. EEC-2133516. We thank CS3 members for discussions and feedback about the project, especially Jason Hallstrom, Henning Schultzrinne, and Andrew Smyth. A number of students contributed to the development of CityOS: Kimberly Collins (container lifecycle fixes), Othmane El Houssi (frame garbage collection and output driver acknowledgements), Ian Kammerman (integration testing and macOS support), Christian Montgomery (stream access control), Apolline Weinstein (inter-node communication and output buffer API), and Seojin Yoon (video and webcam input drivers), all at Columbia University; and Maahin Rathinagiriswaran (IMU classifier) at Rutgers University. Pierre Tholoniat, Jessica Card, and Alison Caulfield (Columbia University) contributed to the development of the Attribution library we are using, including core DP accounting, Python bindings, and logging infrastructure, respectively. We thank them all for their valuable work. This article was edited with the assistance of generative AI. All ideas, design details, analyses, and results originate from the authors. The text was initially written by the authors, then edited with AI for clarity, concision, and structure, and finally verified by the authors for accuracy and authenticity. The CityOS code was developed in a similar author-originated, AI-assisted, and author-validated manner.

Related Work

CityOS draws on four lines of prior work, each exposing a facet of the same gap, namely the absence of privacyenforcing interfaces at the data-access layer. Inspired by the web’s shift toward privacy-conscious platform APIs, CityOS fills this gap with purpose-built, risk-calibrated interfaces. Urban sensing. Urban sensing spans fixed networks [52], mobile collection [34], and participatory paradigms [12]. Multi-year deployments [14, 53, 68] show that privacy concerns surface only after hardware is fielded; CityOS defines data-access constraints before applications are deployed. Platforms and interoperability. sMAP [18] showed that standardizing interfaces unifies heterogeneous feeds. Cityscale standards [23, 59, 60] and platforms built on them [27, 35, 38] centralize raw streams before evaluating access policy. CityOS intervenes earlier so re-identifiable data never reaches a backend store. Edge and fog computing. NIST [36] and ETSI MEC [22] formalize compute near endpoints, driven by bandwidth and latency constraints on modalities like video [66]. Waggle/SAGE [8] embodies “process locally, export derived products” but provides no mechanism to bound what an edge plugin may export; CityOS adds this missing layer through its three API tiers. 13

References

[17] T.-H. Hubert Chan, Elaine Shi, and Dawn Song. 2011. Private and Continual Release of Statistics. ACM Transactions on Information and System Security 14, 3 (2011), 26:1–26:24. doi:10.1145/2043621.2043626 [18] Stephen Dawson-Haggerty, Xiaofan Jiang, Gilman Tolle, Jorge Ortiz, and David E. Culler. 2010. sMAP: A Simple Measurement and Actuation Profile for Physical Information. In Proc. ACM Conference on Embedded Networked Sensor Systems (SenSys). 197–210. doi:10.1145/1869983. 1870003 [19] Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith. 2006. Calibrating Noise to Sensitivity in Private Data Analysis. In Theory of Cryptography (Lecture Notes in Computer Science), Shai Halevi and Tal Rabin (Eds.). Springer, Berlin, Heidelberg, 265–284. doi:10.1007/ 11681878_14 [20] Cynthia Dwork and Aaron Roth. 2014. The Algorithmic Foundations of Differential Privacy. Foundations and Trends in Theoretical Computer Science 9, 3–4 (2014), 211–487. doi:10.1561/0400000042 [21] ETSI. 2020. Cyber Security for Consumer Internet of Things: Baseline Requirements (EN 303 645). Technical Report. European Telecommunications Standards Institute. https://www.etsi.org/deliver/etsi_en/ 303600_303699/303645/ [22] ETSI. 2024. Multi-access Edge Computing (MEC); Framework and Reference Architecture (GS MEC 003 v3.2.1). Technical Report. European Telecommunications Standards Institute. https://www.etsi.org/deliver/ etsi_gs/MEC/001_099/003/ [23] ETSI. 2024. NGSI-LD API (GS CIM 009). Technical Report. European Telecommunications Standards Institute. https://www.etsi.org/deliver/ etsi_gs/CIM/001_099/009/ [24] European Parliament and Council. 2016. General Data Protection Regulation (GDPR) – Regulation (EU) 2016/679. https://eur-lex.europa. eu/eli/reg/2016/679/oj/eng [25] Michael Fagan, Katerina N. Megas, Karen Scarfone, and Matthew Smith. 2020. IoT Device Cybersecurity Capability Core Baseline. Technical Report NISTIR 8259A. National Institute of Standards and Technology. doi:10.6028/NIST.IR.8259A [26] Hendrik Fichtenberger, Monika Henzinger, and Jalaj Upadhyay. 2023. Constant Matters: Fine-grained Error Bound on Differentially Private Continual Observation. In Proceedings of the 40th International Conference on Machine Learning. PMLR, 10072–10092. https://proceedings. mlr.press/v202/fichtenberger23a.html [27] FIWARE Foundation. 2016. FIWARE: An Open Platform for Future Internet Applications and Smart Cities. https://www.fiware.org/. [28] Ganz Security. 2024. Smart Cities Today Using Tomorrow’s Security Technology. Industry report. https://www.ganzsecurity.com/blog/ smart-cities-today-using-tomorrows-security-technology [29] Gothamist. 2026. NYC Wegmans is Storing Biometric Data on Shoppers’ Eyes, Voices and Faces. Gothamist (2026). https://gothamist.com/news/nyc-wegmans-is-storing-biometricdata-on-shoppers-eyes-voices-and-faces [30] Nicolas Grislain, Paul Roussel, and Victoria de Sainte Agathe. 2024. Qrlew: Rewriting SQL into differentially private SQL. arXiv preprint arXiv:2401.06273 (2024). [31] Ahmad Hassan, Arvind Narayanan, Anlan Zhang, Wei Ye, Ruiyang Zhu, Shuowei Jin, Jason Carpenter, Z. Morley Mao, Feng Qian, and ZhiLi Zhang. 2022. Vivisecting Mobility Management in 5G Cellular Networks. In Proc. ACM SIGCOMM. 86–100. doi:10.1145/3544216.3544217 [32] Katherine Hausladen, Oliver Wang, Sophie Eng, Jocelyn Wang, Francisca Wijaya, Matthew May, and Sebastian Zimmeck. 2025. Websites’ Global Privacy Control Compliance at Scale and over Time. https://www.usenix.org/conference/usenixsecurity25/presentation/ hausladen. In 34th USENIX Security Symposium (USENIX Security 2025). USENIX Association, Seattle, WA, 5837–5856. [33] Michael Hay, Vibhor Rastogi, Gerome Miklau, and Dan Suciu. 2010. Boosting the Accuracy of Differentially Private Histograms Through Consistency. Proceedings of the VLDB Endowment 3, 1 (2010), 1021–

[1] 3GPP. 2025. System architecture for the 5G System (5GS); Stage 2. Technical Specification (TS) TS 23.501 v18.9.0. 3rd Generation Partnership Project (3GPP). https://www.3gpp.org/ftp/Specs/archive/23_series/23. 501/ Release 18, §5.30 (Non-Public Networks). [2] Paarijaat Aditya, Rijurekha Sen, Seong Joon Oh, Rodrigo Benenson, Bobby Bhattacharjee, Peter Druschel, Tongtong Wu, Mario Fritz, and Bernt Schiele. 2016. I-Pic: A Platform for Privacy-Compliant Image Capture. In Proc. 14th ACM International Conference on Mobile Systems, Applications, and Services (MobiSys). [3] Nir Aharon, Roy Orfaig, and Ben-Zion Bobrovsky. 2022. BoTSORT: Robust Associations Multi-Pedestrian Tracking. arXiv preprint arXiv:2206.14651 (2022). [4] Apple. 2021. App Tracking Transparency (ATT). https://developer. apple.com/documentation/apptrackingtransparency [5] Apple. 2021. iCloud Private Relay Overview. https://www.apple.com/ icloud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf. [6] Apple. 2023. Apple announces powerful new privacy and security features. https://www.apple.com/newsroom/2023/06/apple-announcespowerful-new-privacy-and-security-features/. [7] Ashwin Ashok, Viet Nguyen, Marco Gruteser, Narayan Mandayam, Wenjia Yuan, and Kristin Dana. 2014. Do Not Share! Invisible Light Beacons for Signaling Preferences to Privacy-Respecting Cameras. In Proc. 1st ACM MobiCom Workshop on Visible Light Communication Systems (VLCS). 39–44. doi:10.1145/2643164.2643168 [8] Pete Beckman, Rajesh Sankaran, Charlie Catlett, Nicola Ferrier, Robert Jacob, and Michael Papka. 2016. Waggle: An Open Sensor Platform for Edge Computing. In Proc. IEEE SENSORS. doi:10.1109/ICSENS.2016. 7808975 [9] Skye Berghel, Philip Bohannon, Damien Desfontaines, Charles Estes, Sam Haney, Luke Hartman, Michael Hay, Ashwin Machanavajjhala, Tom Magerlein, Gerome Miklau, Amritha Pai, William Sexton, and Ruchit Shrestha. 2022. Tumult Analytics: A Robust, Easyto-Use, Scalable, and Expressive Framework for Differential Privacy. arXiv:2212.04133 [cs] [10] Keni Bernardin and Rainer Stiefelhagen. 2008. Evaluating Multiple Object Tracking Performance: The CLEAR MOT Metrics. EURASIP Journal on Image and Video Processing 2008 (2008), 1–10. doi:10.1155/ 2008/246309 [11] Cheng Bo, Guobin Shen, Jie Liu, Xiang-Yang Li, YongGuang Zhang, and Feng Zhao. 2014. Privacy.Tag: Privacy Concern Expressed and Respected. In Proc. 12th ACM Conference on Embedded Network Sensor Systems (SenSys). 163–176. doi:10.1145/2668332.2668339 [12] Jeffrey A. Burke, Deborah Estrin, Mark Hansen, Andrew Parker, Nithya Ramanathan, Sasank Reddy, and Mani B. Srivastava. 2006. Participatory Sensing. In Workshop on World-Sensor-Web (WSW) at ACM SenSys. [13] Frank Cangialosi, Neil Agarwal, Venkat Arun, Junchen Jiang, Srinivas Narayana, Anand Sarwate, and Ravi Netravali. 2022. Privid: Practical, Privacy-Preserving Video Analytics Queries. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). 209–228. [14] Charlie Catlett, Pete Beckman, Rajesh Sankaran, and Kathleen K. Galvin. 2017. Array of Things: A Scientific Research Instrument in the Public Way. In Proc. International Workshop on Science of Smart City Operations and Platforms Engineering (SCOPE). doi:10.1145/3063386. 3063771 [15] Giorgio Cavicchioli, Mark Chen, and Pierre Tholoniat. 2025. Private Data Service Library. https://github.com/columbia/pdslib/ [16] Uğur Çetintemel, Daniel Abadi, Yanif Ahmad, Hari Balakrishnan, Magdalena Balazinska, Mitch Cherniack, Jeong-Hyon Hwang, Samuel Madden, Anurag Maskey, Alexander Rasin, et al. 2016. The Aurora and Borealis Stream Processing Engines. In Data Stream Management. Springer, 337–361. 14

1032. doi:10.14778/1920841.1920970 [34] Bret Hull, Vladimir Bychkovsky, Yang Zhang, Kevin Chen, Michel Goraczko, Allen Miu, Eugene Shih, Hari Balakrishnan, and Samuel Madden. 2006. CarTel: A Distributed Mobile Sensor Computing System. In Proc. ACM Conference on Embedded Networked Sensor Systems (SenSys). 125–138. doi:10.1145/1182807.1182821 [35] India Urban Data Exchange. 2020. IUDX Platform Architecture. Technical Report. Indian Institute of Science and Ministry of Housing and Urban Affairs. https://iudx.org.in/ [36] Michaela Iorga, Larry Feldman, Robert Barton, Michael J. Martin, Nedim Goren, and Charif Mahmoudi. 2018. Fog Computing Conceptual Model. Technical Report SP 500-325. National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.500-325.pdf [37] Morten Bornø Jensen, Andreas Møgelmose, and Thomas B. Moeslund. 2020. Presenting the Multi-view Traffic Intersection Dataset (MTID): A Detailed Traffic Dataset at a Four-Way Signalized Intersection. In IEEE 23rd International Conference on Intelligent Transportation Systems (ITSC). 1–6. doi:10.1109/ITSC45102.2020.9294582 [38] Seungmyeong Jeong, Seongyun Kim, and Jaeho Kim. 2020. City Data Hub: Implementation of Standard-Based Smart City Data Platform for Interoperability. Sensors 20, 23 (2020), 7000. doi:10.3390/s20237000 [39] Ryan Johnston. 2020. Digital privacy concerns will follow Sidewalk Labs to next venture, says former consultant. StateScoop (2020). https://statescoop.com/ann-cavoukian-waterfront-torontodigital-privacy-concerns-sidewalk-labs/ [40] Ava Kofman. 2018. Are New York’s Free LinkNYC Internet Kiosks Tracking Your Movements? The Intercept. https://theintercept.com/ 2018/09/08/linknyc-free-wifi-kiosks/ [41] Bastian Könings, Sebastian Thoma, Florian Schaub, and Michael Weber. 2014. PriPref Broadcaster: Enabling Users to Broadcast Privacy Preferences in Their Physical Proximity. In Proc. 13th International Conference on Mobile and Ubiquitous Multimedia (MUM). 133–142. doi:10.1145/2677972.2677978 [42] Harold W Kuhn. 1955. The Hungarian method for the assignment problem. Naval research logistics quarterly 2, 1-2 (1955), 83–97. doi:10. 1002/nav.3800020109 [43] Hansi Liu, Abrar Alali, Mohamed Ibrahim, Bryan Bo Cao, Nicholas Meegan, Hongyu Li, Marco Gruteser, Shubham Jain, Kristin Dana, Ashwin Ashok, Bin Cheng, and Hongsheng Lu. 2022. Vi-Fi: Associating Moving Subjects across Vision and Wireless Sensors. In 2022 21st ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN). 208–219. doi:10.1109/IPSN54338.2022.00024 [44] Leixian Liu. 2019. A Passenger Flow Data Set Collected in the Metro System of Hangzhou, China. doi:10.5281/zenodo.3145404 [45] Pablo Alvarez Lopez, Michael Behrisch, Laura Bieker-Walz, Jakob Erdmann, Yun-Pang Flötteröd, Robert Hilbrich, Leonhard Lücken, Johannes Rummel, Peter Wagner, and Evamarie Wießner. 2018. Microscopic Traffic Simulation using SUMO. In Proc. IEEE International Conference on Intelligent Transportation Systems (ITSC). 2575–2582. doi:10.1109/ITSC.2018.8569938 [46] Robert MacDavid, Carmelo Cascone, Pingping Lin, Badhrinath Padmanabhan, Ajay Thakur, Larry Peterson, Jennifer Rexford, and Oguz Sunay. 2021. A P4-based 5G User Plane Function. In Proc. ACM SOSR. 162–168. doi:10.1145/3482898.3483358 [47] Simon McCormack and Daniel Schwarz. 2023. LinkNYC is a Privacy Disaster. Here’s Why. New York Civil Liberties Union (NYCLU) Commentary. https://www.nyclu.org/commentary/linknyc-privacydisaster-heres-why Accessed February 2026. [48] Nathaniel Meyersohn. 2026. Wegmans is Scanning Your Face at Some Stores. It’s Not the Only Company. CNN Business (2026). https://www.cnn.com/2026/01/12/business/wegmans-facialrecognition-technology [49] Anton Milan, Laura Leal-Taixé, Ian Reid, Stefan Roth, and Konrad

Schindler. 2016. MOT16: A Benchmark for Multi-Object Tracking. arXiv preprint arXiv:1603.00831 (2016). [50] Mitchell L. Moss and Carson Qing. 2012. The Dynamic Population of Manhattan. Technical Report. Rudin Center for Transportation Policy and Management, NYU Wagner School of Public Service. https://wagner.nyu.edu/impact/research/publications/dynamicpopulation-manhattan [51] Mozilla. 2022. Over a decade of anti-tracking work at Mozilla. https://blog.mozilla.org/en/privacy-security/mozilla-anti-trackingmilestones-timeline/. [52] Rohan Murty, Geoffrey Mainland, Ian Rose, Atanu Roy Chowdhury, Abhimanyu Gosain, Josh Bers, and Matt Welsh. 2008. CitySense: An Urban-Scale Wireless Sensor Network and Testbed. In Proc. IEEE International Conference on Technologies for Homeland Security. 583– 588. doi:10.1109/THS.2008.4534518 [53] Charlie Mydlarz, Mohit Sharma, Yitzchak Lockerman, Ben Steers, Claudio Silva, and Juan Pablo Bello. 2019. The Life of a New York City Noise Sensor Network. Sensors 19, 6 (2019), 1415. doi:10.3390/s19061415 [54] National Institute of Standards and Technology. 2020. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. Technical Report. National Institute of Standards and Technology. https://www.nist.gov/privacy-framework [55] New York City Council. 2021. Biometric Identifier Information Law. https://codelibrary.amlegal.com/codes/newyorkcity/latest/ NYCadmin/0-0-0-131285 [56] NYC Department of Transportation. 2023. Bicycle Counts. NYC Open Data. https://data.cityofnewyork.us/Transportation/BicycleCounts/uczf-rk3c Williamsburg Bridge Bike Path, 15-minute EcoCounter data. [57] NYC Department of Transportation. 2024. Cycling in the City: Bicycling in New York City. Technical Report. https://www.nyc.gov/html/dot/ html/bicyclists/bikestats.shtml [58] NYC Department of Transportation. 2024. New York City Bridge Traffic Volumes. Technical Report. https://data.cityofnewyork.us/ Transportation/Traffic-Volume-Counts/btm5-ppia [59] oneM2M. 2020. Functional Architecture (TS-0001). Technical Report. oneM2M Partners Type 1. https://www.onem2m.org/technical/ published-specifications [60] Open Geospatial Consortium. 2016. SensorThings API Part 1: Sensing. https://www.ogc.org/standards/sensorthings [61] Organisation for Economic Co-operation and Development. 1980. OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. Technical Report. OECD, Paris. https:// legalinstruments.oecd.org/public/doc/114/114.en.pdf Adopted 23 September 1980; revised 2013. [62] Sharnil Pandya, Gautam Srivastava, Rutvij Jhaveri, M. Rajasekhara Babu, et al. 2023. Federated Learning for Smart Cities: A Comprehensive Survey. Sustainable Energy Technologies and Assessments 55 (2023), 102987. doi:10.1016/j.seta.2022.102987 [63] Larry Peterson, Oguz Sunay, and Bruce Davie. 2023. Private 5G: A Systems Approach. Systems Approach LLC. https://5g.systemsapproach. org/cloud.html Chapter 6: Managed Cloud Service. [64] Krishna Pillutla, Jalaj Upadhyay, Christopher A. Choquette-Choo, Krishnamurthy Dvijotham, Arun Ganesh, Monika Henzinger, Jonathan Katz, Ryan McKenna, H. Brendan McMahan, Keith Rush, Thomas Steinke, and Abhradeep Thakurta. 2025. Correlated Noise Mechanisms for Differentially Private Learning. arXiv:2506.08201 [cs.LG] doi:10.48550/arXiv.2506.08201 [65] Attila Reiss. 2012. PAMAP2 Physical Activity Monitoring. UCI Machine Learning Repository. doi:10.24432/C5NW2H [66] Daniel Rivas, Francesc Guim, Jordà Polo, Pubudu M. Silva, Josep Ll. Berral, and David Carrera. 2022. Towards Automatic Model Specialization for Edge Video Analytics. Future Generation Computer Systems 134 (2022), 399–413. doi:10.1016/j.future.2022.03.039 15

[67] Ignacio Rodriguez, Huan Cong Nguyen, Niels T. K. Jørgensen, Troels B. Sørensen, Jan Elling, Matthias B. Gentsch, and Preben Mogensen. 2013. Path Loss Validation for Urban Micro Cell Scenarios at 3.5 GHz Compared to 1.9 GHz. In Proc. IEEE GLOBECOM. 3942–3947. doi:10.1109/ GLOCOM.2013.6831689 [68] Luis Sánchez, Luis Muñoz, José Antonio Galache, Pablo Sotres, Juan Ramón Santana, Verónica Gutiérrez, Rajiv Ramdhany, Alex Gluhak, Srdjan Krco, Evangelos Theodoridis, and Dennis Pfisterer. 2014. SmartSantander: IoT Experimentation over a Smart City Testbed. Computer Networks 61 (2014), 217–238. doi:10.1016/j.comnet.2013.12. 020 [69] Todd W. Schneider. 2016. A Tale of Twenty-Two Million Citi Bike Rides: Analyzing the NYC Bike Share System. Blog post. https://toddwschneider.com/posts/a-tale-of-twenty-twomillion-citi-bikes-analyzing-the-nyc-bike-share-system/ [70] Daniel J. Solove. 2013. Privacy Self-Management and the Consent Dilemma. Harvard Law Review 126, 7 (2013), 1880–1903. [71] State of California. 2020. California Consumer Privacy Act (CCPA). https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ oal-sub-final-text-of-regs.pdf [72] State of Connecticut. 2022. Connecticut Data Privacy Act (CTDPA). https://portal.ct.gov/ag/sections/privacy/the-connecticut-dataprivacy-act [73] State of New Jersey. 2024. New Jersey Data Protection Act (NJDPA). https://www.cyber.nj.gov/guidance-and-best-practices/ identity-theft-privacy/data-privacy/nj-data-privacy-prevention-act [74] Greg Sterling. 2017. Mobile-location data turns out-of-home billboards into ‘digital channel’. https://martech.org/mobile-location-data-turnhome-billboards-digital-channel/. [75] Pierre Tholoniat, Kelly Kostopoulou, Peter McNeely, Prabhpreet Singh Sodhi, Anirudh Varanasi, Benjamin Case, Asaf Cidon, Roxana Geambasu, and Mathias Lécuyer. 2024. Cookie Monster: Efficient On-device Budgeting for Differentially-Private Ad-Measurement Systems. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (SOSP ’24). Association for Computing Machinery, New York, NY, USA, 693–708. doi:10.1145/3694715.3695965 [76] Ultralytics. 2026. YOLO26. https://github.com/ultralytics/ultralytics. YOLO26n variant. [77] W3C Privacy Working Group. 2024. Global Privacy Control (GPC). W3C Working Draft. https://www.w3.org/TR/gpc/ [78] W3C Private Advertising Technology Working Group. 2024. Attribution Level 1. W3C Working Draft. https://www.w3.org/TR/attribution/ [79] Pawan Wawage and Yogesh Deshpande. 2022. Smartphone Sensor Dataset for Driver Behavior Analysis. Data in Brief 41 (2022), 107992. doi:10.1016/j.dib.2022.107992 [80] Bing Zhang, Vadym Doroshenko, Peter Kairouz, Thomas Steinke, Abhradeep Thakurta, Ziyin Ma, Eidan Cohen, Himani Apte, and Jodi Spacek. 2024. Differentially Private Stream Processing at Scale. Proceedings of the VLDB Endowment 17, 12 (2024), 4145–4158. doi:10. 14778/3685800.3685833

API 1: On-Scene – Security Analysis

in one hour under the largest maxEC tested (10 min), and as little as 0.11% under short contexts (30 s). The attacker obtains only fragmentary, temporally bounded observations from visited locations, not a continuous city-wide view. Static attackers capture data only at a single location, with exposure determined by local traffic rather than system-wide scale (§6.1). Localized release confines this risk spatially: compromise does not propagate across nodes. Large-scale attackers (e.g., widely deployed mobile apps) could collect outputs across many locations. While this case is outside our core threat model, CityOS mitigates it through (i) anonymized inputs by default (bounding boxes rather than raw imagery), reducing the information content of outputs; and (ii) reliance on policy and regulation to prohibit systematic collection and resale of localized signals, analogous to web defenses against third-party tracking. Targeted exfiltration. Applications may attempt to encode information in seemingly benign outputs, such as watermarking signals, tied to specific targeted individuals. Such attacks are difficult to detect purely technically. CityOS limits their impact through ephemerality (bounded temporal scope) and localization (bounded spatial scope), ensuring that successful attacks require either a large-scale sniffer or physically trailing the individual. Visual feedback loops. A potential attack against CityOS’s cross-ephemeral-context independence is a visual feedback loop between a malicious application at the node and a colluding device in the environment. In this attack, when the application detects a target individual, it emits a signal via API 1 outputs; a nearby device senses this signal and responds with a visual (or otherwise observable) pattern that is fed back into the node’s sensors. By iterating this loop, the application can effectively externalize state and carry it across ephemeral contexts. Such behavior is feasible and should be explicitly disallowed at the policy level. Its impact depends on the attacker’s objective. If the goal is information exfiltration, the attacker gains no additional power beyond a sniffing attack: any information encoded in the feedback loop could equivalently be captured directly from API 1 outputs by the nearby colluding device (§4.1). Thus, ephemerality and localization continue to bound the attacker’s effective visibility. If the goal is to violate API 2 sensitivity assumptions, the attack is more subtle. By persisting signals across tracking contexts (𝑇𝐶’s), a feedback loop can induce dependencies that break the assumption that events within each 𝑇𝐶 are independent. This can invalidate sensitivity bounds in the untrusted mode of operation (e.g., Privid-style bounding), which assumes computation over short aggregation intervals are isolated from each other. In contrast, the trusted mode of operation, which derives sensitivity from the trusted Object Detection and Tracking pipeline, is not affected by such cross-context manipulation.

API 1 exposes the richest access to raw sensing data and therefore carries the highest immediate risk if not carefully constrained. We summarize its protections and residual risks under our threat model (§3.2). This is a security analysis, not a privacy one, as API 1 provides no formal privacy guarantees. Node compromise. If an adversary compromises a CityOS node, the exposed data is fundamentally limited by API 1’s ephemerality guarantees. At any time, the node retains at most maxECsys worth of raw input frames and derived state. As a result, temporary compromise yields only a short, temporally bounded snapshot of activity at that location, rather than a persistent or historical record. This sharply contrasts with centralized architectures, where compromise exposes long-term stored data across many locations. Long-term compromise (such as with advanced persistent threats) is outside the scope of all CityOS defenses. Application-level exfiltration. Untrusted applications may attempt to exfiltrate information through API 1 outputs. CityOS constrains this channel in two ways. First, applications execute inside ephemeral containers with no network access or persistent storage, preventing direct backend transmission. Second, outputs are restricted to localized release, a bounded-range broadcast channel that does not forward data to remote infrastructure. This design prevents straightforward backend collection but leaves open the possibility of indirect exfiltration via nearby devices. Localized release via private 5G. Localized release can be implemented with a private 5G small cell co-located with each CityOS node [63]. Recent spectrum-sharing regulations allow organizations to deploy private cellular networks without acquiring traditional licensed spectrum. A small cell mounted on a streetlight covers roughly 100–300 m in urban settings [67], so radio propagation itself bounds dissemination to the node’s immediate vicinity without applicationlevel geo-fencing. The 5G architecture further supports deploying the network’s data-forwarding function at each site [1, 46, 63], so that application traffic is served entirely on the node and never traverses a wide-area backhaul link, so outputs remain local by construction. For mobile receivers, cellular handover completes in tens of milliseconds [31], giving even a vehicle at city speeds ample dwell time within a single cell. The coverage boundary is a practical, not cryptographic, spatial bound; we rely on ephemerality (maxEC) rather than on radio propagation alone for privacy (§4.1). Sniffing attacks. A nearby device can collect API 1 outputs and forward them to a backend (a sniffing attack, §4.1). The effectiveness of such attacks depends on their scale. Small-scale attackers (few devices) are strongly limited by ephemerality and locality. As shown in §6.1, even a car-speed attacker captures at most 2.22% of city-wide person-activity 17

That is, ∀𝑢, ∀ TC 𝑒 during which 𝑢 is present, ∀𝐷 ∼user 𝐷 ′ , ∀ measurable 𝑆 ⊆ O:

Summary. API 1 does not eliminate all data exposure, but fundamentally changes its nature: from persistent, centralized collection to short-lived, localized observation. Under our threat model, compromise yields only fragmentary views of activity, and reconstructing large-scale behavior requires sustained physical presence or large-scale deployment. This provides a stronger foundation for building an application ecosystem than the conventional centralize-and-retain approach, enabling on-scene applications while avoiding the accumulation patterns that give rise to tracking-based systems.

Pr[M (𝐷) ∈ 𝑆] ≤ 𝑒 𝜌 node Pr[M (𝐷 ′ ) ∈ 𝑆].

(2)

Theorem B.2 ((User, maxECsys )-level composition on the device). Fix a user 𝑢 and one maxECsys window at locality ℓ. Let 𝑒 1, . . . , 𝑒𝐺 (𝐺 ≤ maxECsys /𝜏TC ) be the TCs during which 𝑢 (𝑔) is present, and let 𝜌 node denote the per-TC filter capacity during 𝑒𝑔 (Thm. B.1). The total privacy loss incurred by 𝑢 is at most Í𝐺 (𝑔) 𝑔=1 𝜌 node . Note that to get releases from different maxECsys , states will be completely reset independently and the composition happens post-facto, meaning we can just compose them through basic composition here.

API 2: Single-Locality Aggregation Privacy and Utility Analyses

This section formalizes the API 2 privacy and utility statements from §4.2. We analyze two modes of operation: trusted event generation, in which events are produced by the Object Detection and Tracking service (the default), and untrusted event generation, in which applications supply their own events. While CityOS supports both, the trusted mode is the default due to the untrusted mode’s inflated sensitivity on count queries, which are expected to be common in API 2 (see §4.2). Both modes share the same data model and Laplace release mechanism, but differ in their neighboring relations, how per-context outputs are modeled, and in the precision of per-user accounting. After formalizing the shared data model and standard DP tools (§B.2), we present per-AW privacy analyses for the two modes (§B.3, §B.4). We then formalize the binary tree mechanism and shadow bridging release (§B.5), prove the node-side privacy guarantees that compose across the tree (§B.6), and analyze the utility of the DP continual-release mechanism under state reset (§B.7). The utility analysis applies regardless of mode of operation (trusted vs. untrusted), although in practice the bounds differ because sensitivity differs between the two modes.

Theorem B.3 (Utility of interval-sum queries). Let 𝜎 2 = 2Δ2 /𝜀 2 be the per-node noise variance and 𝑉 (𝑁 ) = 2(log2 𝑁 − 1) for 𝑁 ≥ 4. 1. For short intervals where |𝐼 | ≤ 𝑁 /2, the interval sum can be recovered from released tree-node values with noise variance at most 𝑉 (𝑁 ) · 𝜎 2 . 2. For long intervals where |𝐼 | > 𝑁 /2, writing |𝐼 | = 𝑘𝑁 /2+ 𝑅 with 𝑘 ≥ 1 and 0 ≤ 𝑅 < 𝑁 /2, the interval sum can be recovered from released values across containers with variance at most (𝑘 + 𝑉 (𝑁 )) · 𝜎 2 . B.2 Data Model API 2 organizes time at each locality into three granularities: tracking contexts (TCs), aggregation windows (AWs), and maxECsys containers. TCs are the smallest unit of time, within which the tracker assigns stable IDs. AWs group one or more TCs and are the unit at which the system produces aggregate outputs. The DP Continual Release service operates over a binary tree whose leaves are AWs, inside an overlapping maxECsys container. Definition B.4 (Localities and time). Let L denote a set of localities. Let T be a totally ordered time domain.

B.1 Main Results We state the main privacy and utility guarantees upfront. We scope the results to a single locality (node), ℓ. Let {𝑄 1, . . . , 𝑄 𝐾 } be the registered queries at ℓ. Each query 𝑄𝑞 has aggregation window AW𝑄𝑞 , tree size 𝑁𝑞 = maxECsys /AW𝑄𝑞 , per-query sensitivity Δ𝑞 , noise parameter 𝜎𝑄𝑞 , and per-tree-node pri√ vacy parameter 𝜀𝑞 = Δ𝑞 2/𝜎𝑄𝑞 . The per-query notation (𝑁 , 𝜀, Δ, 𝜎 2 , the binary tree B𝑁 , the shadow bridging release, 𝑉 (𝑁 ), and the neighboring relation ∼𝑢user ) is formalized in §B.5. Proofs appear in §B.6 and §B.7.

Definition B.5 (Tracking contexts (TC)). Fix a constant 𝜏TC > 0 (the tracking-context duration). For each locality ℓ ∈ L, let Eℓ denote a set of half-open time intervals 𝑒 = [𝑡 start (𝑒), 𝑡 end (𝑒)) ⊆ T , each of duration 𝜏TC , such that: 1. the intervals in Eℓ are pairwise disjoint, and 2. Eℓ is totally ordered by start time. Ð Let E := ℓ ∈ L Eℓ . For 𝑒 ∈ E, write loc(𝑒) ∈ L for its associated locality.

Theorem B.1 ((User, TC)-level DP on the node). Consider a locality ℓ with registered queries {𝑄 1, . . . , 𝑄 𝐾 }. Let M denote the joint release mechanism across all 𝐾 queries. Then M satisfies (𝜌 node, 0)-DP at the (user, TC) level, where 𝐾 ∑︁ 𝜌 node := log2 𝑁𝑞 + 2 𝜀𝑞 . (1)

The "Object Detection and Tracking" service at locality ℓ runs inside a tumbling ephemeral container (minEC = 0, maxEC = TC) that partitions time into consecutive, nonoverlapping tracking contexts tc1, tc2, . . .. Within each TC, the tracker assigns stable pseudonymous IDs to detected individuals. At TC boundaries, all IDs are reset and no tracking state persists.

𝑞=1 18

Definition B.6 (Aggregation windows (AW)). An aggregation window AW𝑄 is a contiguous block of one or more consecutive TCs (AW𝑄 is a multiple of TC). The query API specifies AW𝑄 as a per-query parameter, subject to the constraint that 𝑁 := maxECsys /AW𝑄 is a power of 2 (determining the binary tree height ℎ = log2 𝑁 ), and that the finest aggregation window equals a single TC.

log2 𝑁 + 2 releases total. The following parameters are treated as public: the locality set L, the TC schedules {Eℓ }, maxECsys , and the perreport sensitivity bounds {𝑆𝑟 } (or query templates {𝑄𝑟 } in the trusted class). All of these are deployment-time commitments made before any data is collected. Treating mechanism structure as public is standard in DP [19].

Each AW produces one aggregate output that is fed into the continual-release mechanism. The database records are mutually independent across AWs, since each AW’s output depends only on the sensing data within that AW. The privacy analysis relies on the following assumptions. • Tracking fidelity. Within each TC, the tracker assigns each individual a single consistent ID, possibly with a bounded error factor 𝜌 track ≥ 1 on the number of IDs per user (which scales the sensitivity). In practice, 𝜌 track is derived from empirical error rates of the tracker (e.g., BoT-SoRT via YOLO). • Broadcast reception. If a user is within the sensing range of a node (i.e., the user’s data may contribute to releases), the user’s device receives the node’s privacyloss broadcast. This ensures the device can account for all costs incurred on its behalf. • Container ephemerality. When a maxECsys container is destroyed, all non-DP state (raw data, partial sums, shadow running sums) is irrecoverably deleted. This ensures that releases from distinct maxECsys windows are computed on independent state, which is required for composition across windows (Thm. B.2). • Fixed query workload within each TC. The set of registered queries, their sensitivities, and their aggregation window parameters are fixed within each TC. This ensures the broadcast cost 𝜌 node (Eq. 1) correctly accounts for all current and future releases involving data from that TC.

Definition B.8 (Per-context scalar output). Let Y := R ≥0 denote the set of per-context outputs. Each aggregation window 𝑒 produces a single non-negative scalar 𝑦𝑒 ∈ Y. Let 0 := 0 ∈ Y. For untrusted applications, 𝑦𝑒 is an opaque scalar emitted by arbitrary application code, capped at its declared sensitivity. For trusted applications, 𝑦𝑒 is the output of a fixed bounded query over trusted structured detections (see §B.3). Definition B.9 (Database). A database 𝐷 is a set of localitycontext records 𝑥 = (ℓ, 𝑒, 𝑦) ∈ X := L × E × Y such that ℓ = loc(𝑒), and if (ℓ, 𝑒, 𝑦) ∈ 𝐷 and (ℓ, 𝑒, 𝑦 ′ ) ∈ 𝐷 then 𝑦 = 𝑦 ′ . Let D denote the set of all such databases. For ℓ ∈ L and 𝑒 ∈ Eℓ , define 𝐷 ℓ𝑒 ∈ Y∪{⊥} as the unique 𝑦 with (ℓ, 𝑒, 𝑦) ∈ 𝐷 if it exists, and ⊥ otherwise. B.2.1 Standard DP tools. The following definitions and lemmas are standard and are used by both the trusted and untrusted privacy analyses below. Definition B.10 ((𝜖, 𝛿)-DP). A randomized mechanism M : D → O is (𝜖, 𝛿)-differentially private with respect to ∼ if for all 𝐷 ∼ 𝐷 ′ and measurable 𝑆 ⊆ O: Pr[M (𝐷) ∈ 𝑆] ≤ 𝑒 𝜖 Pr[M (𝐷 ′ ) ∈ 𝑆] + 𝛿.

(3)

Lemma B.11 (Basic composition for long-term releases). If M𝑡 is (𝜖𝑡 , 𝛿𝑡 )-DP for each 𝑡Í∈ [𝑇 Í ], then the joint mechanism (M1 (𝐷), . . . , M𝑇 (𝐷)) is ( 𝑡 𝜖𝑡 , 𝑡 𝛿𝑡 )-DP. Lemma B.12 (Group privacy). If M is (𝜀, 𝛿)-DP with respect to a neighboring relation ∼, and 𝐷, 𝐷 ′ can be connected by a chain of at most 𝑔 steps under ∼ (i.e., there exist 𝐷 = 𝐷 0 ∼ 𝐷 1 ∼ · · · ∼ 𝐷𝑔 = 𝐷 ′ ), then Pr[M (𝐷) ∈ 𝑆] ≤ 𝑒 𝑔𝜀 Pr[M (𝐷 ′ ) ∈ Í𝑔−1 𝑆] + 𝛿𝑔 , where 𝛿𝑔 = 𝑗=0 𝑒 𝑗𝜀 𝛿. In particular, if 𝛿 = 0 then M satisfies (𝑔𝜀, 0)-DP between 𝐷 and 𝐷 ′ .

Definition B.7 (maxECsys container and shadow). Fix a positive integer 𝑁 = 2ℎ (ℎ ≥ 1). The DP Continual Release service at locality ℓ runs inside an overlapping ephemeral container with maxEC = maxECsys := 𝑁 ·AW𝑄 and minEC = maxECsys /2. Primary containers 𝑎 1(0) , 𝑎 2(0) , . . . tile time into consecutive blocks of 𝑁 AWs. A shadow container is initialized maxECsys /2 before each primary-container reset. Each primary container runs a binary tree mechanism with 𝑁 leaves (§B.5). The shadow container adds one bridging release at each primary-container boundary.

B.3 Privacy Analysis for Trusted Mode In the trusted class, a pre-installed trusted object detector processes raw sensor data and emits a structured detection record for each context before any application code runs. Applications are restricted to fixed, bounded query templates (e.g. counts and sums) over those detections. In the future, there may be opportunities to enrich the queries that can be supported via prior works on Privacy-Preserving SQL queries such as those studied in [13, 30, 80]. Sensitivity is derived from the query type, so noise is calibrated to the actual per-user contribution rather than a worst-case declared bound.

The overlapping structure ensures smooth container rotation with minEC = maxECsys /2. The shadow bridging release provides the noisy sum of the second half of each primary container (𝑁 /2 AWs), connecting adjacent containers for interval-sum recovery. Each AW participates in at most log2 𝑁 + 1 tree-node releases (one per level of the primary tree) plus at most 1 shadow bridging release, for at most 19

For example, 𝜇𝑄 = 1 for last-frame COUNT queries, 𝜇𝑄 = 𝑣 max for last-frame SUM queries, and 𝜇𝑄 scales with frame count for cumulative aggregations (e.g., 𝜇𝑄 = 𝑘 for a 𝑘frame cumulative count). The value of 𝜇𝑄 is declared at query registration.

Each trusted release corresponds to exactly one AW and there is no multi-context accumulation. The trusted class can release at this fine granularity because the per-user sensitivity 𝜇𝑄 is typically small (e.g., 𝜇𝑄 = 1 for count queries). The detector assigns a pseudonymous ID id𝑢 to each detected user within each TC (Def. B.5), so each user’s contribution within a TC is bounded. Each user in the detection record D𝑒 (defined formally in Def. B.14 below) carries an attribute value 𝑣 ∈ [0, 𝑣 max ]. Removing or adding one user changes a COUNT query by 1 and a SUM query by at most 𝑣 max , giving per-user sensitivity 𝜇𝑄 . B.3.1 Trusted data model and sensitivity. Note that for both trusted and untrusted classes, context isolation holds based on API 1. That is, application code has no persistent state across TCs. This system property was justified separately by the design of API 1, so we only discuss the aggregation granularity here.

Neighboring relations. The trusted class uses two neighboring relations that serve different roles. 𝐷 ∼id 𝐷 ′ holds iff D𝑒 and D𝑒′ differ by exactly one tracked ID for some AW 𝑒, with all other per-context records unchanged. Noise is calibrated to this ID-level relation, giving per-ID sensitivity 𝜇𝑄𝑟 under ∼id (formalized in Def. B.16). 𝐷 ∼user 𝐷 ′ holds iff 𝐷 ′ is obtained from 𝐷 by removing all IDs attributed to one user 𝑢 within a single AW. This is the semantically meaningful guarantee on the node. Under the "tracking fidelity" assumption with 𝜌 track = 1, a user receives exactly one ID per TC. If AW 𝑒 spans 𝑘𝑒 TCs, user 𝑢 has at most 𝑘𝑒 distinct IDs within 𝑒 (one per TC). Removing 𝑢 from 𝑒 under ∼user amounts to removing 𝑘𝑒 IDs under ∼id . When AW𝑄 = TC (the finest granularity), 𝑘𝑒 = 1 and the two neighboring relations coincide. This section presents an idealized version of the trustedclass analysis. The evaluation in the main text examines the effect of tracking errors empirically (e.g., when multiple IDs are assigned to a single continuous presence of a user within an AW).

Definition B.13 (User). A user is a detected presence identified by a pseudonymous ID id𝑢 assigned by the trusted object detector within a single TC (Def. B.5). IDs are reset at TC boundaries. D𝑒 = (𝐹 1, 𝐹 2, . . . , 𝐹𝑚 ) is the ordered sequence of frame detection sets produced during AW 𝑒 = [𝑡 start (𝑒), 𝑡 end (𝑒)), where each 𝐹𝑖 contains the entities detected at that instant. A user who spans two TCs receives distinct IDs in each and is treated as two separate presences for privacy purposes. Under the "tracking fidelity" assumption, a user has exactly one ID per TC, so within an AW spanning 𝑘𝑒 TCs, a user has at most 𝑘𝑒 IDs.

Definition B.16 (Trusted API 2 report (𝑘𝑟 = 1)). A trusted report 𝑟 is associated with a locality ℓ𝑟 , a single AW 𝑒𝑟 (so 𝑘𝑟 = 1), and a trusted query template 𝑄𝑟 . The trusted report function is 𝜌𝑟tr (𝐷) := 𝑄𝑟 (D𝑒𝑟 ). Under ∼id , Δ(𝜌𝑟tr ) = 𝜇𝑄𝑟 by Def. B.15.

Definition B.14 (Trusted detection record and query template). A detection record for AW 𝑒 is the frame detection sequence D𝑒 = (𝐹 1, 𝐹 2, . . . , 𝐹𝑚 ) from Def. B.13, where each 𝐹𝑖 = {(id, 𝜏, 𝑣)} records the pseudonymous IDs, object types 𝜏, and scalar attributes 𝑣 ∈ [0, 𝑣 max ] (𝑣 max > 0 declared per attribute) of entities detected at sensor frame 𝑖. A trusted query template 𝑄𝑟 is an aggregation function over D𝑒 . The choice of frame subset and aggregation method determines the per-ID sensitivity 𝜇𝑄 (Def. B.15).

Theorem B.17 (DP via Laplace noise (trusted)). The mechanism 𝑀 tr (𝐷) := 𝜌𝑟tr (𝐷) + 𝜂,

(5)

is (𝜀, 0)-DP under ∼id . Under ∼user , if AW 𝑒 spans 𝑘𝑒 TCs, a user 𝑢 present in all 𝑘𝑒 TCs incurs privacy cost at most 𝑘𝑒 𝜀 for the single-AW release. Proof. Δ(𝜌𝑟tr ) = 𝜇𝑄𝑟 under ∼id by Def. B.15. The Laplace mechanism with scale 𝜇𝑄𝑟 /𝜀 gives (𝜀, 0)-DP under ∼id . For ∼user : let AW 𝑒 span 𝑘𝑒 TCs. By tracking fidelity, 𝑢 has at most 𝑘𝑒 IDs in 𝑒 (one per TC). Removing 𝑢 from 𝑒 under ∼user is a 𝑘𝑒 -step chain under ∼id :

Representative query templates include COUNT(𝜏) (number of type-𝜏 entities in a designated frame subset) and SUM(𝜏, 𝑣) (sum of attribute 𝑣 over type-𝜏 entities). Averages are represented as SUM/COUNT and treated as a scaled sum for DP purposes.

𝐷 = 𝐷 0 ∼id 𝐷 1 ∼id · · · ∼id 𝐷𝑘𝑒 = 𝐷 ′ .

Definition B.15 (Trusted query sensitivity). The per-ID sensitivity 𝜇𝑄 of a trusted query template 𝑄𝑟 is the maximum change in the query output from adding or removing all occurrences of a single tracked ID across the frame sequence: 𝜇𝑄 := max 𝑄𝑟 (D𝑒 ) − 𝑄𝑟 (D𝑒id→∅ ) , D𝑒 ,id

𝜂 ∼ Lap(𝜇𝑄𝑟 /𝜀),

(6)

By Lem. B.12 with 𝑔 = 𝑘𝑒 and 𝛿 = 0, the cost is 𝑘𝑒 𝜀. When AW𝑄 = TC, 𝑘𝑒 = 1. □ In the trusted class, the detector identifies which users contributed to each AW’s output, so privacy loss can be attributed per user. In the untrusted class, all users present in the AW must be charged pessimistically since the application output may depend on any of them. The total per-user

(4)

where D𝑒id→∅ is D𝑒 with all entries for id removed from every frame. 20

privacy cost across the binary tree is analyzed in Thm. B.1 and Thm. B.2. B.3.2 Accounting protocol and algorithms. The node continuously broadcasts the current TC identifier and the per-TC privacy cost 𝜌 node (Eq. 1), which accounts for all registered queries. Note that the broadcast is not per-ID, since every device in range receives the same (ℓ, 𝑒, 𝜌 node ) tuple and accounts for the same loss (again, the first two elements merely identify the TC, and the third one is for privacy accounting). Per this design, the node doesn’t need to know which device corresponds to which tracked ID.

Alg. 1 Release and accounting at locality ℓ (trusted, binary tree)

Definition B.18 (Privacy broadcast). Throughout each TC 𝑒, the CityOS node at locality ℓ continuously broadcasts (ℓ, 𝑒, 𝜌 node ). Every device in range receives the same broadcast. A device that is present at any point during 𝑒 records 𝜌 node once (deduplicating by the TC identifier 𝑒). The cost 𝜌 node pre-charges for all tree-node releases and shadow bridging releases across all queries that will ever involve TC 𝑒’s data.

Tree.AddLeaf(𝑦𝑒 ) // insert 𝑦𝑒 as next leaf of B𝑁 leafIdx ← leafIdx + 1 if leafIdx > 𝑁 /2 then // second half of container ShadowSum ← ShadowSum + 𝑦𝑒 13: for all 𝑣 ∈ Tree whose subtree rooted at 𝑣 just became complete do // release per Eq. 11 14: 𝜂 𝑣 ∼ Lap(𝜇𝑄𝑟 /𝜀) 15: CloudRelease(ℓ, 𝑣, sum(𝑣) + 𝜂 𝑣 ) 16: Broadcast(ℓ, 𝑒, (log2 𝑁 + 2)𝜀) // Def. B.18

1: // CityOS node at locality ℓ 2: 𝜀 > 0 // per-tree-node privacy cost 3: 𝑁 > 0 // AWs per container (Def. B.7) 4: Tree ← NewBinaryTree(𝑁 ) // B𝑁 as in §B.5 5: ShadowSum ← 0 // bridging sum for shadow container 6: leafIdx ← 0 // leaf counter within current container 7: def OnAW(𝑒, 𝑄 𝑟 , 𝜇𝑄𝑟 ) 8: 𝑦𝑒 ← 𝑄 𝑟 (D𝑒 ) // query over detection record (Def. B.14) 9: 10: 11: 12:

Alg. 1 shows the release and accounting procedure for the trusted class. Alg. 2 shows how the trusted detector builds D𝑒 (Def. B.14) and produces DP releases. ProcessFrame runs at sensor rate, maintaining the set of active IDs for query evaluation. AWRelease is called at 𝑡 end (𝑒), evaluating 𝑄𝑟 on the full frame sequence D𝑒 . A user’s device accumulates 𝜀 acc = 𝐺 · 𝜌 where 𝐺 is the number of distinct AWs in which it received the broadcast (the "broadcast reception" assumption ensures reception whenever the user is in sensing range). Every user present during an AW accounts for the same 𝜌, regardless of whether their data actually affected the release. The node-side mechanism does not adapt to individual budgets.

17: def OnContainerEnd // shadow bridging release 18: 𝜂 ∼ Lap(𝜇𝑄𝑟 /𝜀)

CloudRelease(ℓ, shadow, ShadowSum + 𝜂) Teardown(Tree) // destroy all raw state ("container ephemerality") 21: Tree ← NewBinaryTree(𝑁 ) 22: ShadowSum ← 0 23: leafIdx ← 0

19: 20:

24: // User’s device 25: 𝜀 acc ← 0 // accumulated privacy loss 26: def Receive(ℓ, 𝑒, 𝜌) 27: 𝜀 acc ← 𝜀 acc + 𝜌

B.4 Privacy Analysis for Untrusted Mode B.4.1 Query model. In the untrusted mode, the application code that produces events is treated as arbitrary, possibly adversarial. The application receives raw sensing data for each context and emits a single scalar 𝑦𝑒 ∈ [0, 𝑆] at the end of each AW. The system does not inspect intermediate computations or per-user outputs. The application declares a sensitivity bound 𝑆 > 0, which the runtime enforces as a hard cap on each per-context output and uses as the noise scale 𝑆/𝜀 (see Thm. B.23).

anism (§B.5), which accumulates and releases noisy partial sums over contiguous blocks of AWs. The global sensitivity of any single AW’s contribution is 𝑆. B.4.2 Neighboring relation and sensitivity. Definition B.20 (Neighboring databases). We write 𝐷 ∼𝑥 𝐷 ′ , for 𝑥 = (ℓ, 𝑒, 𝑦) ∈ X, iff 𝐷 ′ is obtained from 𝐷 by zeroing out the record (ℓ, 𝑒):

Definition B.19 (Declared sensitivity bound and output cap). An untrusted application declares a sensitivity bound 𝑆 > 0. The per-context output is 𝑦𝑒 := min {Ext𝑒 (Raw𝑒 ), 𝑆 } ,

𝐷 ′ = (𝐷 \ {(ℓ, 𝑒, 𝑦)}) ∪ {(ℓ, 𝑒, 0)}.

(8)

Write 𝐷 ∼ 𝐷 ′ if 𝐷 ∼𝑥 𝐷 ′ for some 𝑥 ∈ X.

(7)

where Ext𝑒 is the application’s extraction function over the raw sensor content Raw𝑒 of context 𝑒. Throughout, 𝑦𝑒 denotes the capped value, so 𝑦𝑒 ∈ [0, 𝑆].

Definition B.21 (Sensitivity). For a report 𝜌 : D → R and 𝑥 ∈ X, define the individual sensitivity Δ𝑥 (𝜌) := max𝐷∼𝑥 𝐷 ′ |𝜌 (𝐷)− 𝜌 (𝐷 ′ )| and the global sensitivity Δ(𝜌) := max𝑥 ∈ X Δ𝑥 (𝜌).

Each AW produces one capped scalar 𝑦𝑒 ∈ [0, 𝑆] (Def. B.19). The per-AW output is fed directly into the binary tree mech-

Lemma B.22 (Global sensitivity of untrusted API 2 reports). Fix an untrusted API 2 report 𝜌𝑟 with declared sensitivity 𝑆𝑟 . 21

Alg. 2 Detection and release by CityOS locality ℓ (trusted)

Alg. 3 Release at locality ℓ (untrusted, binary tree)

1: // CityOS node at locality ℓ 2: D𝑒 ← [ ] // frame sequence for current AW 𝑒 3: ActiveIDs ⊆ Id, init ∅ 4: Tracker // multi-object tracker

1: // CityOS node at locality ℓ 2: 𝑆 > 0 // declared sensitivity (Def. B.19) 3: 𝜀 > 0 // per-tree-node privacy cost 4: 𝑁 > 0 // AWs per container (Def. B.7) 5: Tree ← NewBinaryTree(𝑁 ) // B𝑁 as in §B.5 6: ShadowSum ← 0 // bridging sum for shadow container

5: def ProcessFrame(frame𝑖 ) 6: 7: 8: 9: 10:

rawDets ← Detector.Run(frame𝑖 ) 𝐹𝑖 ← Tracker.Assign(rawDets) ActiveIDs ← ActiveIDs ∪ 𝐹𝑖 ActiveIDs ← ActiveIDs \ {id : absent ≥ 𝜏exit } D𝑒 .Append(𝐹𝑖 )

7: leafIdx ← 0 // leaf counter within current container 8: def OnAW(𝑒) 9: 𝑦𝑒 ← min(RunApp(Raw𝑒 ), 𝑆) 10: Tree.AddLeaf(𝑦𝑒 ) // insert 𝑦𝑒 as next leaf of B𝑁 11: leafIdx ← leafIdx + 1

if leafIdx > 𝑁 /2 then // second half of container ShadowSum ← ShadowSum + 𝑦𝑒 14: for all 𝑣 ∈ Tree whose subtree rooted at 𝑣 just became complete do // release per Eq. 11 15: 𝜂 𝑣 ∼ Lap(𝑆/𝜀) 16: CloudRelease(ℓ, 𝑣, sum(𝑣) + 𝜂 𝑣 ) 17: Broadcast(ℓ, 𝑒, (log2 𝑁 + 2)𝜀) // Def. B.18

11: def AWRelease(𝑒, 𝑄 𝑟 , 𝜀) 12: result ← 𝑄 𝑟 (D𝑒 ) 13: 14: 15: 16:

12: 13:

𝜂 ∼ Lap(𝜇𝑄𝑟 /𝜀) CloudRelease(ℓ, 𝑒, result + 𝜂) Broadcast(ℓ, 𝑒, (log2 𝑁 + 2)𝜀) D𝑒 ← [ ]

Then Δ(𝜌𝑟 ) = 𝑆𝑟 .

18: def OnContainerEnd // shadow bridging release 19: 𝜂 ∼ Lap(𝑆/𝜀) 20: CloudRelease(ℓ, shadow, ShadowSum + 𝜂) 21: Teardown(Tree) // destroy all raw state ("container

(9)

Proof. Neighboring databases differ by zeroing out one context record, replacing one summand 𝑦 𝑗 ∈ [0, 𝑆𝑟 ] by 0. Hence |𝜌𝑟 (𝐷) − 𝜌𝑟 (𝐷 ′ )| = 𝑦 𝑗 ≤ 𝑆𝑟 . The bound is achieved by 𝑦 𝑗 = 𝑆𝑟 . □

22: 23: 24:

The individual sensitivity Δ𝑥 (𝜌𝑟 ) equals 𝑦 if 𝑥 = (ℓ, 𝑒, 𝑦) corresponds to the report’s AW, and 0 otherwise. B.4.3 DP of untrusted API 2 releases.

the binary tree and shadow to obtain the node-level privacy and utility bounds stated in Theorems B.1-B.3.

Theorem B.23 (DP via Laplace noise (untrusted)). Fix an untrusted API 2 report 𝜌𝑟 with declared sensitivity 𝑆𝑟 . The mechanism 𝑀 (𝐷) := 𝜌𝑟 (𝐷) + 𝜂,

𝜂 ∼ Lap(𝑆𝑟 /𝜀),

ephemerality") Tree ← NewBinaryTree(𝑁 ) ShadowSum ← 0 leafIdx ← 0

B.5 Binary Tree Mechanism This section formalizes the binary tree mechanism within the maxECsys container (Def. B.7). Write 𝑁 := maxECsys /AW𝑄 for the number of AW leaves per primary container, ℎ := log2 𝑁 , where 𝑁 = 2ℎ , ℎ ≥ 1, Δ ∈ {𝑆𝑟 , 𝜇𝑄 } for the per-AW sensitivity (depending on it being trusted or untrusted), and 𝜎 2 := Var(Lap(Δ/𝜀)) = 2Δ2 /𝜀 2 .

(10)

is (𝜀, 0)-DP. The noise scale depends only on the declared sensitivity 𝑆𝑟 , so the system does not need to inspect the application’s internal computation. Alg. 3 shows the runtime procedure. Each AW’s capped output is fed into the primary container’s binary tree. AWs in the second half of the container additionally accumulate into the shadow’s running sum, which produces one bridging release at the container boundary. The node continuously broadcasts (ℓ, 𝑒, 𝜌) (Def. B.18) so that every device in range accounts for the same loss 𝜌 = (log2 𝑁 + 2)𝜀. All users are charged pessimistically since the opaque application output may depend on any of them. The per-AW DP guarantees for both modes are now established: (𝜀, 0)-DP per release under ∼id (trusted) or ∼ (untrusted), with sensitivity Δ = 𝜇𝑄 or Δ = 𝑆𝑟 respectively. The next two sections compose these per-AW guarantees across

The base case. We first deal with the simpler case where the queried interval lies entirely within one primary container. Fix a locality ℓ and one primary container 𝑎𝑘(0) spanning 𝑁 consecutive AWs 𝑒 1, . . . , 𝑒 𝑁 . Build a complete binary tree B𝑁 whose 𝑁 leaves are 𝑒 1, . . . , 𝑒 𝑁 . Each node 𝑣 at depth 𝑑 (root at depth 0, leaves at depth ℎ) represents a contiguℎ−𝑑 consecutive leaves. Define sum(𝑣) := ous Í block of 2 𝑡 ∈leaves(𝑣) 𝑦𝑡 . At the end of each AW 𝑒𝑡 , the mechanism releases noisy partial sums for every node 𝑣 such that 𝑒𝑡 is the last leaf in the subtree rooted at 𝑣 (i.e., the subtree rooted at 𝑣 just became complete): 𝑠˜ (𝑣) := sum(𝑣) + 𝜂 𝑣 , 22

𝜂 𝑣 ∼ Lap(Δ/𝜀),

(11)

B.6

with all 2𝑁 − 1 noise draws being independent. This is the standard binary mechanism of [17]. Shadow container. A shadow container is initialized 𝑁 /2 AWs before each primary container reset (Def. B.7). The shadow maintains a running sum over the second half of the primary container (AWs 𝑁 /2 + 1 through 𝑁 ). At the primarycontainer boundary (position 𝑘𝑁 ), the shadow releases one additional noisy partial sum, perturbed by Lap(Δ/𝜀). This single bridging release connects two adjacent primary containers, enabling interval-sum recovery across primary-container boundaries. Each AW in the second half of a container participates in log2 𝑁 + 1 releases from the primary tree plus 1 bridging release from the shadow, for a total of log2 𝑁 + 2 releases. AWs in the first half participate in log2 𝑁 + 1 tree releases only, so log2 𝑁 + 2 is a worst-case bound that applies uniformly to all AWs. Longer queried intervals via decomposition and induction. Next, we build the tools for handling queries whose intervals (1) span a primary-container boundary, (2) cover more than 𝑁 AWs, or both. Definition B.24 (Canonical interval decomposition). For a contiguous sub-interval [𝑖, 𝑗] ⊆ [1, 𝑁 ], the canonical decomposition Can( [𝑖, 𝑗]) is the unique minimal set of nodes in B𝑁 whose leaf sets partition {𝑖, . . . , 𝑗 }. Define 𝑉 (𝑁 ) := 2(ℎ − 1) for 𝑁 ≥ 4 and 𝑉 (2) := 1.

End-to-End Privacy Guarantee Enforced on Each Node We first establish a per-query privacy guarantee at the AW𝑄 level, then compose across all queries at TC granularity to prove Thm. B.1 and Thm. B.2. Lemma B.26 (Per-query, per-AW DP under ∼id ). Fix a single query 𝑄𝑞 with aggregation window AW𝑄𝑞 , tree size 𝑁𝑞 = maxECsys /AW𝑄𝑞 , and per-tree-node privacy parameter 𝜀𝑞 . Fix an AW 𝑒 of 𝑄𝑞 . Then the joint release of all noisy tree-node partial sums and the shadow bridging release for query 𝑄𝑞 involving 𝑒’s data is ((log2 𝑁𝑞 + 2)𝜀𝑞 , 0)-DP under ∼id (i.e., with respect to adding or removing a single tracked ID in 𝑒). Proof. Let 𝐷 ∼id 𝐷 ′ differ by one tracked ID in AW 𝑒. Then |𝑦𝑒 (𝐷) −𝑦𝑒 (𝐷 ′ )| ≤ Δ𝑞 and 𝑦𝑒 ′ (𝐷) = 𝑦𝑒 ′ (𝐷 ′ ) for all 𝑒 ′ ≠ 𝑒. Let {𝑀 𝑗 }𝐿𝑗=1 with 𝐿 := log2 𝑁𝑞 + 2 denote the releases involving 𝑒: log2 𝑁𝑞 + 1 tree-node sums plus at most 1 shadow bridging release. Each 𝑀 𝑗 adds independent Lap(Δ𝑞 /𝜀𝑞 ) noise. By the Laplace mechanism, each 𝑀 𝑗 satisfies (𝜀𝑞 , 0)-DP under ∼id . The noise draws are mutually independent, so by Lem. B.11, we get that (𝑀1, . . . , 𝑀𝐿 ) is (𝐿 · 𝜀𝑞 , 0)-DP = (log2 𝑁𝑞 + 2)𝜀𝑞 , 0 -DP. (12) □

Theorem B.1 (restated). The node enforces a global privacy filÍ𝐾 ter with per-TC capacity 𝜌 node := 𝑞=1 (log2 𝑁𝑞 +2)𝜀𝑞 . For any user 𝑢 present during TC 𝑒, the joint release across all queries Lemma B.25 (Prefix and suffix canonical sizes). Let popcount(𝑛) involving 𝑒’s data is (𝜌 user 𝐷 ′ . node, 0)-DP with respect to 𝐷 ∼𝑢 denote the number of 1-bits in the binary representation of a positive integer 𝑛. Proof. Fix TC 𝑒 and user 𝑢 present during 𝑒. By tracking fidelity, 𝑢 has one tracked ID id𝑢 within 𝑒. For each 𝑞 ∈ 1. A prefix [1, 𝑟 ] in B𝑁 has |Can( [1, 𝑟 ])| = popcount(𝑟 ). [𝐾], let 𝑒𝑞 denote the unique AW of 𝑄𝑞 containing 𝑒 (since 2. A suffix [𝑁 −ℓ +1, 𝑁 ] in B𝑁 has |Can( [𝑁 −ℓ +1, 𝑁 ])| = AW 𝑄𝑞 /𝜏TC ∈ N). Let M𝑞 denote the joint release of 𝑄 𝑞 popcount(ℓ). for AW 𝑒𝑞 . Under 𝐷 ∼𝑢user 𝐷 ′ , removing 𝑢 from 𝑒 removes 3. For any [𝑖, 𝑗] ⊆ [1, 𝑁 ], |Can( [𝑖, 𝑗])| ≤ 𝑉 (𝑁 ). id𝑢 from 𝑒𝑞 , i.e., one step under ∼id . By Lem. B.26, M𝑞 is 𝐾 use independent noise Proof. (1) By induction on ℎ. Base case ℎ = 1: 𝑟 ∈ {1, 2}, ((log2 𝑁𝑞 + 2)𝜀𝑞 , 0)-DP. The {M𝑞 }𝑞=1 Can( [1, 𝑟 ]) consists of one node, and popcount(𝑟 ) = 1. For (separate trees), so by Lem. B.11, we get that (M1, . . . , M𝐾 ) the inductive step, if 𝑟 ≤ 𝑁 /2, then [1, 𝑟 ] lies in the left is Í subtree and |Can( [1, 𝑟 ])| = popcount(𝑟 ) by induction. If 𝐾 (log 𝑁 + 2)𝜀 , 0 -DP = (𝜌 node, 0)-DP. (13) ′ 𝑞 𝑞 𝑞=1 2 𝑟 > 𝑁 /2, write 𝑟 = 𝑁 /2 + 𝑟 . The prefix decomposes as the left child of the root (one node) plus the prefix [1, 𝑟 ′ ] in □ the right subtree (popcount(𝑟 ′ ) nodes by induction). Total: Theorem B.2 (restated). Fix a user 𝑢 and one maxECsys win1 + popcount(𝑟 ′ ) = popcount(𝑁 /2 + 𝑟 ′ ) = popcount(𝑟 ). dow at locality ℓ. Let 𝑒 1, . . . , 𝑒𝐺 (𝐺 ≤ maxECsys /𝜏TC ) be the (2) By symmetry: reflect B𝑁 (swap left/right children at (𝑔) TCs during which 𝑢 is present, with per-TC filter capacity 𝜌 node . every level). The suffix [𝑁 − ℓ + 1, 𝑁 ] maps to the prefix Í (𝑔) [1, ℓ] in the reflected tree. By part (1), this has popcount(ℓ) The total privacy loss is at most 𝐺 𝑔=1 𝜌 node . Releases from disnodes. tinct maxECsys windows are computed on independent state (3) If 𝑖 ≤ 𝑁 /2 < 𝑗, write [𝑖, 𝑗] = [𝑖, 𝑁 /2] ∪ [𝑁 /2 + 1, 𝑗]. and compose additively. The first piece is a suffix of the left subtree of length ℓ ′ = (𝑔) 𝑁 /2 − 𝑖 + 1, the second is a prefix of the right subtree of Proof. By Thm. B.1, the joint release for each 𝑒𝑔 is (𝜌 node, 0)length 𝑟 ′ = 𝑗 − 𝑁 /2. Both ℓ ′, 𝑟 ′ ≤ 𝑁 /2, so each popcount DP under ∼𝑢user restricted to 𝑒𝑔 . Removing 𝑢 from all 𝐺 TCs is at most ℎ − 1. Total: at most 2(ℎ − 1) = 𝑉 (𝑁 ). The other yields 𝐷 = 𝐷 0 ∼𝑢user 𝐷 1 ∼𝑢user · · · ∼𝑢user 𝐷𝐺 = 𝐷 ′ . By cases (𝑗 ≤ 𝑁 /2 or 𝑖 > 𝑁 /2) follow by induction. □ Lem. B.11 with 𝛿 = 0, we get that the total privacy cost 23

𝑂 (log 𝑁 ) total raw state.

is 𝐺 ∑︁

(𝑔)

(14)

𝜌 node .

𝑔=1

The CityOS API 3 design and privacy guarantees largely inherit from Attribution. We leverage prior formal analyses of Attribution [75] via a mapping between API 3 measurements and Attribution primitives. Our argument is currently intuitive: we outline this mapping and rely on its correspondence to Attribution, but do not formalize it here (formalization is ongoing).

□ Proposed device-side accounting. At the beginning of (𝑔) each TC 𝑒𝑔 , the node computes 𝜌 node from the currently (𝑔)

registered queries and continuously broadcasts (ℓ, 𝑒𝑔 , 𝜌 node ) (𝑔)

(Def. B.18). A device in range records 𝜌 node once per TC Í (𝑔) and accumulates 𝑔 𝜌 node over the TCs during which it is present.

C.1 Mapping API 3 to Attribution We detail API 3’s functioning to make the mapping between API 3 and Attribution explicit. Fig. 4 illustrates the workflow. 1 In API 3, applications register cross-location measurements at CityOS nodes along (and optionally within) a target corridor. Each measurement consists of simple device-side instructions that map directly to Attribution primitives. For example, in a linger-time measurement, entry nodes instruct devices to record the current time (analogous to saving an impression), while exit nodes instruct devices to report the elapsed time since entry (analogous to attributing a conversion to a previous impression). Additional instructions within the corridor (e.g., recording intermediate locations) correspond to further impression events from which one or more reports are later generated and budgeted separately. 2 Nodes store registered measurements and 3 broadcast them locally. 4 The CityOS mobile app receives these broadcasts and forwards them to Attribution for execution. 4.1 Devices record small amounts of local state corresponding to these instructions, analogous to Attribution’s impression storage. Upon a reporting trigger, the device generates an encrypted report using trajectory-specific functions (e.g., bounded time differences or L1-bounded histograms over visited locations). These are variations of Attribution’s conversion logic, preserving the bounded-sensitivity constraints required for correct IDP accounting. 4.2 We reuse Attribution’s IDP accounting, extending it to include API 2 privacy losses (§4.2), and expose it as a unified CityOS component. Unlike API 2, where privacy is enforced at the node and accounted on devices, API 3 enforces and accounts for privacy entirely on-device. Each device maintains an epoch-level budget (e.g., weekly), deducts privacy loss upon generating reports, and suppresses further contributions once the budget is exhausted (e.g., by returning encrypted null values). 5 Devices send encrypted reports to the application backend, which 6 aggregates reports across users and 7 submits them for secure aggregation (MPC/TEE), as in Attribution. 8 The aggregation service computes noisy aggregates consistent with the on-device accounting and returns DP results to the application. A key difference from the web setting is the absence of

B.7

Utility of Binary Tree Mechanism with State Reset We restate and prove Thm. B.3. Recall from Def. B.24 that 𝑉 (𝑁 ) := 2(ℎ − 1) = 2(log2 𝑁 − 1) for 𝑁 ≥ 4 is the worst-case number of tree nodes needed to decompose any sub-interval of [1, 𝑁 ]. Theorem B.3 (restated). Let 𝜎 2 = 2Δ2 /𝜀 2 be the per-node noise variance. (1) For short intervals where |𝐼 | ≤ 𝑁 /2, the interval sum can be recovered from released tree-node values with noise variance at most 𝑉 (𝑁 ) · 𝜎 2 . (2) For long intervals where |𝐼 | = 𝑘𝑁 /2+𝑅 with 𝑘 ≥ 1 and 0 ≤ 𝑅 < 𝑁 /2, the interval sum can be recovered with variance at most (𝑘 + 𝑉 (𝑁 )) · 𝜎 2 . Proof. Case 1: |𝐼 | ≤ 𝑁 /2. If 𝐼 lies within one primary container, by (3) of Lem. B.25, we have |Can(𝐼 )| ≤ 𝑉 (𝑁 ), so Var[𝑆ˆ(𝐼 )] ≤ 𝑉 (𝑁 ) · 𝜎 2 . (15) If 𝐼 straddles a boundary, write 𝐼 = 𝐼 1 ∪ 𝐼 2 with 𝐼 1 a suffix of one container (|𝐼 1 | = 𝑠) and 𝐼 2 a prefix of the next (|𝐼 2 | = 𝑝), 𝑠 + 𝑝 ≤ 𝑁 /2. By Lem. B.25(1-2): |Can(𝐼 1 )| + |Can(𝐼 2 )| = popcount(𝑠) + popcount(𝑝) (16) ≤ 2(ℎ − 1) = 𝑉 (𝑁 ).

(17)

All noise draws across the two trees are independent, giving Var[𝑆ˆ(𝐼 )] ≤ 𝑉 (𝑁 ) · 𝜎 2 . Case 2: |𝐼 | > 𝑁 /2. Write |𝐼 | = 𝑘𝑁 /2 + 𝑅 with 𝑘 ≥ 1, 0 ≤ 𝑅 < 𝑁 /2. The depth-1 nodes tile the timeline into aligned 𝑁 /2-blocks, each answered by one tree node with variance 𝜎 2 . Decompose 𝐼 into at most 𝑘 complete blocks plus two residual pieces (a suffix and a prefix, each < 𝑁 /2). By (1-2) of Lem. B.25: total nodes ≤ 𝑘 + popcount(𝑠) + popcount(𝑝) ≤ 𝑘 + 𝑉 (𝑁 ).

API 3: Cross-Locality Aggregation – Intuitive Privacy Analysis

(18) (19)

All noise draws are independent, so Var[𝑆ˆ(𝐼 )] ≤ (𝑘 +𝑉 (𝑁 )) · 𝜎 2. □ Remark (bounded state). At most two containers are active at the same time, since primary and shadow starts are offset by 𝑁 /2 AWs. Each primary tree requires at most ℎ+1 running partial-sum counters (one per node on the incomplete rootto-leaf path), and the shadow maintains 1 running sum, for 24

40 30 20 10 0

5060 Ti Jetson AGX Orin

5 10 20 30 40 50 60 maxEC

(s)

(a) Frames dropped (%)

20 10 0

5060 Ti Jetson AGX Orin

5 10 20 30 40 50 60 maxEC

(s)

(b) Effective FPS

Fig. 8. API 1 performance overhead vs. maxEC on a desktop 5060 Ti and an edge Jetson AGX Orin. (a) Percentage of input frames dropped during container rotation. (b) Effective throughput in frames per second. The 5060 Ti reaches near-zero drops and 30 FPS by maxEC≥10 s; the Jetson plateaus near ∼17% drop / ∼25 FPS due to its slower GPU. Each data point runs for 5×maxEC to ensure at least five rotation cycles.

D.1 API 1: On-Scene Sniffing attack with maxEC – methodology. We simulate the sniffing attack from §4.1: a mobile adversary traverses the city and, at each intersection, reads the current API 1 output buffer, capturing all activity accumulated since the start of the current EC window. We grant the attacker full buffer access upon arrival, providing an upper bound on any sniffer’s capability. This evaluation targets small-scale sniffing; large-scale defenses (anonymization, regulation) are orthogonal and not modeled. We construct the simulation over Midtown Manhattan (14th–59th Streets, ∼3.5 × 3.5 km, ∼540 intersections), extracted from OpenStreetMap and converted to SUMO [45]. Synthetic traffic traces are calibrated to 10% of peak-hour Manhattan volumes [50, 57, 58], providing realistic density in the absence of public city-scale traces. We model four attacker profiles: pedestrian (1.3 m/s), cyclist (5.4 m/s), car (13.4 m/s), and a static device at Times Square. Mobile attackers follow a greedy routing strategy that maximizes new intersections visited per unit time. We sweep maxEC ∈ {30s, 1min, 2min, 3min, 4min, 5min} and report the fraction of total city-wide person-activity (person-seconds across all intersections) captured over one hour. Frames dropped with maxEC – methodology. We evaluate API 1 container-rotation overhead using the Object Detection and Tracking service (YOLO26n), which processes raw video frames and emits per-frame bounding boxes. We use the MTID pole-camera dataset (38 minutes, 30 FPS) [37] and measure the percentage of input frames dropped (not processed within the real-time deadline) while sweeping maxEC ∈ {5, 10, 15, 20, 25, 30, 40, 50, 60} s on an Nvidia 5060 Ti (desktop GPU) and an Nvidia Jetson AGX Orin (edge GPU).

C.2 Intuitive Privacy Claim Under the above mapping, an API 3 measurement can be viewed as an instance of an Attribution measurement in which: (i) infrastructure broadcasts induce impression events or reporting triggers, (ii) device-side logic generates conversion reports, and (iii) reporting is governed by on-device individual differential privacy (IDP) accounting. We therefore invoke Thm. . 1 of [75], and claim that API 3, through its use of Attribution, satisfies (device, epoch)-level individual differential privacy, meaning that the inclusion or exclusion of any single device’s participation within an epoch (e.g., a week) has a bounded effect on the distribution of outputs, as determined by the device’s configured privacy budget. The argument is informal. A formal reduction, currently under development, requires: (1) formalizing the data, query, and system model of CityOS API 3 and showing equivalence to Attribution’s; (2) formalizing node-user coordination as having an effect equivalent to the “report identifier” in [75] – the logical construct that was introduced to capture the shared context between device and conversion site, by which a device “self-identifies” to participate (and incur privacy loss) or not in a measurement; and (3) showing that our unidirectional node-user coordination protocol introduces no additional privacy leakage beyond what is already captured in Attribution. Despite the lack of a full formalization, we highlight an intriguing parallel: public sensing must explicitly implement a construct that is inherent on the web, but which Attribution needed to introduce conceptually to model that behavior. This reinforces our web analogy – and its breaking points – as a useful guide for designing privacy in public sensing.

Effective FPS

Frames Dropped (%)

an explicit interaction channel through which users are associated with specific measurements. On the web, this association is inherent: a user visiting a site and performing an action (e.g., a purchase) establishes a shared view between browser and querier of which measurement the user participates in. This information is essential for IDP accounting, ensuring that privacy loss is charged only for relevant measurements. In CityOS, we reconstruct this association via node-user coordination: devices self-identify as relevant to specific measurement contexts based on broadcast annotations and local sensing, and execute the corresponding reporting logic. Intuitively, this serves as a physical-world analogue of the implicit interaction channel between the browser and conversion site in Attribution.

D.2 API 2: Single-Locality Aggregation DP counting accuracy – methodology. We evaluate counting accuracy on NYC DOT bicycle counts from the Williamsburg Bridge Eco-Counter (15-minute bins over 30 days, 2,880 bins).

Evaluation – Methodology Details

This section provides full methodological details for each experiment in §6. Each subsection mirrors the corresponding evaluation subsection in the paper body. 25

We implement DP continual release using the Toeplitz mechanism [26], a state-of-the-art approach that provides stronger utility than the tree-based mechanism described in §4.2 while preserving analogous guarantees. We describe the tree-based mechanism in the body for simplicity of exposition, but use Toeplitz in our prototype for its superior performance in both the trusted and untrusted modes. We aggregate bins into windows ranging from 1 to 12 hours and add Gaussian noise matching the Toeplitz marginal distribution (𝑇max = 1,440, 𝛿 = 10−5 ). We report root mean square relative error (RMSRE) [33] averaged over 1,000 Monte Carlo trials. This per-period simulation is unbiased (§B.2). We sweep 𝜀 ∈ {0.1, 1.0} under two configurations: trusted (sensitivity Δ = 5, justified below) and untrusted (output clamping to [0, 100], yielding Δ = 100). The latter value is chosen to match the order of magnitude of counts over the largest aggregation window (12 h), ensuring that measurements are not artificially clamped in the untrusted setting. We assume the querier does not know the exact value a priori, but can set a reasonable order-of-magnitude upper bound, here 100. The sensitivity ratio Δ𝑈 /Δ𝑇 = 20 directly scales the noise. The hero figure plots three lines – trusted at 𝜀=1, trusted at 𝜀=0.1, and untrusted at 𝜀=1 – to highlight that trusted mode more than compensates for a 10× tighter privacy budget. Empirical sensitivity benchmark for trusted mode – methodology. Pipeline under test. We run the identical detector and tracker configuration deployed by the CityOS Object Detection and Tracking service. The detector is YOLOv26n [76], an NMS-free end-to-end architecture, with confidence threshold 0.5 and person-only class filter (class 0). The tracker is BoT-SORT [3] using the production configuration: high/low detection thresholds of 0.25/0.1, track buffer of 90 frames (3 s at 30 fps, extended from default to accommodate CityOS’s frame-dropping architecture), IoU matching threshold 0.8, no camera motion compensation (gmc_method: none), and no re-identification network (with_reid: false). A fresh model instance is created for each sequence, resetting all tracker state (track IDs, Kalman filters, lost track buffer) to match CityOS’s per-ephemeral-context lifecycle. Dataset. We use the MOT17 benchmark [49] training set, which provides annotated pedestrian sequences at 1920×1080 resolution. We restrict to the four static-camera sequences (MOT17-02, 04, 05, 09; 3,012 frames total), excluding three moving-camera sequences (MOT17-10, 11, 13) because CityOS deploys on static pole-mounted cameras and the BoT-SORT configuration disables camera motion compensation. Ground truth is filtered to class 1 (pedestrian) with confidence flag 1 (not ignored). Method. For each frame, ground-truth bounding boxes are matched to tracker outputs using the Hungarian algorithm [42] on an IoU cost matrix. We discard assignments with IoU < 0.5, following the CLEAR MOT standard [10]. For each GT 26

identity across all frames in a sequence, we collect the set of distinct tracker IDs matched to it; the cardinality of this set is the number of track IDs assigned to that person. GT identities never matched to any tracker output are excluded to avoid conflating detection recall with tracking ID consistency. Limitations. MOT17 depicts European street scenes; deployment may involve different camera angles, lighting, or crowd densities. The sequences are 17–35 s at 30 fps; longer sequences may exhibit more ID switches as individuals leave and re-enter the scene beyond the 3 s track buffer. The confidence threshold of 0.5 matches production but discards low-confidence detections, which may cause track fragmentation on re-detection. BoT-SORT runs without ReID, so reidentification after long occlusions relies solely on Kalman filter motion prediction; enabling ReID would likely reduce Δ but is not part of the production configuration. D.3 API 3: Cross-Locality Aggregation Subway OD estimation under per-device budgets – methodology. We use the Hangzhou Metro smart-card dataset [44], containing 29.2 M trips from 4.97 M riders across 80 stations over 25 days. Unlike aggregate OD datasets, it provides peruser histories, enabling direct modeling of budget exhaustion. Entering station 𝐴 records an event locally; exiting at 𝐵 triggers a report consuming 𝜀 rep = 0.5 from the device’s weekly budget 𝜀. Once 𝜀 is exhausted, subsequent reports are replaced with encrypted nulls, introducing bias due to missing contributions. We capture this alongside standard DP noise in RMSRE, where budget exhaustion contributes bias error and DP noise contributes unbiased variance. Each station aggregates received reports into an 80 × 80 OD matrix and adds Laplace noise with scale 𝑏 = 2.0. We vary two parameters: (1) device budget 𝜀 (1–10 and ∞), and (2) batch length (hour/day/week). RMSRE is computed exactly (no Monte Carlo) since both budget exhaustion and noise are analytically characterized. D.4 API 3: Self-Identification Stage 1: IMU activity classification – methodology. We employ a histogram-based gradient boosting classifier to distinguish the three modes of human activity: walking, driving, and cycling based on the six-channel IMU data (accelerometer and gyroscope). Raw recordings are obtained from three heterogeneous sources: Vi-Fi pedestrian traces [43], in-vehicle accelerometer and gyroscope pairs [79], and PAMAP2 cycling segments [65]. All samples go through a shared preprocessing stage that includes normalization to rad/s, resampling frequencies, and segmenting the continuous signals to 3-second sliding windows. Each window is flattened into a 900-dimensional feature vector and fed to a histogram-based gradient boosting classifier in a stratified group k-fold setting to prevent data leakage. To assess the robustness of the trained classifier to sensor noise, we evaluated its performance under synthetically in-

jected Gaussian perturbations of increasing magnitude. For each feature, we computed the standard deviation across the held-out test set. At each noise level 𝜎scale , zero-mean Gaussian noise was drawn independently for each observation and each feature dimension, scaled by the product of the perfeature standard deviation and 𝜎scale , and added to the clean test data. A noise level of 0.0 corresponds to the unperturbed test set, while a noise level of 1.0 indicates that the injected perturbation has the same spread as the natural variability of each feature. This feature-relative scaling ensures that noise magnitudes are comparable across features with different dynamic ranges, providing a realistic simulation of sensor degradation. Multiple independent trials were averaged at each noise level to reduce sampling variance. Stage 2: Bounding-box to IMU matching – methodology. Stage 2 matches each phone to a visual bounding-box track. For each 5 s window (2.5 s hop), we compute Welch PSDs of IMU magnitude and visual motion signals in the 0.7–3.0 Hz walking band, form a 𝑃×𝑇 cost matrix of pairwise cosine distances, augment it to (𝑃+𝑇 )×(𝑃+𝑇 ) with an adaptive unassignment penalty 𝜆 (75th-percentile of the cost distribution), and solve the assignment with the Hungarian algorithm [42]. Any phone or track matched to a dummy counterpart is declared unmatched. We evaluate on Vi-Fi outdoor sequences [43] using windowlevel micro-averaged F1-score. In deployment, the camera observes many tracks without a matching phone. We inject 0–10 distractor tracks from other scenes (3 random trials). Impact on API 3 utility – methodology. We reuse the Hangzhou Metro trip dataset from §6.3 (29.2 M trips, 80 stations, 25 days) and enrich it with transfer information via shortest-path routing over the station adjacency graph, identifying 13.6 M transfer events – passengers present at intermediate stations without exiting. We parameterize the end-to-end self-identification pipeline by a single detection rate 𝑎 ∈ [0, 1]: recall (fraction of true exiters correctly detected) = 𝑎, and false positive rate (fraction of transfer passengers falsely detected as exiters) = 1−𝑎. This single-parameter sweep suffices for the sensitivity analysis we present. Stage 2 (cross-modal matching) determines which bounding-box track a phone corresponds to, not whether an exit occurred, so its errors are orthogonal to the OD error modeled here. A second parameter 𝑝 ∈ {0, 0.5, 1.0} scales the fraction of transfer passengers near exit gates, modeling station geometries from transfers far from gates (𝑝=0) to fully overlapping transfer and exit paths (𝑝=1). For each (𝑎, 𝑝) pair, the expected per-bin signed OD error is (𝑎−1) · 𝑛 true + (1−𝑎) · 𝑝 · 𝑛 transfer : missed exits (negative) and spurious entries (positive). We aggregate over weekly batches and compute RMSRE as in §6.2, including the analytic Laplace noise floor (𝑏 = 1/𝜀 rep = 2.0, yielding RMSRE = 0.0025). We report results against F1 score; because 𝑝 affects the false positive count, F1 depends on both 𝑎

and 𝑝, so curves for different 𝑝 values occupy different x-axis ranges.

Record · ID 155401 · SHA-256 f8adfe17bdc64e55
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.