The Physical World Is Part of the Attack Surface

The thing that set me off on this line of thought was Safari refusing to support the web Vibration API. At first glance that looks petty. Let the page buzz the phone. Who cares. Then you read the actual privacy discussion and realise the browser vendors are not being paranoid enough, if anything. The problem is not that vibration itself reveals some secret. The problem is that once the web can make a device do something physical, and once some other observable system can sense the result, you have created a new channel.

That is the pattern underneath a huge amount of security research: take a boring capability, combine it with a second boring capability, and suddenly you have something that feels like spycraft.

The web standards discussion around vibration is unusually candid about this. The spec's security and privacy considerations explicitly call out fingerprinting risk when vibration is combined with motion sensors, and also the simpler fact that a physically vibrating device can be identified by nearby observers. The working group's 2024 self-review goes even further: it effectively says "yes, this can be risky, but maybe we can constrain it enough with user activation, silent no-op behaviour, and rate-limiting." WebKit looked at the same class of risk years earlier and chose not to play. I get it.

What fascinates me here is not just the API. It is the deeper lesson. The physical world is part of the attack surface whether we acknowledge it or not.

Composition is where things get weird

Most systems are designed as though capabilities are isolated. Camera access is one thing. Motion sensors are another. Audio output is another. CSS is styling. The cache is performance infrastructure. DRAM is just memory. None of these sound sinister on their own.

The trouble starts when two individually boring systems compose.

• An actuator plus a sensor becomes a covert channel.
• A user-facing output plus precise timing becomes a fingerprint.
• A performance optimisation plus speculative execution becomes a data leak.
• A browser feature plus CSS state becomes history sniffing.

That is why so many attacks feel magical. They are not usually exploiting one obviously dangerous primitive. They are exploiting the gap between how we categorise primitives and how reality lets them interact.

Once you start looking for this pattern, you see it everywhere.

Vibration is a perfect example

The Vibration API is almost comically simple: a page asks the device to buzz for some duration or pattern. That feels nowhere near the sensitivity of geolocation, the camera, or the microphone. But "simple" is misleading here.

If a phone vibrates in a repeatable pattern, another sensor can potentially observe the response. An accelerometer or gyroscope has manufacturing quirks. The chassis of a device resonates in slightly different ways. A site that can trigger vibration and sample other signals may be able to infer something device-specific. That turns haptics into an indirect fingerprinting primitive. The spec now says this out loud, which is rare and refreshing.

Even before you get into that more sophisticated model, there is the coarse version: a website causes a physical buzz and someone in the room can tell which phone it was. The browser has just let remote content produce an externally observable real-world side effect. That alone is enough to make conservative vendors nervous.

This is also why the standards discussion kept reaching for mitigations instead of pretending the problem did not exist:

• require user activation
• let the browser silently ignore requests
• avoid exposing why a vibration failed
• rate-limit the calls
• let the browser or user disable the feature entirely

Those mitigations are sensible. They are also an admission that the primitive is not harmless.

The browser has a long history of "harmless" features going feral

The classic browser example is visited-link sniffing. For a long time, websites could style :visited links differently enough that pages could infer what you had clicked before. That turned what looked like a convenience feature into browsing-history leakage. The modern restrictions around :visited styling exist precisely because browsers learned the hard way that presentation state can become sensitive data.

Another good example is autoplay and user-activation gating more broadly. Audio and video playback look like straightforward media features. In practice, they became abuse surfaces. Browsers added friction not because media was intrinsically unsafe, but because web content will use any unrestricted channel to seize attention, gather signals, or route around user intent.

The same thing happened outside the browser sandbox too. The FTC's action against SilverPush is one of the most surreal examples: ultrasonic audio beacons used to link devices that happened to be in the same room. A television or app emits a near-inaudible tone, a nearby phone hears it, and suddenly "which devices belong to the same person or household" becomes inferable without the user understanding what just happened. Nothing exotic was required. Just sound, microphones, and correlation.

That is what makes this field so interesting. The cleverness is usually not in some impossibly advanced exploit chain. It is in seeing that a mundane signal can be used as glue between systems.

Five examples that feel absurd and are all real

1. Spectre

