Jagged Thoughts | Dr. John Linwood Griffin

February 29, 2012

Pitch, power, and trim

Filed under: Aviation — JLG @ 10:43 PM

I made my first three landings today!  (That’s three separate landings, not one landing where I bounced twice.)

The plan for today’s flight was to fly over to the practice area (the Wachusett Reservoir, north of Worcester, MA) and have me work on ground reference maneuvers.  These maneuvers include:

  • Turns around a point.  Here you fly 1-mile-diameter circles around a fixed point on the ground while holding an altitude of exactly 1000 feet above ground level.  Flying in a circle is harder than it sounds because you have to constantly adjust your bank angle to account for wind; imagine trying to drive a motorboat in a perfect circle while on a river flowing at 15 MPH.  The technique you use is (a) make steeper turns when you are in the part of a circle where the wind is behind you, and (b) make shallower turns when the wind is ahead of you:

    Figure 6-6 (Turns around a point) from the FAA's Airplane Flying Handbook

  • S-turns across a road.  Again, the key point is correcting for wind by changing the steepness of your turns throughout the maneuver:

    Figure 6-5 (S-Turns) from the FAA's Airplane Flying Handbook

  • The rectangular course.  This maneuver is especially important because it mimics the turns you (and other airplanes) make when flying around a runway before landing.  Not surprisingly, the key point is correcting for wind:

    Figure 6-4 (Rectangular course) from the FAA's Airplane Flying Handbook

For longer descriptions of the maneuvers, and the theory behind them, see chapter 6 of the FAA’s Airplane Flying Handbook.

We also practiced steep turns with bank angles greater than 30 degrees.  At 45 degrees we experienced a 1.5G force and at 60 degrees it was a 2G force.  WOW was that fun!  (My instructor knows of my interest in aerobatic flying and mentioned that I will eventually have even more fun pulling 3G and up during aerobatic maneuvers.)  The objective of a steep turn is to make a 360 degree turn, exiting the turn on the same heading you start with, all while maintaining the exact same altitude (3000 feet for today’s practice).  Maintaining altitude is especially challenging during a steep turn; the plane naturally wants to descend whenever you turn because the lift from the wings no longer points straight up.

When we took off the weather was good but snow was quickly moving in on the horizon, making us worry that the flight would have to be cut short.  My instructor even made sure to bring the materials he needed in case visibility dropped too quickly, in which case he would need to take over to make an instrument approach and landing at the airfield.  After an hour of practice the weather conditions were still okay but my instructor gave me the choice of continuing to fly in circles or to head back to the airport to try a few landings.  Well, duh!

Part of flight training is to learn how to interact with air traffic control so as we neared the airport I made initial contact with the tower:  “Hanscom Tower, Cessna one one five four golf, ten miles west, for touch-and-go, with charlie”.  This phrase identifies who we’re contacting (the control tower), who we are (a Cessna brand aircraft with tail number N1154G), where we are (about 10 miles west of the airport), and what we wanted to do (land at the airport then immediately take off again for another practice landing).  After this initial contact the instructor took over the rest of the conversation with ATC so that I could focus on flying the airplane and preparing to land without being distracted by the radio.

Neat tidbit: To return to the airport from the practice area we use Walden Pond (yes, the Walden Pond) as a visual navigation guide — we fly east until we’re directly over the pond, then make a left turn toward the airport’s control tower.  The pond is easy to identify from the air and lines us up at the perfect angle for how ATC wants us to approach the airport.

When we approached the airport we didn’t fly directly towards the runway; instead we flew a partial loop around the runway called the traffic pattern.  The traffic pattern helps organize multiple planes when they are all trying to land at the same time.  In the figure below, we started at the “Entry” label (flying in from the left-hand side of the picture), then flew a U-shaped loop while slowly descending (“Downwind”, “Base”, and “Final”) until we were right above the numbers at the end of the runway:

Excerpt from Figure 7-1 (Traffic patterns) from the FAA's Airplane Flying Handbook

As we got closer and closer to the numbers I kept expecting my instructor to announce “I have the airplane” and take over the controls from me.  But he never did!  He made occasional suggestions at various points — reduce power to increase the descent rate, pitch the nose of the airplane down to gain a little extra airspeed — then all of a sudden he said “okay, start the flare now” and moments later we sank down onto the main wheels in what I consider to be one heck of a pretty darned good landing for my first attempt.

