For UK users: Will gnucash get ready for Making Tax, Digital ?

Buddha Buck blaisepascal at gmail.com
Wed Jul 26 20:52:41 EDT 2017


On Wed, Jul 26, 2017 at 6:53 PM <Mike.Minh at 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.


More information about the gnucash-user mailing list