Hacker News Reader

Comment by scandox | Hacker News Reader

> SOURCE CODE > Sorry, but I do not release the source code for any of my software. This is particularly true for the Cash Register program.

> The Cash Register program. has many things that must be hidden like the passwords and PIN numbers. It also has things that users must not be able to change like sales and tax amounts and transaction numbers. These things could easily be changed by anyone who has the source code and anyone with the source code could write a program that would change the hidden things and then release it on the internet making my program useless.

It's all in FAQ. I don't really get the whole thing about the PINs/Passwords, but I'm guessing there's some logic in it.

The funny thing is he explicitly explains to people how to modify the binary with a Hex Editor to change language strings...

View on HN

I'm a bit of a computer history buff, and dig around through old software archives from time to time. It seems to me that developers back in the 80's (at least in the PC / home computer world) were quite possessive of their source code, even for hobbyist projects that they gave away for free. It might seem a little odd to us today, although perhaps they had some rational motivation (e.g. hopes of productizing it or selling the IP later). So I'm not surprised that this program is also closed source, with some vague integrity/security reasons offered.

I say this with all due respect to the developer, who of course is free to distribute his software however he would like. It's a very cool project, and I often wish we could see a resurgence of such simplicity and distraction-free UX. :)

FWIW there are a lot of closed source freeware programs out there, especially on the Windows world. Irfanview is a very popular example. Another, not as popular in general, though quite popular in HN, is the utilities by NirSoft.

> It seems to me that developers back in the 80's (at least in the PC / home computer world) were quite possessive... even for hobbyist projects that they gave away for free.

Yup, this is one of those things where the free software movement managed to be surprisingly influential, even before open source proper was a thing. People who were committed to releasing freeware stuff, with no delusions about ever selling it commercially (even as indie "shareware") started making their source code available and using free software licenses, often "share alike"/"copyleft" ones. Even Linux itself went down that very path, in fact.

Well, that sounds a bit like "security by obscurity". That ain't good.

This isn't meant for a highly secure organization. This is meant for a mom and pop shop with limited inventory and limited employees. Most of his target audience are very very small businesses, trying to save a buck on POS software. From his website:

    26,000 ITEM LIMIT
    You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunately there is limited memory in DOS software to do this. The theoretical maximum would be 32,000 items but since some memory must also be used for other purposes the program becomes unstable with more than 26,000 items.

    The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 26,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.

26,000 ITEM LIMIT

You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunately there is limited memory in DOS software to do this. The theoretical maximum would be 32,000 items but since some memory must also be used for other purposes the program becomes unstable with more than 26,000 items.

The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 26,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.

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.

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.

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).

Thanks for the digging. I would steer clear of this project. I expect there to be opensource alternatives that score better on openess.

Reply on news.ycombinator.com