My comment to the FAA regarding a request for comments.

After reading about a request from the FAA regarding a redesign of the Embraer ERJ 190-300 aircraft on Schneier on Security, I took a moment to leave a comment with the FAA.

Note that my reading of the original call for public comments, it seemed to me what Embraer wants to do is create a single network off of which all equipment–from in-flight entertainment to some of the aircraft avionics–on a single network which includes off-the-shelf operating systems.

That is, I believe Embraer is not moving towards “security through obscurity” (though this may be an effect of what they are doing), but towards using more off-the-shelf components and towards using network security in place of physical security when designing in-flight electronics. (Current aircraft provide for network security by physically separating in-flight passenger entertainment systems from aircraft avionics.)

With that in mind, I left the following comment with the FAA.

Note that I did this without my usual first cup of coffee, so it’s not very polished.

(Oh, and as a footnote: if you choose to leave a comment with the FAA, be polite. And realize that, unlike most bureaucracies in the Federal Government, the FAA tends to attract people who love to fly or who love to be around airplanes. So if you leave a comment, realize you’re leaving a comment with a bunch of old pilots: very smart folks who are very concerned about aircraft safety, and who are trying to learn about new technologies to make sure the system remains the safest in the world.)

From the background information provided in FAA-2017-0239, it sounds to me like the new design feature of the Embraer Model ERJ 190-300 aircraft is the use of a single physical network architecture which would tie in equipment in the “passenger-entertainment” domain and the “aircraft safety” domain, and provide for separation of these domains through network security. That is, it would provide isolation in these domains through software, and would therefore require network security testing in order to verify the separation of these domains.

When considering computer security, it is useful to classify the potential problems using the “CIA triad”: confidentiality, integrity and availability.

In this context, confidentiality is the set of rules and the systems and mechanisms which limit information access to those who are authorized to view that information. Integrity are the measures used to assure the information provided is trustworthy and accurate. And availability is the guarantee that the information can be reliably accessed by those authorized to view the information in a timely fashion.

Taken individually we can then consider the types of attacks that may be performed from the passenger-entertainment domain against the aircraft security domain which may cause inadvertent operation of the aircraft.

Take attacks against availability, for example. Attacks against availability include denial of service attacks: one or more malfunctioning pieces of equipment flood the overall network with so much useless data that it chokes off the flow of information across the network. A similar attack, known as a SYN flood attack, attempts to abuse the underlying TCP/IP network protocol’s three-way handshake connection protocol to prevent a piece of equipment from responding to a network connection.

Embraer needs to demonstrate if they use a unified network architecture that the avionics and navigation equipment in their aircraft can survive such a denial of service attack against network availability. This means they need to demonstrate that map products and weather products are not adversely affected, that control services and auto-pilot functionality is not adversely affected, and that attitude, direction and airspeed information is not adversely affected during a denial of service attack. (If the test is to be passed by resorting to back-up indicators, the system must clearly visually indicate to the pilot that avionics are no longer reliable or available.)

Attacks against integrity include spoofing network packets–equipment plugged into the passenger-entertainment domain which spoof on-board data-packets sent from various sensors, and session hijacking: creating properly shaped TCP/IP packets which intercept a network connection between two pieces of equipment. (A sufficiently sophisticated attacker can, with a laptop connected to a network, create a seemingly valid IP packet that appears to come from anywhere in the network.)

Embraer needs to demonstrate that the network protocol they use to communicate between pieces of equipment are hardened against such spoofing. Hardening can be performed through using end-to-end encryption and through the use of checksums (above that provided by TCP/IP) which validate the integrity of the encrypted data. Embraer will also need to have processes in place which allow these security encryption protocols to be updated during maintenance in the event a disgruntled employee leaks those security protocols.

Embraer also needs to demonstrate their software is hardened against “fuzzing”. Fuzzing is an automated testing technique that involves providing invalid, unexpected or random data to a system and making sure it doesn’t fail (either stop working or provide inaccurate information to the pilots). Fuzzing can be performed both by providing completely random inputs, and by varying valid packets by small amounts to see if it creates problems with the system being tested.

In proving that systems are hardened against such protocol attacks, Embraer needs to demonstrate not only that invalid information does not flow into the aircraft-safety domain, but they must also demonstrate that such attacks do not shut down communications between the aircraft-safety domain and various sensors sending vital data.

Confidentiality attacks include passive attacks: users sniffing all the data on a network and eavesdropping on the data being sent and received, and active attacks: gaining internal access to systems which they are not authorized to access. Confidentiality attacks can lead to attacks against availability (by, for example, locking out someone using a password change) and integrity (by, for example, corrupting IFR map products).

Embraer needs to demonstrate their software is hardened against unauthorized access, both to the flight sensor data being sent across the network (through end-to-end encryption) and by verifying access to in-flight data products are restricted to authorized users (by using some form of access control, either though the use of a physical key, a password or biometric security: the “three factors” of authentication). For example, one way to satisfy this requirement is met for mapping products is to require that map data can only be changed from within the cockpit.

Of course, as always, Embraer needs to demonstrate that back-up attitude, directional and air-speed indicators continue to work in the event of a problem with the avionics, that the avionics provides a clear indication that the information they are providing may be invalid due to failure or due to a network attack. And Embraer needs to demonstrate the flight controls of the aircraft continue to operate in the event in-flight avionics are compromised. This includes making sure that all flight control systems are kept separate from the in-flight avionics, with the exception of the autopilot (which should not prevent the pilot from taking control with sufficient force).

I understand that this is an incomplete list of potential security attacks. But by classifying attacks in a networked environment along the “CIA triad”, it should be possible to create and maintain a comprehensive list of tests that Embraer can perform to assure the integrity of the aircraft security domain.

Thank you for your time.

– Bill Woody

One of my biggest complaints about the way we approach government is that we constantly complain about the lack of experts in government–but then, those of us who have some expertise never bother to publicly participate in what is supposed to be a democratic process.

So even if my comments are utterly worthless, they are far better than the expert in the field who never says anything.

A clever man in the middle attack which is why you should always receive reset instructions by e-mail.

How hackers can steal your 2FA email account by getting you to sign up for another website

tl;dr: When building a web site, NEVER create a reset password flow that asks security questions. Always send an e-mail with reset instructions.

In a paper for IEEE Security, researchers from Cyberpion and Israel’s College of Management Academic Studies describe a “Password Reset Man-in-the-Middle Attack” that leverages a bunch of clever insights into how password resets work to steal your email account (and other kinds of accounts), even when it’s protected by two-factor authentication.

Here’s the basics: the attacker gets you to sign up for an account for their website (maybe it’s a site that gives away free personality tests or whatever). The sign-up process presents a series of prompts for the signup, starting with your email address.

As soon as the attacker has your email address, a process on their server logs into your email provider as you and initiates an “I’ve lost access to my email” password reset process.

From then on, every question in your signup process for the attacker’s service is actually a password reset question from your email provider. For example, if your email provider is known to text your phone with a PIN as part of the process, the attacker prompts you for your phone number, then says, “I’ve just texted you a PIN, please enter it now.” You enter the PIN, and the attacker passes that PIN to your email provider.

Same goes for “security questions” like “What street did you live on when you were a kid?” The email provider asks the attacker these questions, the attacker asks you the questions for the signup process, and then uses your answers to impersonate you to the email provider.

This has some serious consequences with account sign-up and password reset flows that do not involve a secondary channel, such as sending an e-mail or replying to an SMS message.

Note that this attack is insidious because it appears you’re answering questions on a third party web site, as that third party is using your answers to attack a trusted bank account.

Do you want to know the reason why? Cocoapods.

The Size of iPhone’s Top Apps Has Increased by 1,000% in Four Years

