Case study
CID “started as a database containing basic details about asylum seekers and was initially expected to be an interim solution."
This is what they should teach Comp Sci and MBA students. How IT happens in the real world.
432 publicly visible posts • joined 25 Oct 2007
It's not the app that's the problem. It's the mechanism (or lack of it) for controlling access rights. Who decides who will be a member of the WhatsApp or Signal group? Who decides what each of those members can see or do with the data? There are no mechanisms in place on messaging apps whereby an organisation can maintain control of and audit who accesses what information.
No it hasn't. You're just trying to sound official or technical or something. What has occurred is a fire, not a "fire incident". Just like it's not a "flood event" it's a flood. And when did we move from having a storm to having a "severe weather event"? Anyway, gotta go, I had a curry last night and can feel a catastrophic evacuation event coming on.
For most businesses, planning for quantum computing will I suspect be more of a cybersecurity issue. At some point in the not too distant future it will be economically viable to start brute force decrypting what is currently strongly encrypted data using quantum techniques. Crucially it will be possible to do so within a useful timeframe - for example where the target is still in business / alive in order to blackmail or prosecute them.
Crooks and spooks are right now hoovering up encrypted traffic in anticipation of being able to decrypt it quickly whilst it is still useful to them.
Nobody is giving a date for when quantum computing will be able to deliver this, but it is definitely a case of when, not if, and it could be in the next few years. When it happens it will be sudden, and I imagine catastrophic.
"The situation causes major restrictions in its supply chain operation to the market of some of its products in the different marketing channels" reported ChatGPT in a translation that is barely distinguishable from one that would be made by any 1st year GCSE Portugese language student.
The very term cloud software stems from the cloud symbol used from way back when in network diagrams, originally to depict a large private WAN.
These days, practically nobody runs a private network to every geographic location that needs access to central systems, and that applies whether those central systems are on prem, in colo or on some sort of SaaS or PaaS offering.
The cloud in the diagram now depicts the internet, itself a network of many networks, owned and run by many different organisations, any of whom can mess up the world's routing tables. And let's not even mention the DNS root servers.
Whether you like it or not, you depend utterly on the cloud, wherever your mission critical software is running.
Most small and many medium sized businesses employ service providers for things like accountancy, legal and payroll/HR. They couldn't possibly do it in house, so the problem is identical. You need to find someone you can trust, and until fairly recently Rackspace had a good record. There's nothing to say that the accountancy practice you use won't go bust, or mess up - in fact they often do.
As many have said before, that's all very well if you have an in house IT team and your own geo-redundant hardware infrastructure. Reading various articles about this disaster, most of the hosted Exchange customers are small businesses with 20 or 30 users. They haven't got a cat's chance of running their own mail systems (especially Exchange based). They have no choice but to trust someone else.
We've used Rackspace, amongst others, for dedicated servers and VMs (not email) for a couple of decades and they really were fanatical and technically excellent with their support and services back in the day. Recently we've been steadily reducing what we have with them. The aforementioned job cuts and service centre offshoring have reduced Rackspace to a budget operation of the 1&1 (now Ionos) ilk.
For the average small business, it's very hard to know who to trust with their mission critical stuff. They don't even know what questions to ask of a supplier, let alone what the right answers would be.
Low code in essence is just another level of abstraction from machine code - a very high level language if you like.
The art of programming though is a way of thinking, a mental approach more than a particular language. Ask a business person to define the process or problem they need solving or automating, and inevitably you'll get a vague, poorly specified, ill thought through answer. Your next step is to tease of them what they're actually after, and make them aware of the knock on effects of what they're asking for. It's the classic beginners exercise of writing down how to make a cup of tea. Most non-programmers miss several of the crucial steps.
No matter how high level the language, you still need to think like a programmer to make the machines do useful stuff. Putting amateurs and hobbyists in charge will inevitably lead to a mess of a system and most likely the loss or corruption of valuable data.
Indeed. Why use a database management system when you can frig a piece of software, which wasn't designed to manage data, to try and do the same job in a much more complicated and error prone way that can literally kill people. Think losing thousands of safety critical Covid data records whilst using Excel to share the data.
The NHS is an umbrella for a myriad different organisations and a million odd staff. Some of these are private (think GP practices, dentists and pharmacists for example) and some public (largely emergency, acute care and chronic care). If the NHS stands for one thing it's that for its users healthcare is free at the point of delivery. In this context, delivering a monolithic national software stack is a complete nonsense.
Each organisation in the NHS should be free to choose from best of breed solutions for their particular area of operation. The national framework should aim instead to set standards for data interchange such as xml schemas for patient records plus possibly some kind of middleware service to ease the integration of systems via their APIs. A central data repository for healthcare analytics requires only anonymised data, the aggregation of which can be automated using the aforementioned schema definitions and APIs.
In this way a competitive software ecosystem is established ensuring best value for money for the tax payer, avoiding a supplier monopoly, denying the government another unjustified opportunity of harvesting personally identifiable data and finally denying politicians and civil servants the opportunity of a lucrative non-exec role in the private sector. These are also the reasons why the NHS always fails to get sensible technology solutions.
Presumably the suspended person is the muppet who included the addresses in the cc field.
It should be people at the very to of the MoD who ultimately get suspended. The system is at fault, not an admin clerk. Being able to paste the addresses into the cc field means they were somehow available on a standard email distribution list or most likely an Excel fu**ing spreadsheet. They should be on a secure list server where nobody can see the addresses and where each recipient receives an individual copy of the email, preferrably with the address in bcc, and the sending of which is logged and stamped with the ID of the user who authorised the sending. Nobody, whether within the MoD or outside it should see these addresses on screen.
Or even better, use a secure portal to communicate.
FFS Mailchimp would be a thousand times more secure than what the MoD is doing, apparently routinely.
These twats have put actual lives of actual people, along with their families in grave danger of death or worse. No fine is big enough - a spell in prison should send the right message.
SAP - very funny.
Why not pick best of breed SaaS offerings for each of the functions then integrate. That's one thing SaaS services make very easy, either through custom integrations directly via their APIs or more likely pre-built integrations via the likes of Mulesoft of Zapier. The added advantage is that you're not over the contractual barrel for a decade with a single supplier.
The days of the monolithic ERP are surely over, along with the near business death catastrophes that were so often associated with their implementation.
For years the industry bemoaned the move from in house teams to the big outsourcers. Now, the big outsourcers are getting a taste of their own medicine as they lose work to the big cloud providers. Bitter? Me? Just because my small business lost loads of local work to monolithic national framework contracts with the likes of Capita and Fujitsu? Well, yes actually.
A) Massive cover up to avoid tipping off the Russians that we're on to them.
B) A software upgrade gone wrong.
Drawing on all the experience gained over a long career in IT troubleshooting, on balance, having assessed all the possibilities and even though the client tells me the problem is definitely B, I'd still have to say that the most probable cause is A.
I thought you were joking at first, but suddenly realised you were serious.
No mainstream politician of any persuasion has ever argued with the principle of free at the point of delivery. Ever. Nobody. Where opinions differ is how we might arrive at that point of delivery - and that is a subject for legitimate debate as the current system depends too heavily on the sacrifice, dedication and unpaid overtime of a million odd NHS workers who see the NHS as a vocation, not just a job. If those workers suddenly worked to rule the whole shooting match would collapse. It is an abuse of all of those staff to leave things as they are. Blair/Brown admirably tried chucking vast sums of cash at the existing system but sadly that didn't solve the problem. We need to suspend the ideological dogma and have an open, rational discussion about the options. If we don't we are massively failing patients, NHS staff, and the tax payer.
Efookinxactly! Nail on the head. If this was oil leaking into the ocean, or toxic gas into the air, there would be monumental fines, cleanup charges and possibly criminal charges (think Deepwater Horizon or Exon Valdez). It wouldn't prevent all incidents, but it would change corporate culture enough to reduce the worst excesses. But as it's "just" our identities at stake, nobody gives a toss. It'll be interesting to see whether a South Korean company can be prosecuted under GDPR given the have a large European client base. That would at least show that the law is moving in the right direction.
Monzo provides a great current account service. Opened an account for the sole purpose of a two week train trip with the family through Europe last month because there's no transaction fee or pumped up exchange rate for card payments abroad. Now thinking of switching permanently - it's brilliant. Like someone said transactions, even abroad, ping immediately into the app so you can see whether some dodgy trader has ripped you off while you're still staring them in the face. No more ten day waits until things appear on your account. This is a current account as it should be.
Not too happy about the logging bug, but in the grand scheme of things it's not catastrophic and they've owned up and cleaned up.
The entire holiday was done with booking.com, airbnb, the trainline and heavy use of google maps and translate en route and what could have been a disaster was a triumph. We only pre-booked some of the stuff in advance and did the rest on the fly. We all moan about the cloud on the Reg, but if you just step back and think what's possible now that was either impossible, or at the very least unbearably more complicated, just a few years ago it's pretty amazing really.
OK, so I may have told some Italian waiter that his mother had the face of a pig and he himself was of dubious parenthood, but you know, Google's not perfect - and I probably would have got some instant offline feedback from the waiter.
Crikey, haven't we moved on from this sort of thing yet?
You might as well ask how that IT thing is going for ya? Abacus, slide rule and paper spreadsheets were just so much more reliable. Never had a power outage with those. Or a virus.
Embrace the new, make it work for you and learn valuable lessons from those who fail to make it work for them.
Nobody claimed that the blockchain was part of the crypto currency innovation/invention. As you say, Bitcoin uses pretty much bog standard blockchain theory.
Satoshi Yakamoto's contribution was the idea of proof of work which is the mechanism for minting new coins. The proof of work process is a mathematical guessing game whereby the creation of new blocks in the chain can be made artificially harder as more people become miners (creators of blocks). The aim is to limit the rate of coin production. This is an inherently stupid idea as all it does is increase the demand for computing power and therefore energy.
Blockchain is not new, it was just brought to the world's attention by the prospect of unlimited riches, and in a classic gold rush most people are digging in the wrong place. The only ones who'll make money are those selling the picks, shovels and pumps.
Computer systems within a registry and registrar were infected by tricking employees into opening spear-phishing emails laden with malware from sometime around January 2017, and continuing through the first quarter of 2019.
Really? For two years? In not just registrars but *registries*! Gordon Bennett. We're all doomed.