No but, Ruby makes it trivial. No decompilations, no assembly, no debuggers necessary. Drop into an irb in a running process, change stuff and get out in seconds
What makes Ruby so irreplaceable? Why struggle to make it something it's not when you could pick an existing statically typed language and build your system?
Also how is Ruby a safe language for financial transactions when an engineer can hijack a running process and change memory without leaving a trace
F# Is a good choice for cloud orchestration. MBrace was doing something similar to this atleast about 5yrs ago.
I've written a ml pipeline entirely in F# with deployment.
My 2p re: Dark
Rather than creating a completely new language, Dark could just provide an API or a framework and use F# as the deployment scripting lang.
F# is succinct and easy to learn and work with for the customers (DevOps). Beats yaml anyday.
Writing a new language that is production ready is no small task.. takes years to get the syntax, stdlibs, and tooling right. By that time cloud computing may evolve into something else entirely..
What you say is that our actions even without explicit names, etc. can be used to identify the actual person. This is kind of missing the point. Because, that sort of reverse lookup can't scale, and in a very large number of cases it won't be. [Edge case: only person in a village or a post code].
By removing the directly identifiable info, the damage done in a breach would be less. Where as now, a single breach contains all the data that could identify a person and every person in that breach, without having to do any/much reverse look up.
Now, the orgs that collect this data does not have a certification standard and verification that they have to obtain before going operational. Even a restaurant kitchen has that.
On that note, I'd say that there should be a severity grading for the data items. Even Eggs have a grading system. Our personal data is a tad more valuable.
I think a third party or minimum number of parties can be included in this trust network for exchange of information.
Where as now (if the data gets public) there's no restriction.
This may not be the status quo of the medical system. But I'm willing to bet it wasn't conceived and put in place when breaches like this could happen frequently and the consequences were damning.
Overhaul of the process is required. Just keep paying the Ransom/Hackers is not the only and meaningful solution.
Medical history has to be only meaningful between doctor and patient. Doctor can keep records under a unique ID which patient is given at the start of sessions and the patient presents it at each session to validate the relationship. In the event of a breach, even when all data is exposed, without tracking the unique ID back to a person (which would be difficult or impossible) the harm is little..
(Imagine reading a story of a person but you don't know who that person is..)
You might say that there would be other person names and places in mentioned in the records and from that network and timeline you may be able to deduce the identity.. but these PII can in turn be depersonalised. And also this is not scalable for widespread damage.
It just need a bit of thinking when designing a system. Frankly any org that ask for PII and doesn't have a well thought out way to store them should be heavily penalised.
That's what the law should do standardised methods of storing sensitive data.
There's no good reason to have personally identifiable information stored in the system. They could easily issue each patient an alphanumeric ID which is not tied to personal information yet uniquely distinguishable..
This is a system design failure to begin with. Design sensitive systems with only minimum required information. The alternative is to have a massive framework to make sure PII hadn't leaked. And then a legal and financial frameworks on top of that..
after all if a leak happens it can't be undone. Damage to the people will be long standing and cascading.
Best is to have a system that have no or minimum PII.