Spectre is one of the best examples of an attack that sounds fake until you understand it. The CPU speculatively executes instructions for performance, then rolls back the architectural state if the speculation was wrong. Fine. Except microarchitectural side effects, especially cache state, can remain observable. So code that should never have been allowed to read some secret data can still influence the cache in a measurable way. The secure abstraction held at one level and failed at another.

That is the recurring theme in all of these stories: a rollback at the logical level does not mean nothing happened physically.

2. Rowhammer

Rowhammer is another favourite because it turns "memory reads" into "memory corruption" through persistence and physics. By repeatedly accessing certain DRAM rows, attackers could induce bit flips in adjacent rows. No software bug in the conventional sense, just the physical reality of densely packed memory cells behaving badly under stress. Software people think in APIs and permissions. Hardware still thinks in charge leakage and interference.

3. BitWhisper

The BitWhisper paper is exactly the kind of research that sounds like someone joking and then turns out to be real. Two adjacent air-gapped computers communicate through heat. One machine modulates thermal output by changing workload. The other senses tiny temperature changes using its built-in thermal sensors. It is absurdly slow, but that misses the point. The point is that if two systems share a room, they share a medium.

4. Fansmitter

Fansmitter uses computer fan noise as a data exfiltration channel. Change fan speed, modulate acoustic output, let a nearby microphone decode the pattern. Again, the bit rate is terrible. Again, that is not the lesson. The lesson is that output channels you classify as "incidental" are still outputs.

5. Van Eck phreaking and TEMPEST

This is the old-school ancestor of all of it: screens, cables, and electronics leak electromagnetic emissions. With enough skill and the right equipment, you can reconstruct information from those emissions. The broad TEMPEST family of work is what happens when governments take seriously the proposition that computation is a physical process and therefore cannot help but radiate evidence of itself.

None of this requires science fiction. It requires taking side effects seriously.

What these attacks have in common

The common structure is almost always the same.

First, find a thing that can be influenced:

• vibration motor
• speaker
• fan
• cache
• DRAM row
• thermal output

Second, find a thing that can observe the influence:

• accelerometer
• microphone
• nearby phone
• timing measurement
• electromagnetic receiver
• thermal sensor

Third, rely on some implementation detail or physical quirk:

• manufacturing variance
• resonance
• cache eviction behaviour
• charge leakage
• room acoustics
• thermal transfer

That is it. That is the whole trick. The sophistication is in the pairing.

This is also why browser vendors and platform teams sometimes look irrationally conservative from the outside. People ask why a company would block a tiny API, or require user activation, or make a feature no-op in background contexts. The answer is usually not that the feature itself is too powerful. It is that the vendor has learned that every new primitive participates in a larger combinatorial system.

The web is especially sensitive to this because it is hostile multi-tenant computation by design. You are not exposing a primitive to one trusted application. You are exposing it to every ad, analytics script, embedded frame, growth experiment, scam page, and bored teenager with DevTools open.

Why this matters for product and architecture, not just security research

I find this useful beyond the thrill of weird attack papers because it changes how you think about building products.

When you add a capability, ask:

• Does this let remote content produce a physical side effect?
• Does it reveal timing, state, or hardware characteristics indirectly?
• Can this output be sensed by something else in the same device, browser, room, or network?
• If I say "it does not expose data directly," am I only talking about the obvious API surface?

That last question matters most. "No direct exposure" is one of those technically true phrases that often hides the interesting part. The indirect path is frequently the real one.

The same mindset also explains a lot of my instinctive preference for local-first and privacy-first architectures. Every time you remove a server, an identifier, a tracker, a third-party script, or an unnecessary sensor path, you shrink the number of compositions available to an attacker or an over-curious platform. The safest primitive is not the heavily permissioned one. It is the one you never exposed.

The real lesson

The real lesson is not "everything is broken" or "attackers are geniuses." It is more specific than that.

Computing is physical. Security models are abstractions layered on top of physical systems. Whenever those abstractions ignore timing, sound, heat, movement, power draw, radiation, or mechanical response, reality gets a vote anyway.

That is why vibration tracking feels so clever. It is not because the API is advanced. It is because it exploits the fact that software people keep pretending software is separate from the world. It is not. A device is a machine in a room, making noise, drawing power, heating up, vibrating, radiating, and interacting with other machines. The web sits on top of all of that whether the API surface admits it or not.

Once you see that clearly, a lot of browser decisions stop looking petty and start looking like scar tissue.