Was there ever a case of a spreadsheet application introducing intentional floating-point errors when it detected that it had been pirated? Particularly errors that were small enough to go unnoticed until multiple calculation steps made them add up?
For some reason I thought that there was but I can't find anything about it now.
Although I've only seen such things in games rather than in professional software, the same principle could apply to both: if the program is not altered, it will either behave correctly or refuse to run at all, but attempts to alter the program to bypass the protection will cause other parts of the program to occasionally malfunction in possibly-subtle ways. If one uses a compiler and linker that can treat values of the form someConstant+(uintptr_t)&someObject as link-time-resolvable constants, one can arrange things so that the parts of the code that use easy-to-find copies of addresses will automatically be kept synchronized with "hidden" ones every time the program is linked, but someone who tries to patch the machine code would cause the copies to get out of sync.
Even here, I would think going for subtle behavioral variations would be a bad idea, because people might equate flakiness of a pirated version of the code with flakiness of the original. On the other hand, it may be good to write such code in such a way that it will often work for awhile, but occasionally fail with a report that it has been tampered with, using code written in such a way that someone encountering the message would have a hard time finding the code that produced it.
Perhaps you're remembering "copyright trap": small and inconsequential errors acting as a fingerprint. A product with the same errors must have been copied; if there's no licence, some kind of infringement. I have heard of software with this kind of thing, but don't know of any spreadsheet software. Also some map copyright cases.
Related idea is that of "calculator forensics", from a researcher trying to find similarities in the exact behaviour of various calculators, specifically tabulating the result of calculating asin(acos(atan(tan(cos(sin(9)))))) in degrees. https://www.rskey.org/~mwsebastian/miscprj/algorithm.htm
MOV AX,BX you can either encode the instruction as "from AX to BX" or "from BX to AX"); the assembler picks the form to use based on an algorithm that leaves a fingerprint behind, the idea being that the author could use it to identify unlicensed commercial use.
– Jules
Dec 6 '18 at 0:58
from AX to BX and from BX to AX. I think you may have meant from AX to BX and to BX from AX.
– user6464
Dec 6 '18 at 2:31
In the 80s-90s, nobody would design anything that would bugger their own software, copy protection was physical, remember, telephone support only nothing online! However, it would not be unusual if you discovered that after you saved your data it mysteriously started to get the odd auditing error here and there causing huge frustration. Before virus's etc software sometimes incorporated what we called TSJ or TSV 'Target Specific Trojan', these would tamper with your competitors data not in an obvious or dramatic way but in a very subtle impossible to realise what is going on type of way, the attack was not random but highly targeted to mimic bugs (such as items in an order being lost, an auditing Z-read to not balance with itself etc). The clever bit is quite often the Trojan was incorporated into the copy protection sector itself so continued doing its job even after all the software was erased! This was not software written by a self taught hacker in Mumbai, these were developed by highly skilled systems programmers with years of experience and in those days highly detailed specialist hardware knowledge! I always thought it was amusing that it took about 10-15 years before virus scanners got clever enough to report 'suspicious activity', by then everybody had moved on and the wars and battles long forgotten!
