Authorisation vs. Consent An Article by Terence Eden shkspr.mobi I recently read this interesting, and distressing, story of a man who was drugged and robbed. A form of crime which has been going on for centuries. But the 21st Century twist is that the thieves forced him to transfer large sums of money via his phone's banking apps. While under the influence, the victim used his usernames, passwords, PINs, and biometrics to send money to the criminal's accounts. Is there a "technological" way to stop this? His banks initially refused to refund the stolen money. Only once the press stepped in did they relent. One bank, Revolut, said: This was an unusual case where the payments were authorised by the customer but, as is now clear, without his consent. Upstream Color crime
Rethinking Twitter Verification An Article by Terence Eden shkspr.mobi The main problem, I think, is that no one knows what "Verified" means. If I were in charge (which I'm not) there would be various types of ticks. 🤖 is a bot 🆔 proved their legal identity 🏭 is run by a brand ⚖ is run by a government department 👮 Official law enforcement 😎 Celebrity And so on. iconographyidentity
Feature parity An Article martinfowler.com Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business. Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'. softwarefeaturesrepair