16 Mobile Wi-Fi and Sensing Privacy

privacy

mobile-privacy

wifi

bluetooth

sensing

evidence

16.1 Signals Can Identify Without Messages

Start with a familiar mobile-IoT moment: a phone pairs with earbuds, unlocks a speaker, or lets a room controller notice whether people are nearby. Nothing private seems to be typed or spoken. Still, the phone is broadcasting identifiers, listening for nearby radios, and reading motion or signal changes that can reveal where it is and what is happening around it.

Wireless radios and motion sensors are always interacting with their surroundings, and the privacy risk often lives in that interaction rather than in any message a device sends. The identifiers a device broadcasts, the list of access points it can see, the strength of a signal, and the readings from an accelerometer can all reveal who is present and what they are doing, without anyone reading a single line of content.

This is what makes Wi-Fi and sensing privacy different from ordinary data collection. Two distinct risks combine here. First, wireless identifiers can let separate locations recognize the same device over time and follow it. Second, signal patterns and sensor readings can be turned into inferences about presence, motion, and activity. Both happen below the level most people think of as "data."

If you only need the intuition, this layer is enough: treat wireless identifiers and signal metadata as personal data. Rely on randomized identifiers, process signal and sensor data on the device, request the narrowest scanning permission a platform offers, and be honest when a feature senses presence.

Wireless privacy has two paths to review at once. Use Figure to follow the persistent identifier risk separately from the raw-signal inference risk.

Wireless Sensing Review

Identifier -> scan permission -> raw signal -> local inference -> minimal result.

Review both tracking and sensing: randomize identifiers, scope scans, and keep raw radio measurements local.

In Figure, begin with the identifier and ask whether randomization prevents recognition across places. Then inspect the scan permission and raw signal, derive only the needed inference locally, and release a minimal result. The route removes both the fixed “name badge” and the unnecessary radio trace. It connects the chapter's two risks—tracking and sensing—to one testable minimization workflow.

Think of a crowded room. Even if you cannot hear any conversation, you could still learn a lot if every person wore a fixed name badge and if you could feel the air move as people walked around. The badges let you recognize the same person on different days, and the moving air tells you the room is occupied and active. Wireless identifiers are the badges, and signal changes are the moving air. Good design removes the fixed badge and keeps the air-reading on the device.

The One-Minute Sensing Decision

Identifiers can track

A stable wireless address can be matched across places. Prefer randomized identifiers so a device is not recognizable from one location to the next.

Signals can sense

Signal strength and channel changes can reveal presence and motion. Treat these measurements as sensitive even though they carry no content.

Minimize and decide locally

Request the narrowest scan permission, derive only the result the feature needs on the device, and disclose presence sensing plainly.

Beginner Examples

Work from the simplest case toward the broader design consequence. First, A phone that uses a randomized address when scanning is harder to follow from shop to shop than one that always shows the same address. Next, the list of Wi-Fi networks a device can see is effectively a location fingerprint, even when no coordinate is collected. Then, comparing the lists of Wi-Fi networks two different devices have seen can reveal a social relationship between their owners, such as coworkers, family, or a shared interest group, even though neither list contains a name. Finally, A presence sensor that decides "room occupied" on the device leaks far less than one that streams raw signal measurements to a server.

Overview Knowledge Check

Start simple: remove the fixed wireless name badge, ask for the smallest scan grant, and keep raw sensing close to the device. If you can explain the two risks, recognizable identifiers and inferable signals, you have the core idea. Continue to the review layer to scope a wireless or sensing feature.

16.2 Scope Scans and Keep Sensing Local

The practical work is to inventory the wireless and sensor signals a feature touches, request the narrowest access that delivers it, and keep raw signal data on the device wherever possible. As with location, the goal is a deliberate, recorded decision rather than broad access taken just in case.

What Each Signal Can Reveal

Signal

What It Can Reveal

Mitigation

First Question to Ask

Device wireless address

A persistent identifier that can be tracked across locations.

Use randomized addresses for scanning and per network.

Does anything depend on a stable address?

Probe requests

The networks a device looks for, hinting at places it has been.

Avoid logging probe contents; rely on platform randomization.

