I find that interesting, because you could probably classify physical location revelation attacks with other timing-based attacks for which we've had to resort to constant-time algorithms (e.g. key protection via constant-time cryptographic operations).

There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak information.

> If you make things as efficient as possible, you'll probably leak information.

at which point the threshold could lower ...

I am confused... this attack doesn't seem to be doing anything with latency?

You are right, it is only pinpointing the DNS server of the client, which usually resides in the same city, so you can find where the victim lives. It is inferred from the conversation here though that one could potentially exploit this even further to perform ping trilateration and get a better accuracy on one's location using the method described in the article. I think this spawned the comment about the timing attacks.

To some extent, this already happens. My cable modem adds about 30ms latency no matter the destination. I think this is a combination of buffer bloat (wait for buffer to fill before talking on the network) and waiting for a transmit time slot (shared access to the physical layer). I haven't looked at it in detail, but it is very surprising to me that I get 60ms RTT to Blizzard's servers in Chicago (a speed of light distance of 4ms one way) and 25-40ms ping to Google (in what they call "lga15", which is somewhere in Manahttan, probably 60 Hudson).

I realize that ping is a very poor benchmark as most routers do not handle ping in their fast path, but it's not adding 40ms of latency. So I suspect my modem.

This is extremely unusual to me. Personally I notice it when my ping to local game servers go from 5 to 25.

I’d recommended you look into it, and potentially get another modem. If all my requests started taking another 30ms, I’d consider my network degraded.

On a congested upstream, DOCSIS unfortunately seems to behave like this due to contention for and the insufficient granularity of upsteam transmission timeslots.

This effectively means that even if your share of the total upstream link of a network "collision domain" (shared coaxial medium really) is low (i.e you're using less than 1/n and accordingly should not be experiencing queueing in the modem), you might be seeing latency spikes due to having to compete and wait for transmission timeslots.

My local DOCSIS link is experiencing anything between 0 and 60 milliseconds of latency which I suspect is mostly due to this (since it's inversely correlated to upstream bandwith).

Seems like everyone with any cable ISP has this problem. It could be a modem problem, but it's happened with a variety of modems. It could be an ISP problem, but both Comcast and Spectrum users see the same thing in my experience.

I'd be interested in hearing counterexamples, but I imagine that people with good experiences are on DSL or Fiber.

I can ping 1.1.1.1 right now at 12-15ms, or Google at around 20ms, via Comcast. Less than 10ms to either one on Optimum. But it's 25-30ms to ping Optimum from Comcast.

> buffer bloat (wait for buffer to fill before talking on the network)

That's not buffer bloat (but might nevertheless be something that happens on DOCSIS modems, although I haven't heard of buffering several packets before contending for an upstream send grant).

Buffer bloat, while also rampant especially in shitty CPE like most DOCSIS modem/router combinations, would only occur when your upstream is saturated.

Supposedly though, on DOCSIS, the upstream access contention algorithm used can sometimes add the latency you describe, adding latency even for single packets.

One problem might be with latencies right at the boundary between two buckets. A bit of jitter would let you know you're near the edge with enough sampling. And if you can add a little latency then you can move the boundary where you like.

It seems like the only way to avoid that is with one bucket (constant time).

Even if it's one bucket, isn't it still vulnerable to the same attack you describe? If you push the latency to the edge, you'd know how much is yours and how much the bucket's. Even if it was randomized you could still figure out the window of the added noise with enough sampling and you're back to where you started. I don't see a way out, other than if someone really wants to avoid these types of attacks, then using a VPN is the best bet here.