whatiswrongwithyou

here’s a fifteen year old stack overflow thread where someone asks where a unique system identifier can be read and someone suggests machine-id.

Lest that be considered old and bad information, I just checked /etc/machine-id on a new install of Debian 13 and the permissions were 444, readable by owner, group and everyone else.

So programs can read machine-id. If programs can read it they can transmit it. I hope someone capable of writing a program that can id my machine doesn’t need a proof of that.

Further, programs reading machine-id don’t necessarily fall into the spyware category by default like you say. There are plenty of perfectly good reasons to request a machine specific identifier.

Getting rid of the literal “papers please!” “Okay officer!” File literally makes investigation more difficult and puts a barrier up to tracking where there was none before. Presenting a unique hashed output based on the systems machine-id prevents a tracking method that is currently as easy as read file -> get identifier.

The fact that other methods of tracking exist doesn’t make preventing this method not worthwhile and you should be ashamed for suggesting that.

Machine-id is read as plaintext by programs and transmitted as plaintext by programs.

Hashing the unique id from the host side as opposed to trusting programs to read it and act in a way the user understands and deems appropriate is a much better method of handling calls to identify the equipment than just letting programs read your standardized unique id.

And the above would literally solve something, it would keep programs from just walking directly across the mat tee posing to get a unique id and force them to do some kind of jetpack backflip routine that, when presented to a court, is much more tenuous.

What you said was that if a person was actually worried about it there is a kernel parameter to change it.

My reply was not intended to refute what you said but instead to illustrate how that approach doesn’t solve the problem of tracking and is not a workable solution for many systems and users.

I made that reply to help you and any reader understand the depth and breadth of the problem, not to start a fight.

There is not a parameter to automatically change it every time the system boots, that solution doesn’t work for machines that don’t reboot often and it breaks stuff in systemd as volunteered by many people talking about it online and as verified by me two weeks ago when I tried that.

Yes as I said it’s working as intended. The point of machine id is to id a machine.

A better solution would be to not rely on the various programs to hash the unique id and instead have the host read it, hash it and provide the hash to the program that asked.

Another user said they think machine-id is readable by the browser. This is absolutely true, machine-id is working as described when it is read by any web browser.

So Linux isn’t sending your unique id to a central entity that can associate it with your ip, it’s sending your unique id to any entity you browse to that can then associate it with your ip.

A datacenter on land that relies on water for cooling is using fresh water. Aside from the insane and undesirable use of fossil water or groundwater, fresh water has a much higher ratio of surface area exposed to air and volume than the ocean does.

That ratio is important because you can only evaporate off the surface, so the same volume of water would evaporate faster in a frying pan than it would in a saucepan given the same conditions.

Freshwater is also smaller than the ocean by many orders of magnitude. That’s important because a smaller body of water will heat up more than a larger one given the same conditions.

Freshwater is also generally speaking moving towards the ocean somehow in a complex process called the water cycle. It might flow down a hill into the ocean, it might drip through aquifers to the ocean and it might evaporate and fall as rain either in the ocean or somewhere else where it takes some other path towards sea level.

That last part is important because in America rivers like the ones in Colorado and California have been reduced in volume so much due to of a bunch of manmade events and earthworks that they now lose a higher portion of their volume to evaporation as opposed to flow. That’s a big deal because the Colorado for example flows south but water vapor that comes off of it is blown east. So now much more of the rivers water is going into the desert as opposed to reaching the ocean. The water cycle has been disrupted.

Freshwater is also comparatively super rare and necessary for life on land.

So if you were water cooling a datacenter it would be better to use the huge ocean with much lower surface area to volume ratio and much more volume than to use the rare freshwater that will get heated up much more by the same energy, evaporate faster, we already know can have its water cycle disrupted and all life on land relies on.

Now a person might ask “what about the sea life, doesn’t it matter?” Of course sea life matters, but the way that sea life handles an increase in temperature that’s localized to one specific area is to just go away from there, like it does when undersea magma vents pop up. When the freshwater gets too hot it all evaporates away, there’s no water and the land animals die.

A person might say: “well don’t animals die when the oceans get hot too?” And they’re right! An average increase of .5 degrees c in sea surface temperatures would lead to massive coral bleaching. But enough energy to raise the sea surface temperatures .5c is phenomenally huge. Like getting more sun huge. Because that’s what’s raising it, getting more sun. Datacenters produce so little heat energy in comparison to that level of power that it’s not a concern.

My intent was to provide an explanation for why someone might consider your reply about Chinese manufactured ram being a supply chain risk to be inaccurate.

To be 100% clear as a bell: ram is not a supply chain vector people need to be worried about.

Ram would be a really hard component to supply chain attack. It doesn’t store anything when powered off, so you’d need another chip on the board that can store your attack and that’d stick out like a sore thumb.

It also requires incredibly low latency, so low that trace lengths need to be optimized in order to deliver data accurately. So stream manipulation is out the window.

You’re left with searching through the contents looking for something juicy and that requires some kind of extra sore thumb chip that can’t go fast because it doesn’t have a heatsink.

Plus it’s been standard practice to harden the memory of libraries and programs and even operating systems to avoid stuff like the old Intel hyper threading attacks for at least fifteen years now, so there’s a reduced attack surface.

No one’s supply chain attacking your ram.

Hang on, I’m gonna add a suspicious new component onto a part that is incredibly expensive and heavily scrutinized specifically for speed and latency that will bit bash the I/o.

You add a piece of code (to ram, which famously does not hold information while unpowered).

Which scans for a specific very big prime number (finding large primes quickly would completely invalidate the world’s cryptography and therefore banking, that’s why people are afraid of the quantum boogeyman).

You look for any process and inject into stdlibc any backdoor of your choice (just any process, doesn’t need elevated permissions, assuming they use libc, assuming the backdoor hasn’t been patched out from the other end, defeated by any of the dozens of software integrity checks that have become standard).