Do we need probe data at all?

Nearby access point list

A location fingerprint, even with no coordinate collected.

Map the list to a coarse place on device, do not upload raw identifiers.

Is this really a location feature in disguise?

Signal strength or channel data

Presence, motion, and coarse activity in a space.

Derive only the needed result on device; discard the raw measurements.

Does the server need the signal, or just the conclusion?

Bluetooth beacon or device

Proximity to fixed beacons or to other people's devices.

Use rotating private addresses; scan only when a feature needs it.

Is the scan tied to a visible user action?

Motion sensor stream

Activity, gait, and patterns inferable from accelerometer or gyroscope.

Limit sampling rate and treat high-rate access as sensitive.

Why does this feature need raw motion data?

Scope the Scanning Permission

Because the set of nearby access points reveals location, scanning permissions were historically tied to location access. Recent mobile platforms let an app declare a dedicated nearby-devices intent and state that scanning is not used to derive location, so a Bluetooth or Wi-Fi feature can run without requesting full location. Prefer that narrower permission whenever the feature genuinely does not need a position.

Use the narrowest scan grant

Where a nearby-devices permission exists, use it and declare the scan is not for location.

Tie scans to a visible action

Scan during pairing or an active feature, not continuously in the background.

Keep raw signals on device

Compute the result the feature needs locally and upload the conclusion, not the measurements.

Worked Example: Room Occupancy for Automation

A building automation feature wants to turn off lighting and heating in empty rooms. A weak design streams raw signal-strength and channel measurements from every room to the cloud, and logs the stable identifiers of every device it sees so it can count people. That design exports fine-grained sensing data and builds a tracking dataset as a side effect.

Stage

What It Does

Data That Leaves the Space

Privacy Result

Original design

Streams raw channel measurements and logs stable device identifiers.

Continuous sensing data plus a roster of recognizable devices.

Motion-revealing data leaves the building and people become trackable.

Review finding

The feature needs only whether a room is occupied.

Nothing yet; this is the analysis step.

The raw signal and the identifier log are both unnecessary.

Revised design

Derives an occupied-or-empty indicator on the local controller; discards raw signals; counts presence without naming devices.

A small occupancy result per room.

The automation works while raw sensing and identifiers stay local.

The lesson mirrors location: the strongest fix is to remove the sensitive raw signal from the architecture and keep only the conclusion the feature actually uses.

Practitioner Knowledge Check

If you can scope scanning to the narrowest grant and keep raw signals local, you can stop here. Continue to Under the Hood for how identifiers leak, how signal sensing works, and where mitigations fall short.

16.3 How Identifiers, Channels, and Side Channels Leak

The deeper layer explains the mechanisms behind the two risks. Identifiers leak when a device announces something stable about itself, and sensing works because radio signals and motion sensors are sensitive to the physical world around them.

How Identifiers Leak and How Randomization Helps

To find networks and devices, a radio broadcasts small management frames, such as probe requests, that include an address. If that address is the device's fixed hardware identifier, any receiver can recognize the same device wherever it appears, which is the basis of cross-location tracking. The standard mitigation is address randomization: the operating system uses a randomized address for scanning, and often a different stable-but-private address per saved network. Randomization is necessary, but it is not a complete shield on its own. The specific contents and timing of probe frames can sometimes form a weaker fingerprint, so good design also avoids broadcasting unnecessary detail and does not rely on identifiers being unlinkable forever.

How Signal Sensing Works

A wireless signal weakens and reflects as it travels, so the strength a receiver reports, often called RSSI, changes with distance and obstacles. Finer measurements of how the channel responds, sometimes exposed as channel state information, capture the multipath structure of a space. Because a moving body changes those reflections, the same radio used for communication can act as a motion and presence sensor without any camera. This is the heart of device-free sensing: an entity with access to these measurements across a space can infer occupancy and movement. The privacy implication is that signal-strength and channel data deserve the same care as a sensor feed, even though they contain no message content.

Bluetooth Addressing and Motion Side Channels

Bluetooth Low Energy addresses the tracking problem with resolvable private addresses that rotate over time, so only a paired peer holding the right key can recognize the device, while a passive observer sees a changing address. Motion sensors raise a different issue: accelerometer and gyroscope streams have historically been available to apps and web pages with little or no permission prompt, yet high-rate motion data can reveal activity and gait, and research has shown it can leak even more in some conditions. The defensive posture is to treat zero-prompt sensors as sensitive anyway, limit sampling rates, and request only the resolution a feature truly needs.

Failure Modes and Fixes

Failure Mode

How It Leaks

Evidence to Collect

First Fix to Try

Stable identifier logged

A persistent address is recorded, making devices trackable.

A check of stored records for fixed device addresses.

Use randomized addresses and stop logging stable ones.

Raw signal uploaded

Signal-strength or channel data is sent off-site and reveals motion.

A network capture during a sensing feature.

Derive the result on device and discard the raw signal.

Scan tied to location grant

A scanning feature requests full location it does not need.

The declared permissions versus the actual feature need.

Switch to the dedicated nearby-devices permission.

Continuous background scan

The app scans constantly, building a presence record.

Background scan logs and their triggers.

Scan only during a visible feature or pairing.

High-rate motion access

Fine-grained motion data is read without a clear need.

The sensor sampling rate and the feature using it.

Lower the rate and justify the resolution requested.

Common Pitfalls

Review these failure modes in order. First, Assuming "no content" means "no risk." Identifiers and signal patterns reveal who is present and that they are moving without any message being read. Next, Treating randomization as a complete fix. It is necessary but not sufficient; avoid broadcasting and logging unnecessary detail too. Then, Hiding a location feature inside a scan. A nearby access point list is a location fingerprint and should be scoped like location. Then, Streaming raw signals to the cloud. Channel and signal data can reveal motion, so derive the result locally and keep the raw data on the device. Finally, Ignoring zero-prompt sensors. Motion sensors can be sensitive even when no permission is required, so limit rate and resolution.

Under-the-Hood Knowledge Check

At this depth, wireless privacy has two moving parts: keep identifiers unrecognizable so devices cannot be followed, and keep signal and sensor data on the device so presence and motion cannot be reconstructed elsewhere. Randomization, narrow scan permissions, on-device decisions, and rate limits are the controls that make both real.

16.4 Sensor Inference Through Activity-Stream Re-identification

Pseudonyms offer little protection when a short auxiliary sequence is rare enough to correlate. Figure 16.1 matches train, gym, and clinic windows against four representative sparse streams and shows the anonymity set collapsing.

An auxiliary train-gym-clinic timeline sits above pseudonymous streams P7, P12, P44 and P83; match dots leave P7 unique after three events, followed by time coarsening, rare-event suppression, aggregation, local processing and retention limits. — Figure 16.1: Three auxiliary activity events are matched against pseudonymous sparse streams, reducing the candidate set from twelve to three to one.

In Figure 16.1, P7 matches all three windows, whereas P12 loses the clinic event and P44 loses both later events. The Anonymity set shrinks panel moves from 12 to 3 to P7 only; Break the match responds with time coarsening, rare-event suppression, cohort aggregation, local processing, and retention limits that must be tested against re-identification rate.

Removing names from a sensing dataset does not remove routines. Mobile activity streams are often high-dimensional and sparse: one person produces events across transport, location, motion, app, touch, and time dimensions, yet only a few events occur in each narrow combination. That rarity makes a short correlated sequence behave like a quasi-identifier.

Suppose an adversary observes a target board the 07:42 train on weekdays and sees a public gym check-in around 18:15 on Tuesdays. The adversary now has auxiliary sequence

A=\{(train,07{:}42,weekday),(gym,18{:}15,Tuesday)\}.

The anonymous release contains streams $S_1,\ldots,S_n$ keyed only by pseudonyms. For each auxiliary event $a_i$ , define a match to stream $S_k$ when event type/location agrees and time is within tolerance $\Delta_i$ . A simple weighted score is

score(S_k,A)=\sum_i w_i\,\mathbf{1}[match(a_i,S_k,\Delta_i)].

