I'd have thoughts that data quality issues might loom at least as large as ethical. Provenance? Sample selection? Accuracy? Repeatability with independent data?
However, psychology, social sciences, AI - probably no problem.
33118 publicly visible posts • joined 16 Jun 2014
It looks as if a great many in IT in the UK of my son's generation started out on the Spectrum. In my generation it was punched cards. In our grandchildren's generation it's likely to be the Pi but I suspect for many the Pi will be eased out by the smartphone and the laptop. I wonder how that will work out.
No, irrespective of whoever's in charge of the department of culture media. When a government's entire raison d''etre is getting out from under a regulatory regime which seeks to protect citizens' rights none of its party can be trusted with data protection.
"Yes, the controller is not responsible for this, but why should they?"
Let's turn that round. Why shouldn't they be? They are the ones with whom the data subject has a relationship. They are the ones who undertook - or should have done - to handle the data carefully. They have a duty of care. Part of that includes care in their choice of who they entrusted to process the data if they didn't do so themselves. The processor is the controller's agent. The controller should be responsible tor the actions of the agent.
That doesn't let the agent of the hook, of course, and, indeed, they would presumably be liable to the principal for breach of contract, but the data subject should have a very clearly identified body from whom to claim redress.
The problems with the Privacy Figleaf are that the US jurisdiction doesn't give allows the contractual obligations to be overruled. If that were not the case it seems to be accepted that the EU data subject would be able to take action against the processor in the US; that, I think, in unacceptable, the data subject should be able to take action in the jurisdiction where the original transaction occurred and against the other party in that transaction, the data controller.
None of the examples in the article falls into that category. However the concentration of data that the likes of Equifax accumulate could also be regarded in the same way. When a business holding that much data guards it so badly there should be personal penalties for senior management. It might take a few prominent cases of CEOs or board members jailed but not too many. Management needs to be put into thinking along the lines of "This stuff could be dangerous to me ".
There's a fairly straightforward solution. Make re-identification of de-identified data illegal with personal responsibility for some person in senior management. The newspaper editor, the marketing manager or even better, the CEO get a criminal record and go to jail. And for good measure the company loses any govt contracts it may have, forfeiting any outstanding payments for work done.
The only way to deal with excess data is to make it toxic. That will give businesses second thoughts about collecting it in the first place and make them very, very careful about how they use it.
"They could probably do that tomorrow if they wanted to but they are holding off to give time for people to switch to a VoIP alternative."
Unless they can find a way to power VoIP over the line they don't have an alternative. One of the characteristics of the analogue service is that it continues to work when the lights go out. Discovering that the backup battery has died when the lights go out should not be an option.
The advice included how to spot scams – and this belter of a top-tip, which read: "Don't click on any links… if you've received a suspicious message."
Much the same as an email from the bank warning about phishing emails and stuffed full of links to click. The trouble is that half marketing people completely lack the self-awareness to realise that their emails are indistinguishable from the phishing emails they're warning about and the other half probably see nothing wrong in clicking on aany link in any email they receive and sooner or later are going to let ransomware into their company.
A lot of would be exporters into the EU are now discovering the hard way how red tape works. Previously they weren't really exporting, just selling into a part of their home market that happened to have a bit of water in the way. Now they're really trying to export and it's more complicated than they thought, especially when it's some sort of agricultural product.
AFAIK he'd paid for the package. The support contract was being sold on as an extra.
I'm quite used to the situation where a package is sold and a support contract is optional but selling a support contract and trying to lock the customer out if they don't keep paying is taking the piss in my view.
There were some interesting features to the S/W:
- It was supposed to be based on Informix. Some Informix tools were supplied for reporting but it wasn't written in it for reasons which became apparent.
- They included some files with .sql suffixes which were supposed to be the DDL to set up the database. They weren't even SQL although possibly their S/W would read them to add some tables. They didn't comprise the full set.
- They provided a bcheck* program to check the database. The supplied Informix package also provided bcheck. The bchecks were different. Either would complain there were "errors" if the alternative bcheck had been run first. The DB was OK, it was just that the two products were setting a flag or label differently.
- There were the usual Informix system tables which included indexes. It became clear that the system they provided couldn't have run efficiently with just the indexes listed. When I needed extras for reports I was writing I investigated further with bcheck and discovered that there were indeed more indexes, they just hadn't told Informix's sysindexes about them. Clearly they'd set up the database with some other tools and copied in the Informix system catalogs from a rather less fully featured database to keep the Informix tools more or less happy. I hacked sysindexes with SQL to add in some of the missing entries.
I'm pretty sure that what they'd done was use a C-ISAM package** of which there were a few - possibly even a FOSS one - to write the software, marketed it as being based on Informix and sold some Informix tools along with it although they didn't have a chance of working as well as they might. On the whole I think it balanced out as six of one, half a dozen of the other.
I've often wondered if it was the same crowd who flogged a warehousing system to my ex employers about the time I was being eased out. Some time previously we'd proposed adding warehousing to the existing stock and SOP system - it only needed a couple of extra tables to describe the racking an the additional screens to support it. That had been turned down. Some crowd claimed to be offering an Informix-based system running on VMS sold them a free-standing warehouse system. I knew very well that there wasn't Informix on VMS; we'd been one of the guinea pigs when such a thing was attempted and abandoned. They countered that by claiming to have the database source code It must have been the same thing - an application built on a C-ISAM package. At least I was out of it before I had to cope with trying to keep two separate systems giving their views on stock levels.
* bcheck was a diagnostic for the b-tree indexes.
** Informix Standard Engine, even in its pre-SQL version was based on a C-ISAM package of their own (AFAIK) devising.
"Ever found the time and cash demanded by a vendor was vastly more than truly required by the actual change?"
I had a client who managed to do that all on his own.
I did occasional support work for him but the vendor still required a support contract with themselves. To enforce this they had some sort of lock on the system which involved periodically running something - I'm not sure if they logged in remotely, sent him a file to run or just gave him instructions to do it himself. I kept well clear of that. What they didn't do was provide actual updates to the S/W so in that respect they weren't providing anything in particular, just occasional problem solving.
My remit had been a bit wider as general Unix and DB admin stuff. I'd very quickly come to my own view of their S/W and, in fact, one of the things I was doing was writing bits & pieces round it to do stuff the client wanted. Eventually he realised that their support contract was providing him with nothing and he worked out the coding of the lock file that had to be changed every 6 months or so, ended the contract and updated the lock himself.
It's not an erroneous CC, it's a legally binding notice. The fact that it's possible to send out such a notice in this way doesn't make it any less legally binding. If you look at the PDFs they have a facsimile of s signature on them.
It would be well for those permitting their signature to to be used in this way to consider the safeguards they require - perhaps documents should require their personal release. (I've worked on a system that not only send out such "signed" documents. I was a sub contractor to the sub contractor to one of the usual suspects to whom the entire operation had been contracted out. OTOH I don't think the "signed" documents in this case carried the same legal weight.)
They're official notices giving or withholding permission to do things which have large amounts of money depending on them. So much so that there are frequent casual allegations of corruption surrounding them - any thread dealing with local govt. here is apt to include a few - and I have memories of at leas one scandal that became national news. This is serious stuff. It's not somebody ordering a gross of boxes of paperclips instead of a box of a gross.
The PDFs in the article are of notices sent to the applicants with the relevant official's signature on them. From the point of view of the recipient of an apparently official notice it should be assumed that it won't be rescinded as a mistake at some future date. The incorporation of nonsense in an official notice isn't a reliable indicator that it wasn't meant.
The WiFi trap is one that designers have worked on to improve over the years.
Removing the LED to indicate whether it's on or off has been one improvement. The move onto a function key was a master stroke. They could label the key with some nonsensical icon or go a step further and label it with something apparently irrelevant - of course an icon of an aeroplane means WiFi. And does the Fn key enable the actual Fn or the hardware functions.
Industrial design has contributed a lot to laptop ease of use over the years.