According to Sensor Tower’s analysis of App Intelligence, the total space required by the top 10 most installed U.S. iPhone apps has grown from 164 MB in May 2013 to about 1.8 GB last month, an 11x or approximately 1,000 percent increase in just four years. In the following report, we delve deeper into which apps have grown the most.

Do you want to know why?

Poor software management, and the increasing reliance on libraries which add code bloat.

The former happens when designers and product managers try to fit more and more features in to an app, and developers are rushed to add features wind up implementing the same functionality five or six different times.

And the latter–well, no-one has ever been fired for using Cocoapods (or another library manager) and sucking in functionality from a third party library of twenty.

One project I worked on a while back, the project manager didn’t tell me he had someone else working on the project as well–and while I noted it in the check-ins, I didn’t think anything of it, until one day suddenly two dozen libraries were checked in. I slow-walked my way out of that project starting that day, in part because the other developer replaced a very simple network interface (which worked reliably) with a link to a half-dozen libraries and a rewritten network interface which didn’t work correctly. (For some reason he thought including AFNetworking v2 was better than simply hitting NSURLSession–despite the fact that AFNetworking v2 uses the older NSURLConnection class–and despite the more important fact that he was using AFNetworking wrong.)

So if you’re an iOS developer and you’re wondering why your app is bloated?

Look in a mirror.

Yes, Apple’s tools have contributed to the problem somewhat. And yes, various resolution of artwork has helped–though even there I’d argue one huge problem there is that so many developers punt on gradients and other special effects by including a huge .PNG file rather than using CAGradientLayer and other API entry points.

But in the end, software bloat is coming from poorly built applications constructed by iOS developers who don’t know what they are doing being rushed by product management to deliver garbage.

A fascinating analysis of the navigation bar, why it must go away, and why I disagree somewhat.

All Thumbs, Why Reach Navigation Should Replace the Navbar in iOS Design

As devices change, our visual language changes with them. It’s time to move away from the navbar in favor of navigation within thumb-reach. For the purposes of this article, we’ll call that Reach Navigation.

Read the rest of the article for a fascinating analysis as to why we should redesign navigation in iOS applications to support “reach navigation” by placing important elements towards the bottom left of the screen, and by supporting certain gestures, such as swipe to move back on the screen.

Of course I have two problems with the idea of completely obliterating the UINavigationBar.


One of the trends we see in iOS and on mobile devices in general is the loss of discoverability: the loss of the affordances which allow a new user to, for example, recognize something can be tapped on, or something reveals a drop-down list of items. You can see this in iOS 10 on the new iPhone 7: pressure-taps on home screen icons for some applications pop up a list of options–but you have no way of knowing this. On earlier versions of Android if you wanted to delete an item in a table, you would do a “long-tap”: press and hold for some period of time. But is there anything in the table telling you this? Scrolling on both platforms give no hint that something can be scrolled if the list happens not to have an item that is “clipped” by a boundary–which is why Android started adding fade effects, and why some designers on iOS were adding the same thing.

Affordances allow us to determine that we can do a thing. And the UINavigationBar, even in it’s post iOS 7 stripped down state (where only color–a violation of the idea that some people are color-blind) indicates something can be tapped on, still communicates the screen we’re on can go back to a prior screen.

If we do away with the UINavigationBar, how will someone new to the platform know to swipe to cancel?

Further, if swipe to cancel becomes a standard gesture, how do we accommodate swiping left and right to browse a list of photographs? I know that Apple prefers swipe up and down for browsing and reserves swipe left and right for other gestures–but most designers working on the iOS platform don’t understand such subtitles, and Western speakers generally think in terms of scanning left and right.

Lower usage controls.

Sometimes we need to provide controls which permit us to do an operation, but which we don’t expect the user to commonly use. They still need to be discoverable.

Formerly when we considered design as an inverted L (with the most visually important thing upper left, and the top being the important branding and navigation area), we’d place the least used controls at the bottom.

But just because in today’s world the easiest to reach controls are at the bottom doesn’t mean we don’t have need for those lesser-used controls–nor should they be accessed by a hidden gesture. (I imagine for Pagans that a custom swipe of a pentagram on the screen reveals a secret settings page. And for the advanced, invoking pentagram swipes invoke different settings: swiping to invoke water, for example, brings up a different screen than invoking spirit.)

Instead, with the notion of reachability navigation, the ideal place to put lesser used settings would be the upper right–where you would need two hands to reach.

Further, while the designer in this article may hate branding–it still is useful from a business perspective.

So use the UINavigationBar. But rethink your navigation. And try to design your application so the most important elements are within thumb’s reach–at the bottom of the screen, where you would normally dump functionality you don’t want to deal with.

Transitioning To WordPress

So I’m most of the way to transitioning the entire web site to WordPress. Really the only thing I was using this site for was blogging, with the occasional page referring to some software project or another. So I’ve decided to just go ahead with the switch.

Of course it doesn’t help that my old hosting company were being a little annoying. I mean, who gives a business a 24 hour notice to rectify a problem on a Sunday? Really?

If you can’t explain it to someone not in your field, you don’t understand it.

Richard Feynman’s ‘Prepare a Freshman Lecture’ Test

Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, “Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the freshman level. That means we don’t really understand it.”

John Gruber continues, regarding Brian Merchant’s The One Device:

Schiller didn’t have the same technological acumen as many of the other execs. “Phil is not a technology guy,” Brett Bilbrey, the former head of Apple’s Advanced Technology Group, says. “There were days when you had to explain things to him like a grade-school kid.” Jobs liked him, Bilbrey thinks, because he “looked at technology like middle America does, like Grandma and Grandpa did.”

A couple of Apple folks who’ve had meetings with Phil Schiller and other high-level Apple executives (in some cases, many meetings, regarding several products, across many years) contacted me yesterday to say that this is pretty much standard practice at Apple. Engineers are expected to be able to explain a complex technology or product in simple, easily-understood terms not because the executive needs it explained simply to understand it, but as proof that the engineer understands it completely.

Based on what I’m hearing, I now think Bilbrey was done profoundly wrong by Merchant’s handling of his quotes.

I concur.

If you cannot explain it to a beginner in your field in the form of a “freshman lecture”, it means you do not understand it.

And if you do not understand it, it means whatever it is you’re producing will be an unmitigated disaster–because if you don’t understand it, chances are if you’re coding it you’re just piling up code until it seems right; if you’re designing it you’re just piling up images until you think you’ve dealt with the design; if you’re selling it you’re just using smoke and mirrors to avoid the gaps which make your product an inconsistent and incoherent mess.

Apple’s strength, by the way, does not come from being the first mover in the market. Apple has never been a first mover in any market they now dominate. Apple did not invent the personal computer. Apple did not invent the smart phone. (They didn’t even invent the touch screen smart phone.) Apple did not invent the music player. Hell, even iTunes started life as an acquisition; the current user interface still contains many of the elements when it was SoundJam MP, a CD ripper app with music player synchronization features.

What Apple does, which has allowed it to dominate the mobile phone market, the mobile player market, the table computer market and have inroads in the mobile computing and desktop computing markets, is to make things simple. To create products that can be explained to Grandpa and Grandma.

To make things that work.

And if you want to beat Apple at its own game, make products which are beautiful but simple, whose form follows function and whose function is suggested by form. Make a product which is beautiful but obvious, which are well designed from the hardware through the software to the user interface.

In other words, make a product which explains itself (through good design) to Grandpa and Grandma.

Sadly, given the amount of disdain shown by most people in the computer industry–from programmers who don’t understand what they’re doing and who refer to their user base as ‘lusers’ to designers who don’t realize they’re telling a story and are just drawing pretty pictures–Apple’s monopoly on good design won’t be challenged in a meaningful way anytime soon.

Not even by the likes of Google, Microsoft or Facebook–who may pay lip service to good design, and who may even have some really top notch designers on their staff–but who are still seeped in the mock superiority and arrogance of Silicon Valley.