Data Laundering is an old term... I was using in more than a decade ago in talks about how unethically gathered private data was being sold to Israeli companies, who then licensed it back to US corporations. It was (probably still is) a way to side step privacy laws.
Excellent article and the methods described are accurate. I was speaking extensively about this from 2017-2020 and the usual reaction when I talked about this was disbelief. I was not surprised when In-Q-Tel came calling. I pitched them a military grade privacy protocol but my suspicion was that they were more interested in spying on our users (a non-starter).
I don't have benchmarks but I built a protocol that QUIC later turned out to be eerily similar to. It was a direct replacement for TCP and we used it to provide an additional layer of encryption for all traffic on a given network between two points.
Latency was exceptionally improved. Web pages felt like the loaded faster and at the very least, users could not tell that they were using an encrypted connection.
The protocol essentially worked using a fast-ACK protocol that would preemptively request retransmits (and was occasionally wrong). This enabled it to use connectionless UDP protocol as the underlying transport mechanism. There is, of course, a cost for reduced latency. That cost was slightly higher bandwidth utilization on the network. This was suboptimal for long-lived streams (media and other downloads) so we tried to fault over to ordinary TCP in these instances.
What's funny is that I was once extremely optimistic about the potential for such a device, to the extent of having sold and delivered a few million in product.
Hard experience taught us that churn is just crazy high, no matter how compatible it easy to use you make it. Getting tens of thousands of stars is not the hard part because it's such an easy concept to like. But I would be surprised there are more than let's say ten thousand piholes in active use.
Sadly for the AdGuard team, there isn't much of an audience for this. It's one of those things everyone says they want but few people will actually install one, much less maintain one over time. Add to that the wife-forced uninstalls and the total long-term audience for this is (no kidding) in the thousands.
Sorry, but this is a terrible idea that is going to stifle innovation and make it much harder for startups and small companies to compete. The government simply doesn't need to get involved in this. There is already an incredibly robust ecosystem already in place which shames manufacturers who drop the ball when it comes to security.
More government is rarely the answer and especially so in this case.
Ah, Go. I wrote a whole networking stack in it a few years back. I admit, I did get an incredible amount of performance from a very limited bit of hardware with it. However, it was dependency and module hell. Even the Go expert couldn't get it figured out enough to make it compile every time.
Exactly. I was referring to that bit at the end of the article:
"In the case of Java volatiles, part of the solution is to force all reads/writes to bypass the local registers, and immediately trigger cache reads/writes instead. As soon as the data is read/written to the L1 cache, the hardware-coherency protocol takes over and provides guaranteed coherency across all global threads. Thus ensuring that if multiple threads are reading/writing to the same variable, they are all kept in sync with one another. And this is how you can achieve inter-thread coordination in as little as 1ns."