After we settled down onto the runway he instructed me to add full power and we took off again for another circuit around the traffic pattern and another landing.  I found it surprisingly challenging to try to fly a rectangle that looks exactly like the diagram above; for example, my turns ended up not being sharp 90-degree angles, and instead of a nice smooth descent during the “Base” and “Final” phases of the traffic pattern my descents tended to alternate between “not descending” and “descending too quickly”.  Nonetheless, we made it around the pattern and, with my instructor’s coaching, I executed another pretty good landing.  I made a small error during the flare — I pulled back too abruptly on the control stick — meaning that we floated up too high and had to correct for that (by adding a little power while holding a pitch-up attitude) to keep from coming down too hard on the wheels.

The third and final landing wasn’t great per se but we and the plane all made it down intact.  I made several errors:

  • I came in too high for the landing.  Coming in too high was a problem in all three of my landings; each time I started my descent at what I thought was the correct time, but I still ended up much higher than I expected to be by the time we crossed the threshold of the runway.  As I tried to correct our height on the third landing I ended up causing the airplane to go faster than the desired airspeed (the desired speed is about 80 MPH) as we neared touchdown.  We were ultimately able to burn off the excessive speed before landing (runway 29 at KBED is 7,011 feet long and the Cessna 172 only needs a fraction of that to land, so we just floated above the runway for a few moments while the plane slowed down) but I definitely need to work on controlling my altitude on future flights.
  • By this time the meteorological conditions were deteriorating and there was an increasing amount of crosswind (wind across the runway) that I was supposed to correct for using the rudder, in order to make sure we were lined up exactly with the runway at the moment we touched down.  I didn’t use the rudder correctly so we weren’t exactly lined up straight when we touched down.
  • At the moment that the main (rear) wheels touch down, any pilot will be pulling backwards quite a bit on the control stick in order to keep the airplane’s nose pitched up.  This pitch-up attitude allows the plane to slow down naturally and causes the nose wheel to slowly lower to the ground.  After touching down the final time I released my back-pressure too quickly, meaning that the nose came down more quickly than desired.
  • As we slowed down on the runway I applied the brakes too aggressively and not completely in tandem, causing us to swerve a little bit as we continued down the runway.  The gold standard is to apply gentle pedal inputs whenever you’re careening down the runway at 75 MPH.

Still, we and the plane all made it down intact.  For the next hour I grinned from ear-to-ear from having flown the maneuvers and especially from having landed the airplane.  During the post-flight brief my instructor conveyed that he was impressed with my performance throughout the flight (although he pointed out the above problems, and also noted that I need to work on applying better back-pressure to the control stick near the end of the takeoff roll).  Overall it was a great day.

February 14, 2012

NDSS 2012

Filed under: Reviews — JLG @ 1:03 AM

Last week I attended the Network and Distributed System Security (NDSS) Symposium in San Diego, California.  NDSS is generally considered one of the top-tier academic security conferences.  This was my second year in a row attending the symposium.

