Locking transactions

[Mike or Penny Novack]

>It is not easy to make balanced changes to previous transaction details
>in such systems without trace as long as previous periods are locked in
>the user interface. That is why authorities (in probably all countries)
>trust them. 
>
>Of course programmers can go into the database (or xml file), but to
>make such changes balanced and without affecting current period, would
>be quite hard. One could not claim that such changes was unintentional,
>either.
>  
>
Overestimating the difficulty. You need to consider NOT just 
"programmers going into the database" to make changes but ordinary users 
going in using "version Q" of the application (a special version some 
programmer has made for them that allows overriding the read only 
feature). That requires only one rogue programmer for a whole bunch of 
cheating end users.

I understand what you are saying about the single file. But the burning 
(and then sequestering) of copies of this file post closing does provide 
a means of guaranteeing no changes after. A "compare all transactions up 
to date X and report on any differences" is a simply routine.

>The best solution, as I see it now, would be a "Set Read Only" menu item
>separate from "Close Book". The input dialog will only ask for a date.
>Then the users can turn transactions read only before the given date as
>often as they need and want to, every day if they wish. I would do it
>once a year after last year's accounts are finalized, have come back
>from the auditor, and ready to be sent off to the tax authority. Then I
>would set everything before Dec 31 as read only. (In the mean time, I
>would have continued with the new year's transactions, in the same
>file).  
>
>Birger    
>  
>
That doesn't guarantee no changes. The user who wants to reserve 
cheating capability simply makes a copy (backup) of the file immediately 
before setting that read only date. If they decide to make changes, make 
them in this copy and do some renames. No programmers involved.

I always took a very dim view of "protection by ignorance". The fact 
that 99% of end users too ignorant of the possibilities does not make 
for any protection. Those who wish to do what they shouldn't, will make 
it their business to learn how to get around. That being said, I 
remember only too well that it took me two years to get users disallowed 
to BLP tape labels in the shop where I used to work (two years after I 
showed the tech support folks that I could bypass security on tapes by 
bypassing label processing and thus not have the system notice that the 
"actual tape volume" I was ordering mounted had a different name than 
the name I said it had --- I ask for a name to which I have security 
rights, but specify a volume with a name I'm not allowed to access, but 
BLP so the system doesn't notice the discrepancy). The initial response 
being "But Mike, we're no worried about YOU. Who else could figure that 
out?" (my point being "whoever wanted to break security would read the 
manuals too").

So what I am saying here is that "application locking" provides only a 
FALSE security. If we need our system to be able to provide proof "not 
modified" then we need to provide a mechanism that actually does that, 
not one that "does that as long as the user doesn't want to get around 
it". We are at a slight disadvantage. Perhaps the "proprietary software" 
folks are able to argue "users have to use our one and only version of 
the application" and so locking of the sort proposed adequate in their 
case. I'm saying that in our "open software" situation we have to assume 
that an alternative version of the program that would allow end users to 
easily bypass this lock could exist.

Michael D Novack