Weights should be larger for rarer events; an information-based choice is $w_i=-\log P(a_i)$ . The attacker ranks streams by score or by a probabilistic likelihood that also models missing and false events. The target is singled out when one stream remains plausible and the gap to the next candidate is large enough. A single train event may match hundreds of people; train then a particular gym schedule can reduce the anonymity set to one.

Walk the attack in order:

Collect auxiliary evidence. Direct observation, public posts, calendars, check-ins, or known commuting habits supply a few time-bounded activities.
Normalize representations. Map public descriptions and sensor labels to common event categories and time/location windows.
Generate candidates. Keep pseudonymous streams matching the least common event; discard impossible time/space paths.
Correlate the sequence. Add events in temporal order, allowing the measurement error and missingness expected from the sensor.
Rank and test uniqueness. Compare top scores and estimate how often an equally good match appears under a background population.
Confirm with a different channel. Gait, touch rhythm, key-flight times, Wi-Fi history, or device-specific accelerometer bias can strengthen the linkage.

That last step links two distinct signatures. Behavioral biometrics such as touch pressure, swipe timing, key hold/flight times, and gait can identify a user even after the phone changes. Device fingerprints arise from small accelerometer scale-factor, offset, and cross-axis differences that persist for one handset across users. Combining them can answer both “which person’s routine?” and “which physical device produced this stream?” Do not treat a noisy sensor as anonymous simply because its calibration is imperfect.

Defence	What it breaks	Residual trade-off
Coarsen time and location	exact event alignment and impossible-path pruning	may reduce transport or safety-analysis utility
Suppress rare combinations	high-information quasi-identifiers	can erase minority patterns and bias results
Aggregate before release	person-level sequence construction	overlapping aggregates can still leak; small cells need thresholds
Rotate scoped pseudonyms	long-term linkage under one token	routines can relink rotated tokens unless epochs and releases are designed together
Limit retention and joins	long correlated histories and cross-channel confirmation	reduces longitudinal analysis
Add formal privacy protection	bounds contribution to released statistics when correctly parameterized	does not automatically protect raw per-person streams or arbitrary downstream joins
Process locally	prevents raw touch, motion, and routine streams leaving the device	model outputs can still reveal sensitive states and need minimization

Test protection with the attack, not with identifier removal alone. Build held-out auxiliary sequences of one, two, three, and more events; measure candidate-set size, top-1 match rate, top-score margin, and subgroup disparity. Repeat with realistic timing error and missing observations. If a few common public facts still isolate a stream, coarsen, suppress, aggregate, shorten, or avoid releasing that sequence. The safe question is not “did we delete the name?” but “how much outside knowledge is needed to single someone out?”

Phoebe’s Field Notes: Why “Limit Sampling Rate” Is Not Just A Policy Knob

The mathematical gist. A 5 GHz wave is 0.0600 m long. A person walking at 1.40 m/s along that radio path creates a 46.7 Hz Doppler shift, so the receiver needs at least 93.3 samples/s to reconstruct it. A 10 Hz privacy limit instead folds that motion to about 3.33 Hz, while the chapter’s stated breathing example produces only 0.628 Hz.

16.5 Summary

Carry the chapter’s decisions forward in order. First, wi-Fi and sensing privacy involves two risks: wireless identifiers can let separate locations recognize and track a device, and signal patterns can be turned into inferences about presence and motion. Next, both risks operate below the level of message content, so identifiers and signal metadata must be treated as personal data. Then, address randomization is the standard mitigation for tracking, but it is necessary rather than sufficient, because probe contents and timing can still form a weaker fingerprint. Then, the set of nearby access points is effectively a location fingerprint, which is why scanning should use the narrowest permission a platform offers and declare when it is not used for location. Then, signal-strength and channel data can reveal motion through device-free sensing, so derive the needed result on the device and discard the raw measurements. Finally, bluetooth uses rotating private addresses, and motion sensors can be sensitive even without a permission prompt, so limit sampling rate and resolution.

Key Takeaway

Wireless data is sensitive even when it carries no content. Make identifiers unrecognizable so a device cannot be followed across places, and keep signal and sensor data on the device so presence and motion cannot be reconstructed off-site. Randomization, narrow scan permissions, local decisions, and rate limits are the controls that turn those goals into real protection.