Things I learned or especially enjoyed are in boldface text below (you may safely skip the non-boldfaced text in the list):

  1. What you publicly “Like” on Facebook makes it easy for someone to profile probable values for attributes you didn’t make public, including gender, relationship status, and age.  For example, as described by Chaabane et al., “single users share more interests than married ones.  In particular, a single user has an average of 9 music interests whereas a married user has only 5.79.”
  2. Femtocells could represent a major vector for attacking or disrupting cellular infrastrcture.  I’ve used femtocells; they are great for having strong conversations in weak coverage areas, but to quote the conclusion of Golde et al.: “Deployed 3G femtocells already outnumber traditional 3G base stations globally, and their deployment is increasing rapidly. However, the security of these low-cost devices and the overall architecture seems poorly implemented in practice. They are inherently trusted, able to monitor and modify all communication passing through them, and with an ability to contact other femtocells through the VPN network…[However, it is well known that it is possible to get root level access to these devices.  We] evaluated and demonstrated attacks originating from a rogue femtocell and their impact on endusers and mobile operators. It is not only possible to intercept and modify mobile communication but also completely impersonate subscribers. Additionally, using the provided access to the operator network, we could leverage these attacks to a global scale, affect the network availability, and take control of a part of the femtocell infrastructure…We believe that attacks specifically targeting end-users are a major problem and almost impossible to mitigate by operators due to the nature of the current femtocell architecture. The only solution towards attacks against end-users would be to not treat the femtocell as a trusted device and rely on end-to-end encryption between the phone and the operator network. However, due to the nature of the 3G architecture and protocols and the large amount of required changes, it is probably not a practical solution.”
  3. Appending padding bytes onto data, before encrypting the data, can be dangerous.  “Padding” is non-useful data appended to a message simply to ensure a minimum length message or to ensure the message ends on a byte-multiple boundary.  (Some encryption functions require such precisely sized input.)  As described by AlFardan and Paterson: “the padding oracle attack…exploits the MAC-then-Pad-then-Encrypt construction used by TLS and makes use of subtle timing differences that may arise in the cryptographic processing carried out during decryption, in order to glean information about the correctness or otherwise of the plaintext format underlying a target ciphertext.  Specifically, Canvel et al. used timing of encrypted TLS error messages in order to distinguish whether the padding occurring at the end of the plaintext was correctly formatted according to the TLS standard or not.  Using Vaudenay’s ideas, this padding oracle information can be leveraged to build a full plaintext recovery attack.”  AlFardan and Paterson’s paper described a padding oracle attack against two implementations of the DTLS (datagram transport layer security) protocol, resulting in full or partial plaintext recovery.
  4. If you want people to click on your malicious link, keep it short and simple.  Onarlioglu et al. presented the results of their user-behavior study that showed, among other results: “When the participants did not have the technical knowledge to make an informed decision for a test and had to rely on their intuition, a very common trend was to make a guess based on the ‘size’, the ‘length’, or the ‘complexity’ of the artifacts involved. For example, a benign Amazon link was labeled as malicious by non-technical participants on the basis that the URL contained a crowded parameter string. Some of the comments included: ‘Too long and complicated.’, ‘It consists of many numbers.’, ‘It has lots of funny letters.’ and ‘It has a very long name and also has some unknown code in it.’. Many of these participants later said they would instead follow a malicious PayPal phishing URL because ‘It is simple.’, ‘Easy to read.’, ‘Clear obvious link.’ and it has a ‘Short address’. One participant made a direct comparison between the two links: ‘This is not dangerous, address is clear. [Amazon link] was dangerous because it was not like this.’. Interestingly, in some cases, the non-technical participants managed to avert attacks thanks to this strategy. For example, a number of participants concluded that a Facebook post containing a code injection attack was dangerous solely on the grounds that the link was ‘long’ and ‘confusing’…the majority of the non-techie group was not aware of the fact that a shortened URL could link to any destination on the web. Rather, they thought that TinyURL was the website that actually hosted the content.”
  5. There needs to be more transparency into how lawful telephone interception systems are constructed and deployed.  At CCS two years ago a paper by Sherr et al. was presented that described a control-plane-DoS attack on CALEA systems; here Bates et al. propose a cryptography-based forensics engine for audit and accounting of CALEA systems.  As described by Bates et al.: “The inability to properly study deployed wiretap systems gives an advantage to those who wish to circumvent them; those who intend to illegally subvert a surveillance system are not usually constrained by the laws governing access to the wiretaps. Indeed, the limited amount of research that has looked at wiretap systems and standards has shown that existing wiretaps are vulnerable to unilateral countermeasures by the target of the wiretap, resulting in incorrect call records and/or omissions in audio recordings.”  Given the amount of light that people are shining on other infrastructure-critical systems such as smart meters and SCADA control systems, perhaps the time is ripe for giving lawful-intercept and monitoring systems the same treatment.
  6. There are still cute ideas in hardware virtualization.  Sun et al. presented work (that followed the nifty Lockdown work by Vasudevan et al. at Carnegie Mellon, of which I was previously unaware) on using the ACPI S3 sleep mode as a BIOS-assisted method for switching between “running” OSes.  The idea is that when you want to switch from your “general web surfing” OS to your “bank access” OS, you simply suspend the first VM (to the S3 state) and then wake the second VM (from its sleep state).  Lockdown did the switch in 20 seconds using the S4 sleep mode; Sun et al.’s work on SecureSwitch does the switch in 6 seconds using the S3 sleep mode but requires some hardware modifications.  Given my interest in hardware virtualization, I particularly enjoyed learning about these two projects.  I also liked the three other systems-security papers presented in the same session: Lin et al. presented forensics work on discovering data structures in unmapped memory; El Defrawy et al. presented work on modifying low-end microcontrollers to provide inexpensive roots of trust for embedded systems; and Tian et al. presented a scheme for one virtual machine to continuously monitor another VM’s heap for evidence of buffer overflow.
  7. Defensive systems that take active responses, such as the OSPF “fight-back” mechanism, can introduce new vulnerabilities as a result of these responses.  In some of my favorite work from the conference, Nakibly et al. described a new “Disguised LSA” attack against the Open Shortest Path First (OSPF) interior gateway protocol.  The authors first describe the OSPF “fight-back” mechanism: “Once a router receives an instance of its own LSA [link state advertisement] which is newer than the last instance it originated, it immediately advertises a newer instance of the LSA which cancels out the false one.”  However, “[The] OSPF spec states that two instances of an LSA [link state advertisement] are considered identical if they have the same values in the following three fields: Sequence Number, Checksum, and Age…all three relevant fields [are] predictable.”  In the Disguised LSA attack the authors first send a forged LSA (purportedly from a victim router) with sequence number N (call this “LSA-A”), then one second later send another forged LSA with sequence number N+1 (LSA-B).  When the victim router receives LSA-A it will fight back by sending a new LSA with sequence number N+1 (LSA-C).  But when the victim receives LSA-B it will ignore it as being a duplicate of LSA-C.  Meanwhile, any router that receives LSA-B before LSA-C will install (the attacker’s) LSA-B and discard (the victim’s) LSA-C as a duplicate.  Not all routers in an area will be poisoned by LSA-B, but the authors’ simulation suggests that 90% or more routers in an AS could be poisoned.  In other disrupting-networks work, Schuchard et al. presented a short paper on how an adversary can send legitimate but oddly-formed BGP messages to cause routers in an arbitrary network location to fall into one of a “variety of failure modes, ranging from severe performance degradation to the unrecoverable failure of all active routing sessions”; and Jiang et al. demonstrated that “a vulnerability affecting the large majority of popular DNS implementations which allows a malicious domain name [such as those used in] malicious activities such as phishing, malware propagation, and botnet command and control [to] stay resolvable long after it has been removed from the upper level servers”, even after the TTL for the domain name expires in DNS caches.
  8. Hot topic 1:  Three papers discussed negative aspects of location privacy in cellular networks.  Kune et al. describe both an attack to determine the TMSI (temporary mobile subscriber identity) assigned to a telephone number in a GSM network, and a technique for monitoring PCCH (paging channel) traffic from a particular cell tower to determine if the subscriber is in the vicinity of (within a few kilometers of) that tower.  Bindschaedler et al. show empirically that recent research on “mix zones” — geographic areas in which users can mix or change their device identifiers such as IP and MAC addresses to hide their movement and ongoing communications — is not yet effective as a privacy preservation mechanism for cellular users.  Finally, in the words of Qian et al.: “An important class of attacks against cellular network infrastructures, i.e., signaling DoS attack, paging channel overload, and channel exhaustion attack, operates by sending low rate data traffic to a large number of mobile devices at a particular location to exhaust bottleneck resources…[We demonstrate] how to create a hit-list of reachable mobile IP addresses associated with the target location to facilitate such targeted DoS attacks.”  Of particular interest: “We show that 80% of the devices keep their device IPs for more than 4 hours, leaving ample time for attack reconnaissance” and that often on UMTS networks in large U.S. cities an attacker could “locate enough IPs to impose 2.5 to 3.5 times the normal load on the network.”
  9. Hot topic 2:  Three papers discussed privacy preservation in cloud-based searching.  Chen et al. presented an interesting architecture where a private cloud and public cloud work are used together to perform a search over sensitive DNA information: “Inspired by the famous “seed-and-extend” method, our approach strategically splits a mapping task: the public cloud seeks exact matches between the keyed hash values of short read substrings (called seeds) and those of reference sequences to roughly position reads on the genome; the private cloud extends the seeds from these positions to find right alignments. Our novel seed-combination technique further moves most workload of this task to the public cloud. The new approach is found to work effectively against known inference attacks, and also easily scale to millions of reads.”  Lu, in addition to having the best opening to a Related Work section that I’ve ever read — “This section overviews related work; it can be skipped with no lack of continuity” — demonstrates “how to build a system that supports logarithmic search over encrypted data.”  This system “would allow a database owner to outsource its encrypted database to a cloud server. The owner would retain control over what records can be queried and by whom, by granting each authorized user a search token and a decryption key. A user would then present this token to cloud server who would use it to find encrypted matching records, while learning nothing else. A user could then use its owner-issued decryption key to learn the actual matching records.”  Finally, Stefanov et al. presented sort-of-cloud-related work on optimizing “Oblivious RAM”: “The goal of O-RAM is to completely hide the data access pattern (which blocks were read/written) from the server. In other words, each data read or write request will generate a completely random sequence of data accesses from the server’s perspective.”
  10. Hot topic 3: Five papers discussed smartphone and/or app insecurity.  In work that had my jaw hitting the floor regarding the security design of production apps, Schrittwieser et al. “analyze nine popular mobile messaging and VoIP applications and evaluate their security models with a focus on authentication mechanisms. We find that a majority of the examined applications use the user’s phone number as a unique token to identify accounts, which further encumbers the implementation of security barriers. Finally, experimental results show that major security flaws exist in most of the tested applications, allowing attackers to hijack accounts, spoof sender-IDs or enumerate subscribers.”  Davi et al. described a control-flow integrity checker for smartphones with ARM processors: asserting “the basic safety property that the control-flow of a program follows only the legitimate paths determined in advance. If an adversary hijacks the control-flow, CFI enforcement can detect this divagation and prevent the attack.”  Zhou et al. analyzed the prevalence of malware in five Android app markets, including the official market and four popular alternative markets.  Two papers (Bugiel et al. and Grace et al.) address privilege-escalation problems in Android, where malicious applications are able to gain unapproved privileges either (Bugiel et al.) by colluding with other differently-privileged applications or (Grace et al.) by invoking APIs unexpectedly exported by the Android framework.  The presenter for the latter paper showed a video of a malicious application sending an SMS message and rebooting(!) the phone, both without holding any user-granted permissions.

There were three keynote speakers, whose messages were: (1) you’re a security professional so you need to be involved in publicly advocating one way or the other on security-related social issues; (2) the future [30 years ahead] will be a strange and interesting place and, since you’re a security researcher, you’ll help us get there; and (3) passwords are passé; if you’re not using two- (or more-)factor authentication then you’re not a good security practitioner.

I like NDSS because of the practical nature of the (mostly academic) work presented:  Much of the work feels innovative enough to advance the science of security, yet relevant and practical enough to immediately be integrated as useful extensions to existing commercial products.  Only 17% of submitted manuscripts were accepted for publication, so the quality of work presented was good.  Unfortunately, attendance is low — someone told me there were 210 people there, but I never heard the official count — so it is not as good a see-old-friends-and-make-new-ones event as, say, CCS.

February 4, 2012

Jagged Technology debrief

Filed under: Reviews — JLG @ 6:41 PM

Jagged Technology, LLC — tagline “We may be rough, but we’re sharp.” — was the name of the (first) company that I founded.

The website read:  “Jagged Technology executes R&D and provides consulting services in the fields of computer science, information processing, and computer systems software and hardware engineering.  Our areas of expertise include storage systems, security architectures, network components, and virtualization and operating systems.  Please contact [us] to discuss teaming, collaboration, sales, and employment opportunities.”

