Hacker News new | past | comments | ask | show | jobs | submit login

That's not the point: A bookkeeping system has to have certain properties in order to be able to make it through a tax audit. For example, once a transaction is entered, there have to be certain guarantees that the transaction can't just be deleted or meddled with afterwards. In the pen-and-paper era this was accomplished using special writing instruments. If your books were kept with a pencil or pen with erasable ink, you'd be in big trouble.

It sounds to me a bit like what the author is saying here is that, if the source code were to get out, then it would become common knowledge how to meddle with the accounting records using a hex editor and that, in turn, would be something that an expert witness in a court of law or a tax auditor would point out to attack the admissibility of the whole system.

But that's kind of bad. If the records can be meddled with in a way that would be known if the source code were to get out, then they can probably also be meddled with without the source code being public knowledge (just harder to figure it out), and that is almost as bad: Security-by-obscurity is probably not a valid defense against that allegation if it were to come up in court.

So, there should really be some crypto there instead.

POS Developer here. What you describe is a so-called fiscalized POS system (at least in Germany we call them this way, not sure if there's a different English term). These must report the transactions in a cryptographically secured way to a fiscal authority. To do this, there are multiple concepts (of which some include hardware security devices, smart cards or non-erasable storage or similar, and some do rely on software-only solutions) and any country mandating the use of such systems finds a slightly different way in which they want it done.

In addition to this mechanism that allows the fiscal authority to check the transactions on a specific POS for manipulation, fiscal requirements also often mandate much more, such as explicitly registering POS systems with the authority using serial numbers or hardware checksums, mandating the use of specific receipt layouts, or some kind of freeze of viable parts of the POS software which can then not be modified after approved once by the state (you can imagine how much love this kind of regulation gets from developers wanting to work under modern, agile principles...).

However, not all countries mandate such things - many still accept POS systems that basically do nothing to prevent anyone from modifying transactions after the fact (although there is definitely a trend to more strict fiscal requirements globally). These non-fiscalized systems can try to make it hard to modify transactions if they want, and many do, but they cannot make this actually impossible without having some kind of external authority in play, which is why any effort of doing so will amount to some more or less elaborate kind of "security by obscurity".

Thanks! That's very informative!

But surely: Even if a system is not specifically aiming to comply with the requirements of any specific jurisdiction, there are cryptographic things that could be done that don't cost much and are always preferable to pure security-by-obscurity. -- Just, whenever you append to the ledger, take a checksum of the ledger, append the checksum, get the checksum timestamped by a secure timestamping server (like DigiStamp or Germany's D-Trust), append the signed timestamp, and reiterate the next time you append.

That way you can guarantee that you can only ever erase the ledger in its entirety, not tamper with any single records, and even when you do erase an entire ledger, there is a record of it, if the timestamping server does that kind of journalling. -- No need to rely on any security by obscurity there.

That seems way more secure, and costs next to nothing. You don't even need to be online all the time, you can just fetch the signatures when online, and work in offline mode when there is no connection. You can even retrofit that ability when your system works with files, by putting the files under version control, and making the version control system do that. (Personally, I have my version control server rigged to do just that, in case I ever need to prove in a court of law the date when a piece of code was written etc).

What you describe is pretty much exactly one of the schemes by which a fiscal authority might ensure non-modifyability. The fiscal authority would take up the part of the timestamping service in a real world implementation of course (no government ever would just let you freely choose a provider for such a service by yourself).

That is what I meant with “every implementation that shall not just be an elaborate security-by-obscurity scheme needs an authority”.

Note that no one will ever pay for anything like that if it is not mandated by some government under which you want to operate a significant number of POS installations. It is already crazy expensive to implement all these different and mind-numbingly clusterfucked schemes that all the countries with fiscal requirements want to have implemented. The one thing no one wants to do is coming up with just one more of these schemes that the countries in which no such thing is required will not care about anyway (lawyers will not be impressed at all by technical explanations why your records are super protected against manipulation - they will still call in the armies of accountants to run the numbers up and check your books).

The moment you enter into hex editing these records is the moment that you are into trouble anyway - assuming the software is trusted in the first place.

In some countries it isn't really the POS that does the bookkeeping, but a special device is used that communicates with tax registry (or something, i'm not 100% sure on this). All the POS software does is tell the device what it was sold, the device registers it with the tax registry and gives back some sort of code string to be printed on the receipt. This also allows the receipt to be any type of paper (as opposed to the special triple-layered paper that was often used back in the day) and even if the device itself is tampered with, the information has already been sent to the tax registry.

I think the author of this POS is mostly using this as an excuse to not release the source code, not for any practical reasons.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact