Copyright protest on the 21st MarchÉibhear, 2019-03-21 23:59:00 GMT On the 21st March, I shut down this website for a day in protest at the proposed EU Copyright Directive. I outline my concerns here. Paywalling twitter rantÉibhear, 2019-03-11 13:00:00 GMT The following tweet popped up in my time-line this morning (11th March): In case you can't read that, the tweet is by Tom Hamilton (@thhamilton) the text is All these people complaining that an article is behind a paywall, god forbid that anyone should ever recommend them a book. I quote-tweeted it as the start of a 8-tweet thread on the paywalling of newspaper articles: In case you can't read that, and for posterity, here is that thread as posted (with the thread numbering removed): Addressing the paywall complaints side of this tweet. If I go into a shop and buy a newspaper, I would pay approximately €2. For that, I get access to – perhaps – 100 articles. Coming in at 2¢, I would be happy to pay that on an article-by-article basis. I get my daily news from approximately 40 different sources across the internet. Combined, these sources publish approximately 200 articles or posts per day. However, I read – from start to finish – maybe 5-10 of them, and scan through around another 30. Even if I am charged for accessing each article at the rate of 2¢, my daily news-reading cost would be less than €1. Perfectly reasonable. In fact, I'd be happy to pay twice that on a daily basis. But… no news site that I am interested in accessing is running a charging model that would support my reading habit, and from my perspective, this is a bloody-good reason to complain. Taking 1 newspaper as an example, @irishtimes, if I don't purchase a subscription, I can access no more than 5 of its articles per week. If I buy the most basic subscription they offer, I would pay €3.50/week to access all its articles. Yet, I read 3-4 of its articles each week, and scan-over another 10. That's 25¢ per article accessed, even if it's marketed at me as a rate of 0.5¢/article. If all the sites I access for news charged me the same rate (and assuming I was prepared to pay), my news-reading habit would cost me €140/day, which would result in a per-article, or per-post, access cost of approximately €3.50 each. Again, a bloody-good reason to complain about paywalling. I have heard and read a whopping amount of commentary over the years about how people's expectation of free access to news is killing the publishing industry. I'm calling bullshit. If you charge reasonably, you'll get paying readers. If you're not prepared to respect your readers, then you should have no expectation of being paid. Reporting bugs (Éibhear's opinion, FWIW)Éibhear, 2019-03-06 22:38:00 GMT Prologue I'm old. I'm so old, I was already a development team lead and systems designer before DevOps was a twinkle in anyone's eye, or before The Agile Manifesto was anything more than some scratchings on a paper napkin. What follows is a guideline for how testers were to report bugs to me and my team. Younger people (or those not-so-young people who pretend they're trendy) will argue that with all these new, modern automated testing systems, this should be unnecessary. To that I have this to say: there are organisations out there who aren't yet in a position to make use of those tools and methods, and this post is for them. Introduction Purpose This document outlines what a developer should be provided as part of a well-formed bug report. Background A bug is a behaviour in software that is not expected. Often, the unexpected behaviour arises from code failure. However, this is not always the case. In order to assist the developer in determining the root cause of the problem, the bug/issue report should provide as much information as possible. Most, if not all of the information to be provided to the developer is information that the reporter would have to hand. Information to be in a bug/fault report Subject A single, short, sentence that nearly-uniquely describes the problem as the reporter sees it. Make it read like an e-mail subject It's not possible to ensure that the description is unique, but it should, at least, be distinct from the other open issues. The subject should state the problem, and not what the fix is, or should be. If using a standardised information entry form, the subject should not include information that is recorded elsewhere (e.g. in Bugzilla, Product and Component are recorded in one of the fixed-format fields, etc). Examples Good"Can't access profit centre field in FT Map screen for contract of product XYZ". Bad"FT Map fields not working" Steps to reproduce the bug A detailed set of steps that the developer would follow to reproduce the defect. This information will allow the developer to do this before returning to the reporter (if necessary) for more information. Where possible, avoid using information that is unique to the environment (e.g. specific server names, or URLs), so that the developer can attempt the steps in the development environment. Of course, this may not be possible if the fault depends on specific data or configurations in the environment. If this is the case, these details should be noted in the report. Examples Good Log onto ADS and search for customer '000123456' From search screen, drill down to customer screen, and then drill down to view the details on the contract '11123415'. Create a new contact record with the following settings: Loan letter 1 Handler code 'ABCD' Attach this case to the contract '72615344' by pressing the "Attach" button. Save contact record. Quit the ADS. Log back in and navigate to the same contact record for both contracts. The handler code for '11123415' is recorded correctly as 'ABCD', but the handler code for '72615344' is blank. Bad"when I create a contact record for a contract and attach it to another contract not all the fields are updated properly" Bad The following was the full report on a recent ADS bug "Hi… When I try to generate a letter from the arrears system, I'm getting an error 'Internet explorer cannot display the webpage'. I have attached the screenshot - could you take a look please? Thanks.." Expected behaviour versus Actual behaviour This is critical. The developer must be provided with a description of what was expected and a description of what actually happened. It's not fair to make the developer guess as to what was supposed to have happened. Good example"We expected that the interest surcharge field in the output file for this record would be the same as the value for the contract in the EIS" Bad example"it's not right" Opinion This is also critical. It may not be obvious that this is a bug or fault. The reporter should provide an analysis as to why this is to be considered a bug. Other subjective information that should be included are severity and scope of impact. Example Good "Section x.y.z of the requirement states that for this type of contract, the profit centre field is required and must be supplied. However, as the field is disabled, this isn't possible. This is why we're raising this issue. We find that this bug effects contracts from products A, B and C, but for products D and E, this bug isn't present. As these are the most common product types, and as this field is required for the ticket to be uploaded, this is a critical bug." Bad"Please have a look to see if this is supposed to be the case." Supporting information The following lists the other, supporting, information that the developer might require for investigation purposes. A contact person for the fault/bug (tester, analyst, ITI staff member etc.) Good example"As I will be on leave tomorrow and the next day, I'll be handing this bug over to X, and (s)he will be aware of the details." The investigations that the reporter did to confirm that the fault is something for the developer to investigate. Good exampleI looked into the following: I confirmed that in the CONTACT table, the handler code is populated for the contact record for '11123415', but is reporting NULL for the contact record on '72615344'." Date and time on which the error occured, both system date and time, and application date, if different. This would let us know where in log files, for example, to look (or what log files to look for, in the event that they have been archived). Good example"This occured at around 10:30 on the 5th. The core system, though, was at the 1st February." Scope of the fault. This will give us information on the domain range of the fault. Good examples "The bug occurs just for this contract." "All accounts of class DEPSIA with an open date of before 1st January 2007 show this fault. We haven't seen it in any other accounts." Log files. This could include application log files (e.g. output files produced by the application's code) and system log files (e.g. log files from Apache, Oracle, IIS, etc.) The trouble shooting document of the system at hand will provide information on where to find these output files. Good example"The following files are attached: Error and access log files from apache web server The application error and access log files." Discussion threads regarding the bug. If the reporter has e-mails or instant message logs that discuss the fault/bug, please help the developer by including the full conversations in the bug report. Good example"See below for an IM conversation I had with the DBA on this problem, confirming that the DAD configuration is correct." Other suggestions Don't assume: if you encounter the bug in system X, report the bug as being in system X. If you think the bug is in system Y, then provide the information you used to come to that conclusion. Avoid screen shots: pictures are very difficult to search, and they can also be missing some critical information. For example, a screenshot of a terminal session may not include all the output of the command. Instead, provide the log file, or copy-and-paste the output from the terminal session into the bug (or a text file). If you feel the two are materially different, then provide both. In some circumstances, a screen shot is necessary1. However, please use it only to support the report, not as the report. Finally, if you have to provide a screenshot, please provide them as image files (e.g. jpg, png, etc.) and not pasted into MS Word documents. This just increases the amount of time the developer needs to spend on coming to understand the bug report. If you think it's an environment issue (but you're not sure), rather than a code problem, log the bug anyway. The developer can help to demonstrate and confirm that it is an environment issue. Footnotes: 1 Jesus, did I really write that?! Article 11Éibhear, 2019-03-02 16:11:00 GMT This is the text of a "letter" I sent to the editor of the Irish Times on the 26th January, 2019. It wasn't published. It is now. For anyone who reads this blog – if there is anyone at all – the pitch might seem simplistic. This is because I was seeking to make the point to those who would not have technical backgrounds, who would not be familiar with the context, or who are focussed on other issues and are not aware of the discussion (or a combination of all the above). Also, I have simply removed the greeting and the sign-off; everything else below is what it is the letter, so it still reads like a letter to the editor. Despite clear evidence to the contrary, many of the pre-internet industries believe that bigger, broader, harder copyright is the only way to compete with the internet. Through Article 11 of the EU Copyright directive, EU-based publishers are seeking to escalate this to the point where cutting off one's nose to spite one's face would be considered a mere flesh-wound. Article 11 will place a charge on the use of "snippets" by news aggregation services. The largest news aggregator out there – the bogeyman used to promote Article 11 – is Google News. Google News has recently said it is considering pulling out of the EU altogether if Article 11 is included. This is no idle threat. In 2013, Germany passed a similar law, and Google delisted some publications to avoid accusation of copyright infringement. The resulting loss of inbound traffic prompted the publishers to grant a free licence to Google. In 2014, having learned the lesson, Spain passed a similar law, but made the granting of free licences illegal. So, Google News pulled out of Spain altogether; significantly reducing traffic to the publications' sites. The law also caused a number of local aggregation services to close down, resulting in the loss of jobs. Article 11 seeks to apply a similar regime across Europe, with no regard for the failure of similar, recent efforts within the EU. A publisher can use existing technical measures – such as the "robots.txt" standard – to prevent their works being accessible through aggregators that don't have a licence. If an aggregator doesn't want to pay for such a licence, as should be its right, it can decide not to carry links to those publications' services. What the publishers should neither demand, nor get, is the traffic that comes from the aggregation services (so they can earn their own revenue) as well as payment from those services for the privilege of sending that traffic. Another lesson from Spain, though, is something that should be of concern. Google News is doing just fine. However, a study conducted in 2015 by the Spanish Association of Publishers of Periodical Publications, found that while all publications suffered, the smaller, less well known publications were disproportionally affected; without aggregation services, internet users would just go to the better-known brands for their news. Is this something that EU publishers look forward to? Larger publishers will be resilient to a significant drop in traffic if aggregation is effectively abolished in the EU. Will the smaller, local publishers? Have those publishers looked objectively into the whole effect Article 11 will have on their abilities to gather and report news? The internet is here to stay. In the long term, publications and publishers will have to reconcile themselves to this fact and take advantage of it. The EU Copyright Directive with Articles 11 and 13 will not stop the internet being used, but has the potential to severely damage it for everyone, and one continues to wonder whether this is not by design. Copyright theft and the National AnthemÉibhear, 2019-02-02 16:02:00 GMT I wrote this some months ago, but didn't post it for some reason, so I am doing so now. In July last year, the Seanad issued a report on what to do regarding "protecting" the national anthem. The newspaper reports are here ("Committee calls for national anthem guidelines and formal Irish sign language version"), and here ("Families disappointed Amhrán na bhFiann will not be protected by law") 1, including mention of how some politicians want to put the country's national anthem back into copyright2. I agree that symbols of the state are important, and should be respected. The thing is, respect can't be mandated by legislation. Respect is earned. It's that simple. If a country has to pass a law to make it feel it's getting respect, then that's not the problem the country has. The problem is that the country can't think of any other way to get it. A country that thinks it can get respect by passing a law deserves contempt. On the other hand, if a country wants to make a fool of itself this way (and many have!), it souldn't use copyright. Copyright is a monopoly, granted to creators on their works to allow them some control over them. Typically to allow them to earn money from the work. Copyright's monopoly has a time limit, though: a work under copyright falls into the public domain after a specific period of time. The time limit is there because the original drafters of (modern) copyright wanted to make sure that after the creator had been reasonably compensated for the work, the public could then benefit by sharing it without restriction. Copyright's monopoly also has a scope limit: a still-in-copyright work can be copied without infringment under certain circumstances. Criticism, satire and parody are typical. So, too, are copying for research, or personal study. Libraries have some rights, too. Again, the logic is that the public would be poorer if these forms of copying were prohibited. The copyrights on the tune, the original English lyrics and the later Irish lyrics of The Soldier's Song (Amhrán na bhFiann)3 expired in 2012. Calling for the song to be returned to copyright is just wrong. Being dead, neither Peadar Kearney nor Liam Ó Rinn have livelihoods. So the call isn't out of concern for that. Nor is it out of concern for any of their descendents who happen to still be alive, as the State bought the copyrights in the '60s, so they would have had no entitlement anyway! What bothers those making the call is that once the song was came out of copyright, Paul Galvin, the former Kerry footballer, used it in ads to sell clothes, and they just didn't like that kind of thing. But, simply put, that's not what copyright is for. As with every tool, if you use it for something it wasn't designed for, it could very well get broken beyond repair. I understand why they want these types of restrictions to be placed on symbols of the state. But we have to call this what it is: censorship. We shouldn't be afraid of using that word. Those who want to apply these controls on the national anthem should prepare specific legislation to address their concerns, rather than using something, like copyright, that would neither be appropriate nor effective. I can even donate a name for it, if they'd like: the "Censorship, Restrictions and Appropriation of State Symbols" bill. That way, just like what they do in the U.S., once it is signed into law, it can be referred to as the CRASS Act. Footnotes: 1 If Article 11 of the EU Copyright Directive passes, the inclusion in this blog post of the headlines to those articles would be illegal. Isn't that just mad? 2 Read my previous article regarding why I believe this is a form "Copyright Theft" 3 By the way, only a portion of the song is the country's national anthem Some questions for the "5 Eyes" countries on what they think they can doÉibhear, 2018-09-04 20:11:00 IST As one commenter put it, "Here we go again". There's something up with the so-called "Intelligence Community" that convinces them that there is a technical solution to the social and political problem that exercises them the most these days. And, what is that problem? It's that people talk to each other, and often1 want to do so in private. In a Statement of Principles on Access to Evidence and Encryption, the 5-eyes partnership – the U.S.A., the U.K., Australia, New Zealand and Canada, working together to share all the "signals" (a.k.a. internet) data they capture – have again stated that internet service providers must "assist authorities to lawfully access data, including the content of communications" if the law requires it. This is all fine, but given the history of the requirement, and the ways it has been stated over the years, it's clear that this is code for their belief that the service providers must only provide encrypted communications that law enforcement and other security types can spy on2. It has been pointed out countless times by people far more informed than I that what they seek just can't be provided safely. I am firmly of the belief that this requirement is effectively impossible, and attempts to put it in place will ultimately harm innocent people. Here's a little experiment… Social Gibiris is an instance of the microblogging system called GNU Social. I operate that instance. Social Gibiris is a node in a federated group of similar systems that might be as large as thousands – or maybe tens of thousands – of nodes. These federated nodes use internationally-agreed information-sharing protocols so that a post on one node is made available to users on another if they wish it. Not all of these nodes, or computers, run GNU Social. Other alternatives that speak the same information-sharing protocols include Pleroma, Mastodon, postActiv and many other software packages. However, they can all shares messages with each other, and no one organisation or entity is in control of this environment. As the information-sharing protocol is freely available, anyone can write a new system that can be plugged into the federation of nodes, and – if that person chooses to do so – the code for that new system can be shared with anyone else for them to create their own node. At present, GNU Social, which Social Gibiris uses, doesn't support end-to-end encryption of messages. Therefore, the 5-eyes group of nations doesn't have to worry about trying to crack those messages – they're there for all to see. But, I have posted an encrypted message on my own instance. Only one person can read the decrypted message, and I'm not saying who that is. That person doesn't even know that the message is there. It's not important. That message is now available on other micro-blogging nodes that mine is federated with. By my act of posting it on my instance, Highland Arrow has it, so has social.heckin.tech, it's on gnusocial.net and – while it's still in existence – it's on Quitter.no3. Heck, it's even accessible on twitter! The one person who can decrypt that message can do so by retrieving it from anywhere it has been federated to (except twitter, which doesn't support messages longer than 280 characters, and mine is longer than that). What is important is that I posted an encrypted message to my micro-blogging system that doesn't support encryption, and the 5-eyes countries can't do anything about it. Or… can they? If the answer to any of the following questions is No, then it's unlikely that they can. Can the 5-eyes countries break the encryption method I used to encrypt that message (PGP)? Can they break the other encryption methods that are currently considered "strong"? Can the 5-eyes countries criminalise the use of that encryption method, or any other encryption method that they can't break? Can they force all the other countries in the world to follow along with such a criminalisation? Can the 5-eyes countries really force all the large, global internet platforms to use weakened encryption for the messaging services they offer their users? If they were successful in forcing all the large, global internet platforms to use weakened encryption, can they force all the world's internet users to use only those platforms? Can they prevent users of these large, global internet platforms from first encrypting their messages themselves using strong encryption (i.e. just like I did with my encrypted message on Social Gibiris)? Can the 5-eyes countries stop small software development communities from developing alternatives (e.g. GNU Social, postActiv, etc.) to the weakened systems operated by the large global platforms? Can the 5-eyes countries stop small software development communities from developing alternative encryption methods in the event that the currently-strong methods become weak (e.g. by some new methods being developed to defeat them)? Can the 5-eyes countries genuinely prevent all forms of secret communication, known now, or yet to be invented, from being used by all 7.5+ billion people in the world? To that last question, I have two non-Yes/No follow up questions: How much would that cost? Do we really think it would be worth it? One of the regular arguments against letting governments "legally" spy on encrypted messages is that once that has been facilitated for governments we like, it will also be facilitated for governments we don't like (and also for other bad actors like, for example, organised crime gangs that want to see our banking transactions). The reasoning here is that just like a car, or a screw-driver, or a shoe, an encryption method knows nothing about the intention of its user, and once it's weak, it's weak for all users; good, bad or indifferent. However, that's not my point these days, even though I've made it in the past, and even though I believe it to be compelling. My point these days is that all this effort WILL NOT RESULT IN WHAT THE 5-EYES COUNTRIES PRETEND THEY WANT. And I think that's more compelling. But, what do I know? If you can refer me to a good analysis that suggests I'm wrong, please do so. I can be contacted at @email@example.com, @firstname.lastname@example.org or at my e-mail address, which can be seen at the bottom of this web page. I would genuinely love to hear what there is out there that might prove me wrong. Footnotes: 1 Often?! Very nearly all the time! 2 Their own law enforcement and security types, no doubt. If it's a legal requirement in China, too, I'm sure the NSA and its ilk wouldn't be massively keen to know that Mr. Trumps's WhatsApp messages could legally be decrypted over there! 3 Depending on when you're reading this, quitter.no is shutting down tomorrow, or did so on the 5th September, 2018. Post-script on why you should stop trying to stop people from using encryptionÉibhear, 2018-08-22 13:40:00 IST Quick summary: Forcing internet messaging services to permit only weakly-encrypted communications so that governments can access them easily, will not impact bad actors, but will seriously impact innocent people who want to obey the law. Read further for my explanation. In my previous post, I outlined the abject pointlessness of governments' attempts to force service providers to weaken the encryption used on their messaging services. The government of Australia is embarked on just such a foolhardy course of action. Whether you agree or not that "something has to be done", this is guaranteed to be a total failure no matter how far the initiative is taken. The point of my post yesterday is essentially a combination of the following three facts: It is possible for me to write an encrypted message, to print it out, to put it into an envelope and then the postal system, and for the recipient to do what needs to be done to decrypt that message. No matter how easy it is to open that envelope while the letter is in transit1, the message will still be unavailable to anyone who wants to examine it, because it's encrypted. In exactly the same way, anyone who cares to do so can send an encrypted message to anyone else over an electronic communications channel that isn't encrypted (e.g. e-mail), or one that uses a deliberately-weakened encryption (e.g. WhatsApp, etc. if some so-called democratic governments get their way). The financial cost of being able to do this is tiny: it can be done using the standard "smart 'phone" people carry around in their pockets, and using freely-available software tools. There are 7.5 billion people in the world. If even 1% of 1% of them have the really, really bad intentions that governments believe these measures will stop, that gives us 750,000 people who have an interest in investing the tiny amount of money and effort to get around these weakened encryption schemes. This assumes, of course that at least one of the existing strong encryption methods – of which there are very many! – remains inaccessible to government organisations. If all of them magically become accessible to these government organisations, of the 750,000 really, really bad people interested in circumventing the weakened encryption methods, there are likely enough people in there to develop yet another algorithm that they will be able to exploit. Let's assume that Australia, or the U.S., or some other government ultimately succeeds in getting all the internet service providers to stop providing encrypted messaging2 services, who will be affected? Innocent people going about their private business. That's who. And, perhaps, some low-grade, stupid baddies. Any baddie worthy of the description will avail of the obvious workarounds I outline above. However, people communicating with their banks, lawyers conversing with their clients, charity organisations working to support people in oppressive countries will all have their communications capabilities compromised by these laws, because they will all want to be compliant. Those who don't care about obeying the law will continue to communicate with each other in illegal ways, and it won't matter to them that they have to break yet one more law to do so. A message to politicians: Congratulations for getting this far. Please use the logic of the technology: Technology doesn't know or care about the motives of the people using it. Saying that innocent people won't be affected by a legal ban on effective encryption is patently untrue. But it's worse than that: non-innocent people definitely won't be affected; they will easily route around such a ban. If you are truly interested in the democratic principle of freedom, you will permit innocent people going about innocent activities to speak privately with whomever they wish, and you will push for more sensible measures, which will have to include investing in police and security forces for them to improve their capacities to use the available, effective investigative methods, and to allow them to develop new methods that don't infringe on the rights of innocent people! Footnotes: 1 Or, if I just leave the envelope unsealed 2 I'm now sick of writing variations on "weakened encryption"; simply put: if it has been weakened, it's not encryption. You just can't stop people from using encryption, so stop trying toÉibhear, 2018-08-21 09:00:00 IST UpdateI've added another post, intended to be read after this one, outlining how not only will government efforts to reduce the usage of encryption not work for its intended purpose, but that the real affect will be to innocent people doing innocent things. There is yet another story in the news about how the US Government is trying to compel a voice messaging service to break the encryption on the service for the purposes of an investigation. There are many reasons why this is a bad idea, and many explanations as to how investigative bodies like the FBI could get around such problems. I'm just going to cover one issue here: it's pointless. There is a very long (and growing) list of strong encryption algorithms. There are 7.5 billion people on the planet. The cost of a computer (including the software required) to develop a system that uses any one of those algorthims – or to develop a new one – altogether can be as low a €100-€200 (or lower), and the cost to rent one from one of the cloud hosting providers can be as low as less that €1/day. Encryption is just mathematics, so a new algorithm can be invented using a pencil and paper anyway. There is no government in the world that can stop all those 7.5 billion people from availing of the option to spend that small amount of money to develop such critically useful software. Telling Facebook that it can't use strong encryption doesn't stop Google from using it. Telling Google and Facebook that they can't use it doesn't stop Microsoft. Telling Facebook, Google and Microsoft doesn't stop Amazon, etc. Telling all companies based in the US that they can't use strong encryption doesn't stop companies in Canada from doing so. And then there's France, and New Zealand, and Russia, and Zimbabwe and all the other countries in the world. Even if you could achieve the ridiculous "ideal" of having all countries in the world pass legislation to ban strong encryption, do you really think that subversive civil liberties groups or organised criminal groups would just stop there? Over every communications channels can be built another. For example, it's possible to put an encrypted message into a sealed envelope. Some might think that sealing the envelope is enough security, but others may want the additional protection. It's possible to send encrypted messages over SMS. It's possible to send encrypted messages in e-mail. It's possible to send strongly-encrypted messages over a channel that pretends to be encrypted but isn't because some authoritarian government has passed a law, and those messages will be as difficult to decrypt as the voice messages over Facebook Messenger currently are. Literally, it's pointless, and also a tremendous waste of time and money. So: stop. Spend the cash on effective investigative methods, and allow innocent people to go about their business without interference. So you want to edit/correct/clarify/retract that tweet?Éibhear, 2018-08-19 01:14:00 IST Some years ago I wrote a post proposing that Twitter could (should!) implement a retract button. I still think the proposal is valid and compelling. I recently listened to the great Techdirt podcast episode where Mike Masnick (@mmasnick) talks to Cathy Gellis (@cathygellis) and Parker Higgins (@xor) about "Old Tweets & Your Permanent Record"1, and it prompted me to think a little deeper about my initial proposal. The podcast discussion was inspired by Parker's2 post on how Twitter should allow users to hide their tweets (rather than deleting them). The context is that some famous Twitter users have recently got into trouble because their feeds have been searched for inappropriate tweets, which have then been used to cause them hassle in their professional lives ("She's a racist, the New York Times shouldn't hire her!" or "He promoted paedophilia, Disney should sack him!"). Without being able to cite specifics, I'm guessing that this context results in tweets being deleted. In some cases, I'm sure, whole accounts have been deleted. The result is messy: tweets having been removed from conversational or other contextual flows, links having been broken, conversations' continuities have been reduced, etc. Sometimes, it's more than just messy: as discussed in the podcast, people can delete whole bunches of tweets, and then regret it later because some were personally valuable, after which there's no going back3. I wonder if my proposal might help. Also, I've added some aspects to it that, perhaps, may make it more attractive. Correct, clarify, retract. Twitter4 should offer the ability to users to either correct, clarify or retract a tweet. Unfortunately, I'm not very good at mocking up screens, so I ask you to imagine what I describe. If you would like to volunteer some mock-ups, I'm at @email@example.com or @firstname.lastname@example.org and I would be very grateful for your help. In Twitter, an author's tweet comes with a menu (click on the shallow "v" at the top-right corner of the tweet) that allows you to perform a number of actions, including to delete the tweet. I suggest that there could be some other options, perhaps under a sub-menu with Edit as the name, offering Correct, Clarify and Retract as options. So, what will happen with these options? Upon selecting each of these, the author of the original tweet will be presented with the ability to reply to it, and will (if they wish, I guess) enter an explanation of what's happening. This could be a thread, if necessary. Once submitted, the interesting things happen: The original tweet will be updated in a prominent way with one of the following "The author has added a correction to this tweet." "The author has provided a clarification to this tweet" "The author has retracted this tweet" The explanation provided forever will be the first reply to the original tweet: users won't be able to say they couldn't find it. [Maybe: I haven't thought this one out fully] It won't be possible to reply to or retweet the original tweet. Where the original tweet was retweeted or embedded elsewhere, the fact that the tweet has been corrected, or clarified, or retracted will be made clear to the user. As mentioned in my previous post, all other users who engaged with the original tweet beforehand will receive a notification that this correction or clarification or retraction has happened. Some examples Correction Imagine some lumpen idiot who makes reference to @mmasnick in a tweet and then types out his name as "Mick", but doesn't noticing that until after it has been pointed out to him5. It would be nice to be able to add a correction to the tweet to say that it should have been "Mike" and for it to be prominent for anyone who comes along. ClarificationRemember that tweet you sent that made sense to you right up to the moment just after you submitted it, and then you started to doubt yourself? And then your doubts are confirmed by all the replies with "Wut?" and "Well, actually…"? To delete it, and then to send a clarification, presents the problem that all those replies are set afloat in a sea of noncontext, and then its hard for people to know what's happening. With my proposal, you could follow the original post with a clarification, which jumps out at you when you visit the original. Now other users understand the context of the full conversation. RetractionMy original point. Sometimes you say something that you really regret. Maybe you said something long in the past that now runs counter to your current opinion. The standard approach is to delete the tweet. I have never been convinced that this is the correct approach, however, especially for people who want to acknowledge that they were wrong with the original post. Having been in that situation myself, I understand the risk that a tweet that lives on could be taken out of context no matter how clear you are in your retraction. These tweets are the best fodder for those who want to destroy your employment or personal relationships, but to remove them completely is a regretful corruption of the historical record, and essentially denies it happened. But pretenting such a denial may very well back-fire. Why, though? I believe that deleting tweets is wrong. I won't try to convert anyone else to this view, but I would like help those who agree with me regarding what I say above to use alternative approaches – at least on a case-by-case basis. Essentially, to delete a tweet – especially one that others have engaged with – is not appropriate in all but a very small number of scenarios. People delete tweets to correct typos (Correction: this is the only reason I delete tweets from my personal account), to rephrase them (Clarification), to ensure that they are not used against them (Retraction) or because they are embarrassed by them (Deletion: in no way am I arguing that users shouldn't be permitted to delete tweets). For me only the last reason is compelling enough to delete a tweet, and even then I would recommend retraction instead. Have a read of The Intercept's A Note to Readers, in which it outlines how it found out that one of its staff members had been fabricating parts of stories he had written and were published on the site. Instead of removing the stories, The Intercept added "corrections and editor's notes" to them, even going so far as retracting one story in full. This, in my view, is the correct approach: the record remains intact but the follow-up that corrects or clarifies or retracts the original is prominently presented to all parties. In my scheme, Twitter will include the notice of correction, clarification or retraction with embeds and retweets (even historical retweets – a tweet from 5 years ago that was retracted last week should be obviously retracted to someone reviewing the retweeter's timeline now). Therefore, each reviewing user will be offered the chance to dig a tiny bit deeper into the context before deciding to rant, report, or call for a sacking. Yes, of course: screen grabs will always allow bad-faith actors to remove or deny context. However, if this proposal is implemented, then it will (should!) be clear that if there isn't a link to the original post accompanying screen grab, then the person presenting the screen grab may not have good-faith intentions. Finally, I think it's important that the users who have replied to the original, or retweeted it, receive a notification that the correction or clarification or retraction has happened. This offers those users the opportunity to pass information regarding that event on to their own followers, especially if they have tweeted something about the original that they feel needs a follow-up. The elusive edit-tweet feature Imagine the scenario: a seemingly nice person posts a tweet with "I love cats". As expected it gets loads of "likes"6. Then, some time later, that seemingly-nice person used Twitter's Edit Tweet feature to change it from "I love cats" to "I think fascism is great". Those loads of likes remain, and anyone viewing the list of people who liked the original post will see what they consider to be a list of fascists. This is why Twitter doesn't offer an Edit Tweet feature. However, many want to be able to make changes to tweets they have posted, and the only option to them is to delete it and re-post. My proposal offers a compelling alternative to pure editing of tweets, I believe. Footnotes: 1 Ampersand in the original. 2 There must be something up with me, and I don't think it's the new beer I'm drinking as I write this: I typed "Mr. Higgins'" and "Higgins'" and then decided that "Parker's" was probably the best approach as the others were too formal. I hope I'm right, and I wonder why I worry about these things 3 Parker does mention in his post that users can archive their tweets, and may be able to repost them somewhere else, but this could only ever be a part-solution, as conversations would still be broken 4 Yes. Yes. And the others, like GNU Social, Pleroma, Mastodon, etc. I will get to that in a subsequent post 5 His reply to my tweet about his podcast came in as I was typing this post 6 I still prefer "favourite", even though I don't even like that description With marginal knowledge comes marginal powerÉibhear, 2018-05-28 07:55:00 IST As a designer of back-end IT systems, I regard error management and error reporting as something to consider at the start, rather than at the end. Some years ago1, I designed a file-handing system, where we identified a little over 100 different error scenarios to manage. The system acted as a file-movement inferface between our internal system and an externally-hosted service. Between taking files off the end of one pipe and placing them onto another pipe, there was a need to perform rigourous integrity-checks on the files, and then specific transformations on the contents. Quite a number of potential points of failure arose, and if any one was to occur, we wanted to make sure we knew which one, so that the response from the support team would be appropriate. Management of error conditions was fairly easy. Depending on the error, we needed to know whether the user was to be informed (the user being the business admins of the service within the organisation, and the answer being "sometimes"), whether the support staff were to be informed ("always") and where to place the file (and its associated artefacts). Being clear to all concerned on what errors we were dealing with was the interesting challenge. As is normal, we devised a look-up file which would contain the following information on each potential error: A code uniquely identifying the error; A directive on what to do with the file when the error presented (record the error and continue processing the file, abort processing that file, abort processing of all files, etc.); A message describing the error, in english; A flag for whether to inform the user of the error; and A flag for whether to inform the IT Support department ("Y" in all the identified scenarios at this time, but potentially "N" for new, future errors to be managed). The code we developed would identify the error by its error code, and the look-up file would be used to determine the response. In the notification e-mail, the error is expressed using the human-language message, and not the internal error code. However, the log files recording the processing activity – for the sake of brevity – would record the error code, and not the english message. For what follows in this post, it's important to re-state the following: the notifications sent to the user and the IT Support department would not contain the error code, only the message. If, in designing the system, we have done our jobs properly, the e-mail notification should be sufficient to inform the reader of the specific error condition, and in the vast majority of cases, the appropriate response would naturally follow without further investigation. The population of log files was deemed prudent, though, in case something completely unexpected arises: but they should not need to be consulted except when all other options have been exhausted. As a help to those reviewing the log file, I determined that the error code itself should attempt to be readable. Therefore we devised a format that had two benefits: it would allow those reading the code to guess quickly what the nature of the error was, and also to allow for the easy addition of new codes should new error scenarios arise. The format is a little like: [IN|OUT]_<OBJ>_<ERROR> The first part says whether we're dealing with a file coming in to our internal system, or heading out from it; the second part says what the file type is (i.e. a payload file, or one of the accompanying integrity-affirming files); and the third the error has been triggered. Thus: IN_FILE_DECOMPRESSING tells us that there was an error decompressing the inbound file; IN_FILE_INVALID_SIG tells us that the cryptographic signature for the inbound file is invalid; OUT_FILE_LINE_COUNT declares that we could not determine the line-count of the outbound file we're processing and so on. Fast-forward to a few weeks before we go live, and we present our system-nearing-test-completion to some of the IT support staff. This is so that they are familiar with how the system was intended to work. Over a number of sessions, we presented the major features of the system, broken into the sessions on the business requirements implementation and the non-functional implementations. One of the latter sessions was on error handling. A comment during the session had me quite puzzled. One of the attendees decried the format of the error codes, claiming that there were too many elements to it. The expressed desire was that they didn't come with "simple" alpha-numeric codes that they could learn off. I hemmmmmed. I hawwwwed. I agreed that the comment was an interesting one. I also suggested that at this late stage in the project, going back to devise and implement such a scheme would be costly, and would introduce unacceptable risk to the project and its post-implementation support. But I would keep it in mind. And I did keep it in mind. I work hard to figure this one out for a long time. Eventually, I think I arrived at the core point. Consider this: Oracle DBAs are aware what an ORA-600 error2, or a ORA-12154 error3 are. Someone, somewhere (surely?!), knows what to do when the "Excel found unreadable content in…" error that MS Excel often throws up is presented. However, the users don't, and that's because they don't have access to the documentation that tells them what's going on. If our error codes were, in themselves, explicative as regards what the problem is or was, then the user (or, someone new to the support team!) might be overly empowered to resolve the matter him- or herself. Yes. So, we need the error subsystem to use an obscure coding so that those who respond often must learn the codes as part of their jobs as well as their meanings, but those who encounter them rarely must reference others for help. Also, wouldn't it be cool for two people to speak with each other using these arcane codes in front of a user not-so-familiar with them? I have a scheme that could be fool-proof: the ADICEC, pronounced "Adi-ssek". The "Arbitrarily-Devised, Intentionally Complex, Error Code" can be an attribute of the error, prepared purely for the IT department to maintain a separation from the user, building a false dependency between them. Here's how to build an ADICEC: It must be long. It must contain elements that are utterly pointless. For example: A client code (because you never know when the department head is going to attempt to "monetise" the system by selling it to others)4; An instance code (because you never know how many instances of this single-requirement-system there will be); A date-time stamp (because, we always want to know when these codes have been devised). Alternatively, you could use the change-tracker ticket id with which the error code was introduced… A product code (because … never mind) (Finally) a randomly-generated – but seemlingly-sequential – alphanumeric value, uniquely identifying the error, but bearing no reference at all to what the error is about. Now, don't be put off by this. We will continue to use a more accessible error code for exception handling in our source code. The ADICEC will be external to the source, and will only be used for the purpose of inflating a department's sense of importance. So much for K.I.S.S. Footnotes: 1 Many years ago! I now feel it's time to publish this story! 2 internal error 3 TNS alias look-up error 4 This was a system for a financial services organisation to meet it's specific requirements, and was never going to be sold as a product because of the uniqueness of those requirements.