The company existed from late 2007 through early 2009.  My business plan was to pursue Small Business Innovative Research (SBIR) contract awards, following in the footsteps of the successful group I had previously worked for.  (That group had been part of a small government contracting business that had won numerous SBIR awards, but by the time I worked for them they had been acquired by a larger company and were no longer eligible to pursue SBIRs.)

I was wildly unsuccessful — other than in fulfilling my dream to found a business and work for myself — but I enjoyed every minute of it.  There were a few things I did right:

  • I earned revenue!  Not very much, and I certainly came nowhere near turning a profit, but I was able to score some consulting work (evaluating storage system technologies and formulating research and product objectives) meaning that it wasn’t entirely a pipe dream.
  • I had great mentors.  Before starting Jagged I had the privilege to work with and learn from Dr. Tiffany Frazier and Dr. Chuck Morefield.  Both were successful government-contracting entrepreneurs; Tiffany inspired me to dream big; Chuck took the time to sit down with me to describe what had worked for him when he took the plunge.  While running Jagged I relied on Dr. Greg Shannon‘s advice and assistance in creating winnable (if not winning) SBIR proposals and partnerships.
  • I had good ideas.  After I dissolved the company and started working at my next job, I talked with one of the program managers on the phone (about the next round of SBIR solicitations).  The PM recognized my name and mentioned that he’d really liked what I submitted during the previous round.  (I managed not to scream “so why didn’t you fund it?!?”)

Of course, there were many things I did wrong, including:

  • Not having a contract in hand before starting the company.  Nearly every successful government contractor I’ve talked with has said that they already had a contract lined up before filing the paperwork.  Doing so is especially important because it takes forever (often 9 months or longer) between when you first submit a proposal and when you start getting paid for the work.  I assumed that I’d be able quickly to win one or more contracts and that business would grow rapidly after that.
  • Not having a reputation or past performance with the customers I targeted.  The ratio of submitted proposals to winning proposals was around 30:2 on many of the programs to which I proposed.  Often the program manager was already working with a contractor to develop the SBIR topic and announcement (so there’s 1 of the 2 awards likely already earmarked) so in essence I was competing against 29 other companies — many of whom were actual established companies with existing products, intellectual property, and history of contract performance.  And if the PM has actually worked with any of the other 29 companies on a previous program, then my already unfavorable odds get significantly worse.
  • Overemphasizing the technical aspect of a proposal instead of all evaluated aspects.  SBIRs are evaluated equally on technical merit, feasibility of successful execution, and commercialization strategy.  My technical writeups were strong but the other two components (67% of the evaluation criteria) were usually weak; I typically listed only one or two people (me and a technical colleague) as lined up to execute the work and only one or two ideas on how I would partner with larger companies to commercialize the work.  My early proposals were especially unbalanced since I entered entrepreneurship with the idea that if I proposed a superior mousetrap then the money would beat a path to my door.  It would have made a significant difference in my chances for success if I had experienced partners as co-founders.
  • Focusing my business plan on the SBIR program instead of building a diverse revenue stream.  It is hard for me today not to be severely disappointed in the SBIR program.  I poured significant time and money and opportunity into trying to come up with solutions to the government’s and military’s most urgent technological challenges; when I finally received a rejection notice (usually 9 to 12 months later) and I requested my legally required debrief, typically all I would get was a one-line memo saying that the evaluators “didn’t like my commercialization plan.”  Well, what didn’t they like and how can I do better next time?  Anyway, since I didn’t have contract in hand at the beginning (in retrospect) I would have been better served by focusing on commercially salable technology development — and sales — and using the SBIR program as a way to fund development of related but noncritical offshoot ideas.
  • Not having opened a new cellular telephone account for business purposes.  To this day I get people calling my personal cell phone to try to sell widgets or web hosting to Jagged Technology.  On the plus side, registering your home address for a small business gets you signed up for all sorts of fascinating catalogs for boxes and shipping containers, plastic parts, and scientific glassware — I do enjoy receiving these catalogs, and it’s good to know that if I need a pallet of hazardous materials placards I know exactly whom to call.

The best thing to come out of having started Jagged Technology is a better understanding of how business works — for example, the complexity of balancing your product development schedule and projected contract or sales awards with the available resources (time, people, money) on hand to pursue the work; or the need to work in advance to establish a business area (for example by feeding ideas to program managers, and by visibly contributing to related product or community efforts) instead of simply responding to opportunities; or why a CEO spends his or her days talking with the chief finance officer, chief marketing officer, and chief operating officer instead of spending those days talking with project leads and engineers and salespeople.  It’s not all about better mousetraps.

Just as I feel that I’m a better car driver after having taken the Motorcycle Safety Foundation RiderCourse, I feel as though I’m a better researcher, mentor, and employee today thanks to having immersed myself in founding Jagged Technology and having worked hard for eighteen months to make it successful.

And here’s hoping to more success (or at least more revenue) next time!

February 2, 2012

Discovering flight

Filed under: Aviation — JLG @ 8:00 PM

My first flight lesson was today.  I had a fabulous time.

JLG at Hanscom Field, February 2, 2012

Getting here required the encouragement of private pilot Anastasia (Pittsburgh, 2003), aerobatic pilot Doug (Hawthorne, 2006), sport pilot Tim (Annapolis, 2011), and co-pilot Evelyn (Boston, 2012).  I have long wanted to fly but have long been afraid to start — not because of the flying itself but because of the lifestyle commitment that flying represents.  Various pilots and aircraft owners have warned me that flight is a “use it or lose it skill” and that once you start flying you need to keep flying regularly to stay proficient.

But carpe diem, no?  I’ve been wanting to do this for a decade, and it’s not like it’s going to become more convenient nor less expensive as more time passes.  Evelyn is enthusiastic and exceptionally supportive of the idea of me getting out of the apartment and getting into a cockpit.  So, private pilot certificate, here I come.

There are three general aviation airports within reasonable distance of our place: Norwood Memorial (30 minutes southwest), Hanscom Field (35 NW), and Beverly Municipal (40 NE).  There are at four different flight schools at these three airports, all of which seem fine at first glance.  How to choose?  Unfortunately I haven’t met any local pilots yet to get direct recommendations.  But one of the schools advertises aerobatic training and aerobatic aircraft as part of their fleet — and thanks to Doug I’m very interested in aerobatics — so earlier this week I scheduled a “discovery flight” with that company to meet the staff, try out the drive to Hanscom, discuss the curriculum and training plan, and get up in the air.

The weather this morning was cold, windy, and overcast, which meant hardly anyone else was using the sky; there were only two other general aviation planes flying near us in the practice area west of the airport.  I spent most of the flight grinning from ear to ear.  Some of my takeaways:

  • The aircraft (at least the Cessna 172SP that we flew today) has metallic wicks on the rear of some of the control surfaces to dissipate any static charge that builds up during the flight.  Without the wicks, the buildup of electrical potential could cause communications problems.  Neat.
  • Full throttle isn’t necessarily better.  The concept of “cruise speed” on aircraft has always perplexed me; if the plane can fly faster, why wouldn’t you fly faster in general?  Answer: it’s much louder and much less smooth of a ride, not to mention much less fuel efficient.
  • I should expect my instructors always to pretend that the GPS is always broken.  I’m fairly interested in old-school navigation, be it dead reckoning or the use of VOR/DME equipment, so I was worried that everything would focus on GPS.  The instructor assured me that, other than a 30 minute lesson in GPS (“it’s nice to have when the light is fading and you’re lost”), I would get all the old-school navigation I wanted.
  • Speaking of dead reckoning:  After an hour of having me fly in basically Brownian motion (“ok, now make a steep 180 degree turn keeping your airspeed and altitude fixed but without looking at the instrument panel”) the instructor asked “where’s the airport?”  I’m proud to report that my guess was only off by 90 degrees (I said “east”, the correct answer was “north”).

Most flight schools appear to offer a discovery flight of 30 or 60 minutes (today’s was 60 minutes of flight time as part of an overall 150-minute lesson, including the pre-flight briefing and weather analysis, pre-flight inspection, and post-flight briefing, for $200).  In a discovery flight the student gets to perform the takeoff (yay!) and most of the flying, with hands-on practice in basic aircraft handling: roll/pitch/yaw, trim for level flight, coordinated turns, slow flight, and visual references.  I started lessons today thanks to the discovery flight that Anastasia gifted me a decade ago, plus the ongoing encouragement I’ve received from my friends and family:  Thank you.