Epoch time isn’t actually the same on all systems. All systems follow the same format, but not at the exact same value hence it’s possible to track individual users with it.
I’ve re-read the discussion that lead to #6579 and I agree we should do this.
It would re-enable the “Round-Trip Time Measurement” TCP feature, which back then we thought was not needed in Tails because "the limiting factor for transmission speed is rarely the capacity of the user connection. In retrospect, I think this argument is quite weak: plenty of people on this planet have poor Internet connections that will be the limiting factor.
but Linux seems to prevent that by using a random offset.
Please keep in mind that anonymity, the way it’s a concern in projects like Tor or Whonix, has not been and is not a concern for Linux kernel developers. You should be generally very careful when you interpret a patch or a code change as something that reinforces anonymity of the operating system because it’s usually not the case.
That said, lets take another look at the aforementioned patch:
Re-use of ISN generator also means timestamps are still monotonically
increasing for same connection quadruple, i.e. PAWS will still work.
Adding a per-connection/per-socket offset won’t resolve the issue as we see it. Such a random number will make timestamps in different connections look probably very different but they still monotonically increase by including a timer value and hence they are related to each other within a single connection. And if this is what happens (which most probably is) it means that, whatever causes the timers of the system to count a little faster or slower - like CPU load - can be visible in the sequence of timestamps in one connection. Further, experience has shown, exposing any unnecessary piece of information about the internals of your environment - like a timestamp- can make tracking simpler.
A lot of TCP features have been added for improving efficiency and when it comes to using systems like Whonix and Tor network, users should first agree about losing the luxury of high speed internet before using these systems.
For this specific case, I can’t confidently say that enabling timestamps can be good or bad without reading the code to see how it’s been implemented and how it works exactly but I’m almost sure, based on their description and a quick look at their variables and the places they’re accessed (which can be a little different in newer versions), the random offset will not make changes in the oscillator frequency invisible in the timestamps. So the problem should still persist and I don’t recommend enabling TCP timestamps.