rc3.org

Strong opinions, weakly held

Month: September 2013

The details on ARM64

Mike Ash: ARM64 and You

I’m linking to this, because it’s first class nerdery, giving real insight into CPU design and performance. I always operate many layers of abstraction above this, but I find it absolutely fascinating. By the way, the comments on this post are a tonic against the general pessimism about blog comments.

The security lesson of Touch ID

Today’s big news is that the Chaos Computer Club has broken Apple’s Touch ID fingerprint security feature on the iPhone 5s. First, you have to define broken. They have shown that you can unlock the phone using a copy of an authorized fingerprint. How do you do it? Take a 2400 DPI image of the fingerprint, print it out at 1200 DPI, and then use glue to create a model of the fingerprint.

This reminds me of the fantastic review of bike locks that ran on The Sweethome this week. In the end, the reviewer found that any decent U-lock will deter the casual, opportunistic bike thief and that no lock will deter a professional thief who wants to steal your bike specifically.

Security is a concept with no meaning outside the context of specific threats. Touch ID is meant as a security measure for people who don’t have a passcode on their phone because it’s too much of a hassle. It may also be sufficient for some people who use passcodes. In 2011 Daniel Amitay found that 10% of iPhones are locked using the codes 0000 or 1234.

If you ride a $2,000 bike in New York, it’s eventually going to get stolen if you lock it in the same place every night, no matter which bike lock you buy. If a knowledgeable attacker with unlimited physical access to your phone wants to unlock it, they’ll succeed. Most people don’t need to worry about such attacks. They can probably get away with using Touch ID and a $40 bike lock.

Security has costs, usually in terms of both price and convenience. I already think that tapping in my four digit passcode sucks, I can’t imagine having a longer one. I’m also too lazy to memorize a random passcode, or ever change it. That’s my security posture. Needless to say, I’m not worried about this Touch ID exploit. You probably shouldn’t be, either. If you are, be glad that it’s optional and that you can turn off Simple Passcodes and pick a really good password to unlock your iPhone.

The show must go on

What’s the meaning of life? I really liked the suggestion from Samuel Scheffler in today’s New York Times that it is furthering the human project. He focuses on our belief that human life will continue once we are gone:

Yet I think that this belief plays an extremely important role in our lives, quietly but critically shaping our values, commitments and sense of what is worth doing. Astonishing though it may seem, there are ways in which the continuing existence of other people after our deaths — even that of complete strangers — matters more to us than does our own survival and that of our loved ones.

I think we all know that we confront problems that we will not live to see solved. Believing that society and civilization will go on after we die means enables us to live lives of significance in the face of problems we cannot personally solve. We can proceed with the knowledge that we’re contributing to the project.

A blog is a relationship

I am in the process of writing a post about Ta-Nehisi Coates’ blog that I was going to share with some friends who don’t read it. I started thinking about points he’d made that I wanted to include, and tried to find the posts where he made those points by way of Google. Then I started going through his old posts page by page, and I realized that the whole is far more than the sum of the parts. He’s written some great sentences, and great paragraphs, and great posts, but the blog is a body of work that reinforces, illuminates, and colors the parts that one might want to pick out and share. This may be the first time I’ve had a real sense that blogs really are a new form of writing, different than even a regular column. People may appreciate the posts I select, but they won’t have the same relationship I have with the writing, having read it as it was published over a number of years.

The IETF is on the case

IETF chairman Jari Arkko and Stephen Farrell, IETF Security Area Director, comment on how future Internet standards will respond to the threat of pervasive monitoring (a.k.a. the NSA). The fact that they openly refer to pervasive monitoring as a threat to be countered is a very good sign.

All of this is a long way of saying that I was totally unprepared for today’s bombshell revelations describing the NSA’s efforts to defeat encryption. Not only does the worst possible hypothetical I discussed appear to be true, but it’s true on a scale I couldn’t even imagine. I’m no longer the crank. I wasn’t even close to cranky enough.

Matthew Green: On the NSA. Click through for a good overview of the likely methods and vectors for attack in the SSL ecosystem.

SSL broadly compromised by the NSA

There have been many depressing if not altogether unexpected revelations since Glenn Greenwald broke the story of Edward Snowden’s NSA leaks. Reporters have been working overtime to dig into NSA programs for snooping on electronic conversations. Today’s New York Times story on the NSA compromising SSL is perhaps the biggest. SSL is the secure protocol browsers use to communicate with Web servers. It is the foundation of secure commerce on the Web.

Here’s the crux of the story:

Beginning in 2000, as encryption tools were gradually blanketing the Web, the N.S.A. invested billions of dollars in a clandestine campaign to preserve its ability to eavesdrop. Having lost a public battle in the 1990s to insert its own “back door” in all encryption, it set out to accomplish the same goal by stealth.

The agency, according to the documents and interviews with industry officials, deployed custom-built, superfast computers to break codes, and began collaborating with technology companies in the United States and abroad to build entry points into their products. The documents do not identify which companies have participated.

The N.S.A. hacked into target computers to snare messages before they were encrypted. And the agency used its influence as the world’s most experienced code maker to covertly introduce weaknesses into the encryption standards followed by hardware and software developers around the world.

For more, see this article by Bruce Schneier. As he points out, the NSA has subverted these protocols by cheating the system, not through a cryptanalytic attack on SSL itself. We, as builders of the Internet, need to figure out what we can and can’t trust at this point. If anything, this shows that more than ever before, closed source software is fundamentally untrustworthy.

For more on Edward Snowden, see this piece by Jay Rosen.

Process versus tools

The biggest pushback I got for my Seven Signs of Dysfunctional Engineering Teams post was in response to my point that dysfunctional teams favor process over tools. They argue that it’s easier to change a process as opposed to a tool, and that the more important distinction is in creating a “good process” rather than a “bad process.”

Creating processes is the default in any organization. Creating process starts out simply by reminding people of things, “Make sure you turn out the lights before you leave the room.” Or, “Please email the international team before you launch any features on the UK site.” The establishment of new processes is normal and completely expected.

Atul Gawande became famous for writing about how process can save lives, talking about how discovering best practices and codifying them can provide massive benefits in a medical setting. The New York Times published a really interesting article about Toyota donating efficiency to the Food Bank for New York City. Process improvement is great, and useful.

However, as engineers working in the world of software, we should be building tools to automate these processes whenever it makes sense. Why write down a checklist if you can write a script to execute it? By building tools we can make doing the right thing the path of least resistance. Automation is no panacea, but it can be a powerful productivity multiplier, especially for managers.

Here’s an example. I worked at a company that had a large set of regression tests that were run before every release, and no automated testing regime. When we were ready to release, the entire product team spent at least a day reading tests in from an Excel spreadsheet and running them against the system. Running them by hand created the opportunity for humans to notice problems that may have been beyond the checks in automated tests. On the other hand, this process was incredibly slow, and had the effect of creating a serious disincentive for pushing new releases, which was a problem unto itself.

The sign of dysfunction I was talking about was that an organization fails to recognize and exploit opportunities to create or obtain tools to replace processes or automate redundant tasks. This can happen for a lot of reasons, but the most pernicious is an unwillingness on the part of management to invest resources in building internal software.

That’s what I was talking about.

© 2024 rc3.org

Theme by Anders NorenUp ↑