On Wed, Jul 26, 2017 at 6:53 PM <mike.m...@gmx.net> wrote: > > The need for a secret code to identify approved software was mentioned. > Secret or not, why is it against OpenSource ideals when HMRC wants to > assure that only software with the right capabilities can be used? >
One of the ideals of FOSS is that anyone should have the ability to examine and modify FOSS software to meet their own needs. This means that it is impossible within the FOSS ideals to prevent a user from making changes to software they receive, and it is difficult, if not impossible, to embed a "secret" into the software. If the AuthID/API key is used to identify the company/user using the MTD API, then there isn't a problem; it's basically an installation-specific password and will be different for each taxpayer. The problem comes when HMRC wants to use a secret key to identify the software using their API, and expects software vendors to apply for the API key, distribute that API key to all their endusers, and expect the keys to be secret. When anyone can download GnuCash from GitHub and build it from source themselves, keeping that key secret just isn't possible in practice. Software is constantly being updated and modified -- both FOSS and commercial -- so realistically the best that HMRC can do is to certify specific versions and distributions of any software program. It may be the case that someone is willing to get a particular version of GnuCash certified, but they won't be able to do it in a way that would allow a secret key to remain secret. What they can do is say "The version of GnuCash distributed on this site, with MD5 hash xxxxx is certified by HMRC", and that certification won't hold for any other version. Personally, I think relying on certification and secret keys to discourage malfeasors is a bad idea. If the protocol allows people to do bad things, then the bad guys will reverse-engineer the protocol, wiretap the connections between their "legit" copies of Quicken or whatever to capture the secret key, and Bob's your uncle. Rather, as with anything, the onus is on the registered taxpayer to send good information. The HMRC servers and protocols should be robust to attack, and software which implements the protocol shouldn't be required to identify itself except in an advisory capacity. In which case, GnuCash, if it should choose to support it, could implement the protocol, but explicitly make no warrantees about being "certified" or suitable for purpose. Since already GnuCash does not warrant itself as being correct for tax purposes in any jurisdiction (after all, anyone can use it incorrectly), it wouldn't be a change of policy. GnuCash does not currently (to my knowledge) support any jurisdiction-specify tax policy or reporting requirements. To do so for one would imply that it should do so for all, and that is a maintenance nightmare. As such, I think it more likely that someone would write a program that can take reports or data that GnuCash can already generate (CSV exports? OFX exports?) and uploads the necessary info to HMRC. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.