Posts by Doctor Syntax 42402 publicly visible posts • joined 16 Jun 2014
Hospitals in Germany mostly belong to large chains that are profit driven. If they can shave a Euro from the budget by buying cheaper mice, they will.
But if a security-measure costs money to implement and isn't obviously required by law, they'll just skip it "because we've been good so far, right?".
I assume they have insurance. The insurers should look at what they're on the hook for with badly protected systems and make sure protecting the systems is cheaper than paying the premium. If people will only do things right if it costs them less up-front then make it more expensive up-front to not do things right.
"Medical equipment is also certified, which means it can't get OS patches until they have been certified by the equipment manufacturer, which can take an age."
Let's deal with that one straight away. No commitment to prompt certification of OS patches, no certification for your potentially lucrative piece of medical kit. And all source code must be documented and escrowed - perhaps along with a dowry to enable someone to take it over if you decide to duck out.
"if the diversion is an hour away emergency patients should be seen and paperwork can be sorted out down the line."
Wouldn't it be great if there was a technology that would let you scan in paper-work, transmit it over an ordinary telephone line and print it out at the other end. Might not have helped in this case but as a fall-back it would be worth having.
Unix windowing goes back at least to 1984 with X. The X protocol reached the current version, 11, in 1987. I'm not sure W95 was eve a gleam in Bill Gates eye in 1987. It was also possible view X with a dedicated X-terminal although I'm not sure if anyone still makes those. I'd hazard a guess that all early development of CT systems was done on Unix graphics.
If you really think Linux and other Unix and Unix-like systems are restricted to characters you really need to get out more.
I've done work for a company where production, handling lots of PII was kept well separate from the office system and its vulnerabilities. It was, in fact, a condition of some of their contracts. It might be inconvenient in some ways but it would have been a lot more inconvenient to admit to their clients that they'd been breached or to have production stopped for days because some toe-rag had encrypted their systems.
The germ of the solution is in your cutting machine story. The owners were able to force an admittedly not very satisfactory solution. For medical equipment there , in principle, an easier way to do this and do it better. A couple of decades or more back it wasn't unusual for servers to have remote support via dial in lines which could be unplugged when not required. Medical equipment has to be certified. A certification requirement of remote support via a disconnectable channel would cut out one weakness. The politics of getting such a requirement in place, however ....
"Possibly one reason that email signing and encryption never really took off, despite being more or less standard product since the '90s."
Two reasons, I think.
One was because it wasn't part of the email protocol so it had to be a lot of added on bits, not just to the clients but a whole added on separate key distribution system.
The second was that because of one very few people used it. If you didn't know anybody who used it you didn't need to go to all that trouble to add it yourself and you not using it meant that people emailing you didn't need to use it and because they didn't you didn't either. Critical mass hasn't been achieved.
"Ultimately to prove identity is to meet each other face to face and exchange public keys, then sign them. At a key signing party. Unfortunately that is a barrier but that is the ONLY way to confirm beyond a doubt that it is YOU behind that address and if you do key signing correctly, behind ANY address and ANY key you sign."
Who's YOU? Even face to face you have to take somebody's word for who they say they are. If somebody tells you they're fred@example.com how are you to know that that's who they really are? A better way would be to have example.com's mail server tell you that fred@example.com's public key is. You still don't know whether fred@example.com is Fred Bloggs, Fred Flinstone, Frederick the Great or my late uncle Fred of course.
An occasional client had offices on Banbury and Swindon both running SCO on tower servers.
On-site work was on Saturday mornings when the business wasn't running. I drove down to Banbury and he picked up the Swindon server and brought it to Banbury. No faffing about with tapes.
In relation to another of today's stories, he used fax to take orders. Online support was by means of him disconnection the fax and plugging a modem into his fax line and me dialling that on a Nokia Communicator.
You think not?
The SCCs have been sunk as a means of stopping the Privacy Figleaf from shrivelling completely. With that and the playbook already written it's the next obvious step for the EU. Apart from that, India seems keen on having its own offerings. And, of course, China.
I suppose for the UK trying to pull such a deal would get in they way of the much sought after trade deal although touting the UK as the best place in the world to run such a service might appeal to BoJo.
"This trove of information puts a target on the back of every good-sized school, college, or university."
Just an idea but how about putting that trove on its own isolated network? Yes, inconvenient when somebody has to answer a query that came in by email. But look on it as a choice of that inconvenience vs the inconvenience of an attack on that trove and at best having to rebuild it from backups and at worst seeing it copied off and sold to the highest bidder - or all bidders.
“measures blocking or slowing down traffic are based not on objectively different technical quality of service requirements for specific categories of traffic, but on commercial considerations, those measures must in themselves be regarded as incompatible with Article 3(3).”
That's traffic shaping dealt with then. Good. Oh, we in the UK don't benefit, of course. We've TBC so the ISPs can do as they like.
"For the record, I think that it absolutely should be an obligation that all products are long lived, easily repairable (by third parties) and recyclable (by third parties)."
If those criteria could be made objective then there could be penalties such as substantially higher VAT or environmental surcharges for badly performing products.
Add to those complaints the assumption that every address belongs to a city and customer address formats are structured that way. There's even less excuse when genealogical S/W is written that way to the exclusion of fields that would be more relevant such as townships in England and townlands in Ireland.
And while we're on the subject of addresses I'll add the online ordering S/W of a German car parts site that couldn't cope with the notion that some addresses don't have a street number. I don't know if it's coincidence but ever since that mess hit them one particular courier had been unable to deliver anything here.
If the ISO standard is being followed anyone who mis-interprets it has only themselves to blame. The significance of ISO dates is that (a) they collate properly and (b) they are natural language independent.
If I'm writing up genealogical or historical stuff I do, in fact, use something like 15 Sep 2020. It doesn't have to be collated and the whole text is in English so language dependency of the data is a minor issue.
Dates as data are an entirely different kettle of snakes.
My database engine of choice is Informix which, internally, stores dates numerically where 1 is the first day of the last year of the 19th century (nobody explained it to them) and you can have that converted in a large number of ways depending on language settings and an environment variable. Spreadsheets should work in similar ways and switch representation on demand.
But get into historical dates and if you're lucky all you have to worry about are Julian/Gregorian changeovers and hope that the first part of the year it was written out unambiguously, e.g. 1731/2*.
If you're unlucky you end up with something like: "Friday before the Feast of the Apostles Philip and James in the fifth year of the reign of King Edward" or even worse "the Friday in Pentecost, in the year abovesaid" and hope that some kind editor has done the hard work of translating it all. And if you're really unlucky you find that the kind editor hadn't noticed that a whole year's records were missing so all the dates were mistranslated**.
* I came across the work of an antiquarian who avoided that - I suspect as a deliberate choice - so he recorded a will dated and proved (i.e. testator died between the dates) apparently several months before he was being sent instructions for his part in the latest episode of the Hundred Years War.
** Several hours with an Easter calculator, Googling of saints' days and cal to sort it out.
A good database backup backs up the actual database, not what's on disk. If the database is running there's always stuff in memory that hasn't been flushed to disk yet, at least there is if it's anyway busy. The database S/W should have its own backup process to take care of that.
