In his latest blog post, Bruce Schneier uses a new paper published by MIT to further reiterate his position of general diffidence towards blockchain technologies, this time applied to voting in political election. The paper, concludes that: not only do these risks persist in blockchain-based voting systems, but blockchains may introduce additional problems for voting systems. It is titled “Going from Bad to Worse: From Internet Voting to Blockchain Voting” by Sunoo Park, Michael Specter, Neha Narula, and Ronald L. Rivest and can be downloaded using this link: https://people.csail.mit.edu/rivest/pubs/PSNR20.pdf.
Schneier also links to this XKCD cartoon as a bonus!
Question: What makes code good or shitty? Anything that is obvious for you at first glance?
David: If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code, is a life long pursuit. As I said in my RailsConf 2014 keynote, we’re not software engineers, we’re software writers. “Writing” is a much more suitable metaphor for what we do most of the time than “engineering” is. Writing is about clarity and presenting information in a clear-to-follow manner so that anybody can understand it
There’s no list of principles and practices that somebody can be taught and then they will automatically produce clear writing every time. If you want to be a good writer, it’s not enough just to memorize the dictionary. Just knowing the words available to you, knowing the patterns of development is not going to make you a good developer. You have to develop an eye. You have to decide that the most important thing for your system is clarity. When you do decide that, you can start developing an eye.
It is common practice at conferences, interviews and certifications in general to assume that the candidate can process the code and find the subtle mistakes in it. As the article clearly says “there is no single proof of correlation between correctly answering any of the above questions and real-world proficiency of applying the skills they are meant to assess.”
Doing it right requires more time to prepare the material and analyse it afterwords but unless one needs to asses thousands of candidates, that investment is well worth it
Almost all websites covering technology had an article this week about an interview by the Wall Street Journal with Bill Burr (the man behind the password complexity rules we are forced to use). In the interview Burr says that he might have been was ‘barking up the wrong tree’ in his 2003 manual NIST Special Publication 800-63. Appendix A
This was big news since many organisations follow these guidelines religiously, to the detriment of their users and possible security. Changing your passwords every 3 months and using long and complex combinations makes using a password-per-site impossible to remember. The advent of password managers and 2FA are a sign that the traditional username+password system is not good enough. Maybe someday in the future we will be seeing less passwords…
“TDD was born out of a collective realization that we needed to change the way software was developed and tested. Similarly, the field of cybersecurity has, in the past decade, brought about a change in the way we think about layered defense in the face of determined attackers. By leveraging these three lessons, we can mirror TDD for software development to create new ways of validating and improving the cyber resilience of our own systems.”