My addition would be to pre-calculate a checksum for the encrypted blob, and only send the decryption key after receiving the checksum from the downloader.
You would then have a clear audit history showing that the user had downloaded the file completely, though you still have the possibility that they would claim the encryption key wasn't sent, or similar.
I also wonder what the impact of (presumably) having to encrypt the file for each downloader individually.
Always assign random identifiers.
In my country bills must have an auto incremented bill number. You cannot issue bill #100 without having 99 bills before.
I know one auditing firm that used those ids to spot fraud: some managers started their own firm and started giving contracts to that firm.
The auditors spotted something was going on because the bills have a very low number, and they incremented by 1 or 2 every month - a sign I am your only customer.
I assume it makes it harder to hide invoices during an audit.
Translation: "a sequential number."
Exceptions are explicitly and exhaustively listed here: https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/... , e.g. the requirements for <€100 are relaxed and don't include the number. Note also that this is not for B2C receipts; this is for B2B invoices.
I'll admit the Dutch IRS site is lacking in info. I remember this information from reading the IRS handbook (ugh) back when I was a sole trader there, and extensive conversations with my accountant on the matter.
However, I would bet good money that a separate invoice category per client is not OK. Very interested to be proven wrong.
It's not bullet proof, but it does help auditors.
I then spent a couple weeks writing code that would allow me to query those files for records with specific IDs and cross-reference those IDs with information on other files.
You know, just like a database does. Only slower, probably buggier, and with no real ACID compliance. Whoever came after me must have thought that I was an idiot.
Reason? One of the directors wanted to be able to install this web app on his laptap, but it already had to much crap on there, and he didn't want to install a database. So we had to use files. No, this web app was going to be installed on a proper web server. He just might want it on his laptop too. You know, just in case.
Weird thing was, later we had to do various indexing stuff .... so we just put a database in. The files were still the source of truth, the database was more like a caching layer.
I'll keep your comment in mind for the next time one of those threads titled "what would you tell your past self?" pops up.
Customer replies "Your salesman said we only needed 2400 baud modems" - and buys EXTERNAL 2400 baud modems to save £5 per modem. (Different budget to the phone line you see).
Of course now you had to rely on the retail staff to have left the modem plugged in and turned on. (Which they often didn't).
And the transmission time increased so much that we had to build in additional compression (and complexity) to try and ensure it finished in time.
Why employ technical experts if you're just going to ignore them?
> An early showdown came over employee badge numbers. Scott assigned #1 to Wozniak and #2 to Jobs. Not surprisingly, Jobs demanded to be #1. “I wouldn’t let him have it, because that would stoke his ego even more,” said Scott. Jobs threw a tantrum, even cried. Finally, he proposed a solution. He would have badge #0. Scott relented, at least for the purpose of the badge, but the Bank of America required a positive integer for its payroll system and Jobs’s remained #2.
(From Steve Jobs.)
Crying over a badge number? Doesn't it reveal a deeply troubled personality?
Or am I just too naive and Jobs actually understood the importance of being first?
I remember we had a school headmaster who did a great job in taking the school in a new direction, but he was a sexist, choleric maniac with little self control and a lot of irrational behaviour. These thinga don’t necessarily exclude each other
When you're an asshole it doesn't matter if you're right or wrong, because people don't want to give you the satisfaction of admitting you're right.
From the customers perspective, the only real difference when it came to reading the billing information they received was that federal agencies received a bill that said 'federal' and others received a bill that said 'non-federal'. No big deal, right? Well, not to most agencies. But the US government works pretty closely with, and extends government-style permissions to, various native American tribal authorities. Native American tribes... do not like to be considered to be part of the US government. At all.
It's entirely understandable, but we had to make a bunch of modifications because they wanted to retain the ability to run 'federal agency' style transactions, but wanted their bills to say 'non-federal'. It actually caused quite a lot of drama, but most of it was isolated to the political side of the agency (software changes are not free, after all, so they tried to be diplomatic and begged the tribes lodging the complaint to just ignore the word 'federal' on the monthly bills they received, but they would not budge and demanded it be changed ASAP) luckily. As software lead on the project I did get to hear about some of the firestorm secondhand when working with management to figure out exactly how we were going to change things. The 'federal' designation was a boolean in the database, used both by us in the billing system to determined what kind of processing to do (it impacted amount charged too, with federal customers getting a small discount) and the frontend of the system to kick out attempts to use transaction types not supported for non-federal agencies. So they couldn't just flip the bit and make them non-federal or it would cause even more chaos. It's been a long time ago now, but I believe we ended up special-casing it so that the report templates for the non-federal bills were applied in cases where the agencies were on a hard-coded list of 'federal but non-federal' agencies. All over text maybe 2 people even ever saw.
In the original design of the database, they though it would be a great idea to use negative ID for system use (on the same tables that are being used for user data). No foreign key whatsoever.
Forward 2018 when we have to build a system that have to work with this widedly used database (it's for a french ERP).
Because there is no index or foreign keys the queries are really slow which make our interface slow. Because the tables are accessible but belong to the ERP we cannot modify them because the ERP is under a licence so we don't have access to remodeling of the tables or how the data is processed before being saved in the database.
So to work around the problem we had to create duplicates of the tables with proper index and foreign keys and start a cron job every minute to read from the original tables and fill the datas into our tables ...
Mind boggling .. The software is being sold to a lot of companies which is kind of sad.
There is a lot of topics discussing the use of negative ID when the ID store the same datas all the way from negative to positive.
But storing unrelated datas - data reserved to the system for the developper - on the negative IDs of table ... to "save space" ?
That for me is bad database design and a problem.
Of course it affects price and development speed which may in the long run sink the company in the marketplace, like what happend to e.g. QuarkXPress.
We told him NO - though we could have done it I suppose, the billing system capable of incredible granularity - unlike BUCK$ eh Vint
Fortunately I had a computer history background and realized I was getting a perfectly sensible response...in EBCDIC.
It wasn't binary, but it was fixed length fields, which were surprising common in those days.
The developer saw no issue with making people enter UUID's to search for badges.
Then once word got out that you were willing to modify this system to suit one customer’s ego, it would be open season for everyone to make ridiculous requests (“we really like 69. Can we be 69?”)