Old tech is haunted
therectangle.substack.com
therectangle.substack.com
Finally, she got tired of our fruitless technology-driven attempts to help her and strung a few cloves of garlic along the tops and sides of her cubicle. Her problems went away, immediately. My boss, the director of IT, and I looked at each other, shrugged, and called it good.
I was like wow you're an idiot who believes in bullshit which might actually kill someone, fuck you. Called in late to work, went to the store, bought limes, cut X's into each of them and DOUBLED THE LIMES she put in the corners of the house.
She left while paying rent for like two months and I had the best time of my life which occurred staying there after.
Now there's her problem. By doing that the spell changed from "kill ex-boyfriend" to "self eviction".
[0] No, of course garlic isn't an energy source. ...At least, not one that we (yet) know how to harness. ;-)
[0] https://encyclopedia.ushmm.org/content/en/article/roma-gypsi...
[1] https://en.wikipedia.org/wiki/History_of_the_Romani_people
But when you feed bad power into a computer, you get glitches, and quite often this 'haunted' equipment is just running in a bad way. For all we know this woman jiggled a wire and everything is fine.
I've been on the other side of this: IT head says we're gonna swap a server out. It has nothing to do with the workload I/we have today so we say sure. Problem is that it's in the same rack as something with a deadline, and jiggling the wires causes a network connection to go down. I've had this happen three times and we've swapped the cables in each case. Because jiggling an ethernet cable should never be sufficient stress to lose connection.
First time the manager threw the cable away on his own. Second one I had to make him give me the cable because 'it could still be good'. Third one started the same argument, then pulled out wire cutters, cut off the ends, handed them to me to shut me up. Bad equipment goes in the garbage, not into a drawer that means 'ticking time bombs'. Since the connectors are usually why a cable is 'bad', I was mollified.
the computer would shut down, reboot, and he would look at them and cheerfully and calmly say "All better now. You can go home."
EDIT: Not sure why I forgot to link this, out of one of my all-time favorite presentations. I give you: The Mechanical Transmogrification of Diodes into Capacitors!
https://c3.ndc.nasa.gov/dashlink/static/media/other/Observed...
> A novice was trying to fix a broken Lisp machine by turning the power off and on.
> Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”
> Knight turned the machine off and on.
> The machine worked.
Even the simplest things are a fiction. Or maybe I should say especially the simplest things are a fiction.
Well, the argument was bad though: whether hard drives are analog is orthogonal to why "secure disk erase tools are so complex and slow".
I see what you meant ("if they were digital you could just tell them to flip to zero and that would be easy and fast").
Sure, but there are many other reasons why secure disk erase tools could be complex and slow even in an imagined all-digital disk (and of course the imaginary digital substrate operations could just be a slow tech, the way RAM is slower than Lx caches, etc.). And while for delete you just need to change some directory entries to mark as none, for "secure erase" you'd also want to "reset" every bit, so at least similar time to the work you do when you write a file of same size.
It's security theater. All you have to do is write 0s to the entire HDD.
No, this is not possible neither in theory nor in practice.
>by taking out the platters and very carefully poring over the ever-so-slight analog-induced discrepancies in what "0" and "1" look like
Even doing this is not enough to recover the data. What 0 and 1 look like isn't even constant. There is variability in what the current value is set to and their is variability in what the previous value was set to. There is too much randomness to recover the original data.
>which largely renders disk erasure a moot point
Disk erasure in this case can still be useful. In this case you only have to overwrite the master key.
The idea that overwritten data can be recovered is an urban legend that is not based off reality, and simply wastes people's time and contributes to ewaste from people destroying harddrives.
For just wiping data overwriting it with anything is fine. If you plan on using the disk for FDE you should overwrite the drive with random bytes so that you don't leak the size of the used disk space.
Then go tell that to Peter Gutmann: https://www.usenix.org/legacy/publications/library/proceedin...
The saving grace here is that newer drives are a lot denser than the ones in common use back then, so data recovery in this fashion is prohibitively expensive for anything manufactured in the last decade or so. You basically need to be more precise in your reads than hard drives themselves - and that's a pretty tall order.
Still, technology does march on; there remains a risk that recovery techniques could catch up, and there are indeed folks who need absolute guarantees of erasure - and there ain't much more absolute than physical destruction.
> What 0 and 1 look like isn't even constant. There is variability in what the current value is set to and their is variability in what the previous value was set to.
It's exactly that variability that makes data recovery possible.
> simply wastes people's time and contributes to ewaste from people destroying harddrives.
It doesn't really do either. Again: this is really only relevant if you're being targeted by the sorts of nation-state-level intelligence agencies that have the time, resources, and expertise for this sort of thing - and when you're such a target, guaranteed data destruction matters a lot more than the amount of e-waste you generate.
> If you plan on using the disk for FDE you should overwrite the drive with random bytes so that you don't leak the size of the used disk space.
This doesn't always work - for example, if you want to use TRIM on SSDs, since unused blocks are zero'd out instead of left as-is. The usual recommendation there for maximum security is "just don't use TRIM", with the SSD performance and longevity implications that entails.
Which is what the authors of "Overwriting Hard Drive Data: The Great Wiping Controversy" did. The highlight of their response is that for the recovery method described in Gutmann's paper to be accurate it requires a copy of the original data. When the authors tested a drive that existed at the time Gutmann wrote that paper in optimal conditions there was only a 92% chance of recovering a bit correctly. The chance to successfully recover exponentially decays with the number of bits you want to recover.
>if you want to use TRIM on SSDs
We were talking about HDDs. SSDs are out of scope.
That's still a non-zero probability. For folks whose tolerance for data exfiltration is "zero", anything non-zero, no matter how infinitesimally small, is non-acceptable - hence: physical destruction rather than relying on overwriting.
Thankfully, as mentioned previously, said folks are a pretty tiny minority of the total hard drive market, and are typically the folks encrypting everything at rest anyway. A random pass or two over encrypted data is more than enough to ensure that even if an attacker is able to accurately recover old bits, there's no telling whether or not those old bits are actually data.
> We were talking about HDDs. SSDs are out of scope.
If we're going to adjust our expectations for "overwriting is sufficient for data destruction" based on changes in technology, then SSDs are absolutely in scope - and indeed have their own set of implications when it comes to data retention after overwrite (like TRIM, as mentioned before, or the general case of two writes to the "same" block not necessarily being written to the exact same set of cells).
Just as there is a nonzero chance of someone recovering your data by reading /dev/urandom. Technically your data could be outputed but the person reading /dev/urandom would not be able to tell if it was just random data or if it was what was wiped.
Even if your tolerance for data exfiltration is 0 you can be okay with a non 0 chance for someone to randomly generate the data.
>If we're going to adjust our expectations for "overwriting is sufficient for data destruction" based on changes in technology, then SSDs are absolutely in scope
The process of wiping SSDs is different because you don't do it by overwriting all of the data, but instead by initiating a secure erase.
That variety of non-zero is much closer to zero than the risk of increasingly-sophisticated equipment being able to recover overwritten data - and unlike the non-zero risk of such an "infinite typewriters" sort of attack, mitigating the non-zero risk of recovering overwritten information from media is straightforward: destroy the media.
> The process of wiping SSDs is different because you don't do it by overwriting all of the data, but instead by initiating a secure erase.
In other words: trusting an opaque blob of SSD firmware to overwrite all of the data for you.
No, it isn't. Reread the paper I referenced. The chance of recover exponentially decays which means the probability does quickly go to zero as the number of bits you want to recover increases.
>trusting an opaque blob of SSD firmware to overwrite all of the data for you.
No, you are trusting them to overwrite the encryption key and that the encryption being used is secure.
I did.
> The chance of recover exponentially decays
As does the chance of a random number generator accidentally recreating your secret.
And that's assuming, again, that technology doesn't improve.
> No, you are trusting them to overwrite the encryption key and that the encryption being used is secure.
1. That's hardly any more reassuring (though at least it does hopefully mitigate overwriting concerns, assuming that key can't be recovered and the encryption method is indeed more secure)
2. That doesn't explain why secure erase commands take so long relative to other ATA commands (anywhere from seconds to hours), or why that time scales with drive size.
https://en.wikipedia.org/wiki/The_Ghost_in_the_Machine
This work has informed quite a bit of art and literature ever since, from the manga/anime series Ghost in the Shell to a fair bit of William Gibson's work (see 'semiotic ghosts' of futures that might-have-been in The Gernsback Continuum).
As far as religious belief in modern civilization, Frank Herbert in Dune (Appendix II) describes what I imagine is the common modern view among the 'power elite':
The agnostic ruling class (including the Guild) for whom religion was a kind of puppet show to amuse the populace and keep it docile, and who believed essentially that all phenomena - even religious phenomena - could be reduced to mechanical explanations.
With respect to as belief, I think anyone who says 'I believe in <insert whatever here>' is actually expressing doubt in their own world view. I'm more impressed by the so-called religious fanatics who instead say, 'I know of <insert whatever here>'. Consider the person who hears the voice of 'invisble sky friends' in their heads and writes it down in an (eventually holy) text - who is to say with certainty whether that's the result of schizophrenia and auditory hallucinations, or an actual interdimensional communication from the architect of this virtual reality simulation we're all (okay, perhaps) living in?
As far as haunted old tech:
"We build our computers the way we build our cities - over time, without a plan, on top of ruins." - Ellen Ullman, Life in Code
Russel's Teapot. Also, Occam's Razor.
(Also, Russell's Teapot is not at all a fair comparison. A vast, incomprehensible, inconceivably simple unitary consciousness as the fundamental substrate of reality is much closer to most religious conceptions of God than is a teapot in orbit.)
(...and, of course, a single entity which underlies reality is ultimately simple. Push it pantheist and you reduce the number of entities to one - no other worldview can reduce the number of entities further.)
The corollary between the teapot and the idea of "god" is that both of them are extraordinary claims and therefore the burden of proof rests on the people trying to argue that they're true. That property remains holds for your first definition of god as well. That doesn't mean it _can't_ be true, but it does imply that it should be held to the same standard as any other unfalsifiable claim.
Of course, the converse is true as well, which I think is the point the article is trying to make; believing in ghosts or hauntings isn't any more incompatible with the worldview of the cold, rational technologist that the article describes than religion is. If believing in ghosts or hauntings makes someone happier, as long as they don't use it as a rationale to harm anyone else, all the more power to them!
Sound a bit like Gibbon on Roman religion:
"The policy of the emperors and the senate, as far as it concerned religion, was happily seconded by the reflections of the enlightened, and by the habits of the superstitious, part of their subjects. The various modes of worship, which prevailed in the Roman world, were all considered by the people, as equally true; by the philosophers, as equally false; and by the magistrate, as equally useful. And thus toleration produced not only mutual indulgence, but even religious concord."
I wouldn't - the majority believes in an invisible sky friend.
I heard the simulation has an issue with recursion, which is why my code has a lot of bugs; I implemented it right, but the simulation has bugs when simulating me running it.
If it happens enough to be annoying, consider setting the T-stat to NOT call for heat and then go moving wires around until you find the place that has the intermittent short.
Because I am working on a Web product which aims to be compatible with every Web server and Web browser in every configuration, I went out of my way to visit historic places, such as the Netscape offices in Mountain View, and Urbana-Champaign campus where Mosaic was developed.
I sat and meditated on their history and the events which happened there. And I feel that my product better as a result.
Constantly tempting me, always whispering in my ear to want more, making me covet what others have.
For your own good.
Either ghosts or the PSP on my AMD processor chatting with spooks.
Confronting and undoing a casually overfit mental model is harder the more subtle and useful they are - but those are the bits that hide the great secrets of the universe!
Hum... That's really not overfitting. In fact, that's the opposite of it, an incomplete model.
Every now and then she likes to remind me of that most of our screens are made out of quartz, and highlights the associated qualities of the crystal.
I can't recall them but I always find it interesting, something about assigning beliefs and extra qualities onto your everyday objects. Some people believe in a white god with long hair in the clouds while others believe in the magical qualities of rocks. I find the diversity of beliefs beautiful.
The entire Internet runs on crystals.
This made me throw up in my mouth and my eyes hurt from all the eye rolls
Belief in spirituality, the supernatural, a higher power all can and do exist independently of any particular religion.
Ghosts in the machine, spirit in the system, hear the whispers, screams are distant.
Test failures that are flaky / sporadic often signal something you really need to look into - either you're not in control of your test's corner cases or your product's. Either way you can't ignore it.
But, sometimes, with the whole "running hundreds of thousands of tests of complex, interacting software on cloud infrastructure that has virtualisation, custom kernels, whatever ..." the answer is just "woooooo spooky". When it comes to customer boxes, it's even weirder ;-)
=== When PTRACE_SINGLESTEP got haunted ===
A few years ago, we saw a particular issue in which the PTRACE_SINGLESTEP operation (which should, you know, step by a single instruction!) would sometimes step two instructions - but it basically only happened in testing.
Eventually we figured out that:
* For a particular older enterprise distro on x86.
* If you tried to single-step a thread in one process.
* And a thread in another process hit a watchpoint at the same time.
* Then your thread would step by two instructions.
Spooky action at a distance. This might also have required you to be running on a virtualized system - it didn't matter to us at that point, since clearly we need to work around issues people may see on cloud infrastructure.
Of course, unless you tested debugger workloads extensively you'd probably never have two processes under debug simultaneously in order to notice this.
=== When transparent hugepages got haunted ===
When RHEL backported support for the Linux kernel's THP optimisation, quite a few years ago, to one of their enterprise kernels a bug also got backported that I'd call "extremely haunted".
THP worked fine, maps would automatically get huge pages where appropriate and would get split up again if necessary.
EXCEPT ... if a THP-ed memory location was:
* Write-protected because of COW memory sharing (e.g. after fork)
* And the page was split by a write
* And that write had come from a PTRACE_POKE operation, not an in-process write.
Then something crazy would go wrong in the system. That process, IIRC, would hang and become unkillable.
Some sort of goblin got into the memory management subsystem at that point and there was no getting it out again - gradually the whole system would start to lock up until it became unusable - eventually requiring the box to be reset. This happened even from an unprivileged process.
Again, this is something most workloads wouldn't see but - once we'd understood the underlying issue - we had to find ways to prevent it happening. You just can't trigger a kernel bug like that, even if you know it's not your fault. If you're always there when it happens, nobody is sympathetic to you!