“I think the thing is that I have to learn to live with this — I can’t just keep expecting, waiting to suddenly get better.” I stopped making plans beyond “rest, walk a little, rest, eat a little, rest…” in achingly slow motion, on a good day I could send an email and talk on the phone to a friend.

It’s not that I gave up hope, it’s just that thinking about any specific hope for the future was just not helpful. Recently, my brother shared a poem that captured this experience well:

My grandmother once gave me a tip:
In difficult times, you move forward in small steps.
Do what you have to do, but little by little.
Don’t think about the future, or what may happen tomorrow.
Wash the dishes.
Remove the dust.
Write a letter.
Make a soup.
You see?
You are advancing step by step.
Take a step and stop.
Rest a little.
Praise yourself.
Take another step.
Then another.
You won’t notice, but your steps will grow more and more.
And the time will come when you can think about the future without crying.

— Elena Mikhalkova, The Room of Ancient Keys

I couldn’t find anything else written by Elena Mikhalkova that has been translated into English. I’d love to hear about it if her books or any of her other poems is ever translated.

Flash CVEs (2001-2009)

I looked at the Common Vulnerabilities and Exposure List (CVE List hosted by Mitre with all reports 2001-2019. I found 1172 Flash Player vulnerabilities, which sounds huge, but in context of vulnerabilities reported in Web Browsers, doesn’t look that bad:

• 1172 Flash Player
• 1999 Internet Explorer
• 2033 Chrome
• 2442 Firefox

Note: these numbers don’t necessarily tell us that Firefox had more vulnerabilities than Internet Explorer. It could mean that Firefox was more rigorously open in reporting vulnerabilities, which seems likely.

Understanding attack vectors

Vulnerabilities in the Flash Player were particularly dangerous because Flash was installed on all of the Web Browsers, so any flaw in Flash was much easier to exploit than a flaw in a specific Web Browser. To understand this, one needs to understand that the primary attack vector enabling a hacker to take advantage of a vulnerability in Flash Player was to create a malicious Flash application or movie that would distract the user while doing something illicit or intentionally trigger a crash and then exploiting that crash to execute native code with access to the user’s machine.

In the larger context of a specific attack, a vulnerability in the Flash Player would typically need to be combined with something else:
* deceptive emails (aka phishing)
* deceptive websites
* “man in the middle” attacks (replace real Web content with malicious content that appears identical)

Categorizing vulnerabilities

I conducted a rough cut analysis of matching terms by reading the list of CVEs and creating categories that might provide instructive value in thinking through how to avoid similar issues in the future.

• 802 memory safety
• 42 other code execution
• 58 XSS, CORS, CLRF
• 61 parsing / validation
• 13 clickjacking
• 91 bypass sandbox
• 105 other

Memory safety (~70%)

The vast majority of issues (“memory safety”) resulted from coding errors, which can now be avoided with modern programming languages. For a long time, we’ve been able to use languages like Erlang/Elixir, Java, Python, Ruby, and Go for server-side coding with memory safety features. Even C++ has language features and libraries (though you must choose to use them). Now, for low-profile client software we can use Rust or WebAssembly when we need something higher performance or less memory-hungry than JavaScript.

Escaping the “sandbox” (~15%)

If we develop code that runs in a Web browser, we can trust the browser’s “sandbox” — our apps can only use a restricted set of APIs. If we’re writing a Web browser or any other Internet-connected software used by humans or machines, then it is a good idea to carefully isolate our code that can access the operating system to write files or make network calls.

From my CVE analysis, coding errors in this category resulted in just over 15% of CVEs (other code execution, bypassing sandbox, and XSS, CORS, CLRF issues). Of course, the biggest thing you can do is not include the code that does powerful things you don’t want to allow. However, sometimes you do need to load and execute a shared library, accessing the filesystem and the network.

Parsing / Validation (~5% / ~15% excluding memory safety)

Parsing and validation of input (mostly reading a file or parameter) is another common coding error pattern which can result in a serious vulnerability. Having to fix these kinds of issues causes me to be very careful when adding parsing code to any app or library. If we exclude memory safety errors, parsing and validation errors are larger than any identified class of error.

Clickjacking and “other”

Clickjacking is noteworthy for anyone developing a client app with extensions where 3rd party developers (or other users via content sharing) can present information to the user and allow interaction. This class of attack uses features that are designed to empower users to present compelling content to be instead used to trick people into doing something unintended. For example, there were bugs that allowed Flash content to overlay other web pages or browser UI, thereby tricking the user into clicking or typing in a way to provide privileged access.

Perhaps “other” deserves a closer look, but I didn’t find clear patterns and suspect that contains many smaller categories.

Parsing is hard

In my experience, many programmers recognize that implementing an extension mechanism that allows for user interaction or providing a “sandbox” for 3rd party code can be very tricky to get right and will exercise great care in writing or using that kind of code. However, I have often interacted with programmers who don’t seem to believe that writing code to parse text is difficult. Writing code that performs the intended action is not hard, but writing code that has no unintended effects requires very careful coding and a little imagination.

Looking toward open source code for some examples to learn from, here are a few examples of URL parsing libraries where bugs were found (and fixed) after vulnerabilities were discovered in the field:

• https://github.com/envoyproxy/envoy/issues/7728 (Envoy proxy)
• https://go-review.googlesource.com/c/go/+/189258/ (Go)
• https://www.cvedetails.com/cve/CVE-2018-3774/ (url-parse Node library)

The results of this analysis were included as part of Code Mesh LDN 19 talk, A landscape of unintended consequences (video, slides). The data and methodology is available at on github: ultrasaurus/flash-cve-analysis.

It was fun to go back in time and recall why Flash was great in 2000, when IE 5.5 had just been released and you couldn’t rely on CSS actually working. In prepping for this talk, I worked really hard to try to express what Web development was like then and why people loved Flash: “200K of cross-platform goodness.” Flash made the Web work for high fidelity interactive graphics 20 years ago, which I think helped drive Web standards to support more than text, images and links.

“We wanted to support all the people on the internet.” It still boggles my mind how we could support low-latency way-back-then and now when computers and networks are faster it seems impossible… sometimes I try to visualize what is happening to the bits as I wait for something to happen. (I really do know why things are slower now, and it’s not just about the tech, but that’s a different story.)

HTTP tunneling worked much better than you would expect… sometimes it’s good to make something work for everyone, even if not optimal.

I fondly remembering Doug Engelbart telling me that his Augment system (built in the 1960s) had more features than Flash Player 6 + Flash Communication Server in 2002. (It’s great when your heroes tell you that your great accomplishments are not all that interesting.) Later, he did acknowledge that making this stuff available to everyone on the Web was “pretty good.” Inspiring widespread adoption, creating an ecosystem is a different kind of innovation.

The thing that makes it an ecosystem is that each essential component can be bought from multiple companies and is available as open source. At first Flash was essential, now much later, Flash doesn’t really matter anymore to the relevance of the RTMP protocol.

Today there are 500M IP camera on the Internet, about the number of people on the Web when Flash Player 6 was released. SmartHome video sensors have insane growth. The future of video is not about how to catch up with latency and resolution of live broadcast TV (though that will happen), it’s about how we can be integrate video streams from new devices, how we can help the machines help the people by creating new applications. Maybe RTMP will be a part of that, what do you think?

I rarely find good resources for learning a new language that are targeted at experienced programmers. So I’ve developed a habit of looking for language koans. Inspired by Ruby Koans, these are unit tests which guide a programmer through basic language constructs by presenting a failing test and let you write simple code to learn the syntax of a language. These tests typically include a bit of text that helps newcomers reflect on what is special and interesting about this particular programming language.

In learning Go, I found cdarwin/go-koans, which helped me to reflect on the philosophy of golang, the Go programming language.

The koans caused me to meditate on the basics, leading me to read more and reflect. While about_basics.go is quick to solve technically, it sparked my curiosity on two points.

1. The uninitialized variable

I really wanted the comments in the go-koans to be a bit more like Zen koans (or Ruby koans), so I wrote these:

// listen to the darkness of an unset variable
// what is the code that is not written?
// consider the emptiness of a string

// create meaning from emptiness
// undefined structure isn't

“Make the zero value useful” —Go Proverbs

It reminds me of the Zen teacup parable. An empty cup has utility, even before it is filled.

2. The implications of a string

One of the most deceptively simple types in modern programming languages is the string. In Go, there is a built-in string type with short, unsatisfying descriptive text.

Strings, bytes, runes and characters in Go explains that strings are a read-only slice of bytes (at runtime). Go source code is UTF-8, so string literals always contain UTF-8 text (except for byte-level escapes.

Strings always cause me to reflect on how memory management works in a language. In my search for basic answers about how and when memory happens in string operations, I read about allocation efficiency in high-performance Go services which includes a nice explanation of heap vs stack memory allocation in Go.

Reflections

At this point, I don’t know what I need to know about this new programming language. I just like to know what the code I’m typing actually does. Learning syntax is boring, so I need to occupy my mind with something more interesting while I practice typing unfamiliar sequences of text. To write good code, I need to know so much more than the syntax, but I need to be careful not get get too attached to certain details. For example, future compiler versions change the patterns of how code is transformed into machine operations. However, if I attach just a little deeper meaning to these syntax constructs and get a feel for what my code ends up doing under-the-hood, I can more quickly understand the implications of the code I write.

When I emerge from these learning meditations and I can finally construct this new syntax without thinking and start to solve actual problems that matter to humans, then I will have created these little trails in my mind that lead to empty spaces, which have shape and meaning, like the Go zero value and the Zen teacup.

The term mansplaining was coined more recently, sparked by Rebecca Solnit’s 2008 essay Men Explain Things to Me. Solnit’s stories present a different perspective from the prevailing narrative that women lack confidence to speak up: perhaps the lack of confidence is not in ourselves but rather in our audience. One must be an authoritative expert on a subject with footnoted documentation before having the right to an opinion, and even then, we may be inaccurately criticized or simply ignored.

It was a few years ago when I realized that I had accepted the status quo. I was on a conference call with two male colleagues. I was caught up in the discussion and hadn’t noticed that I had initially put forth an idea that was then attributed to my other male colleague. Instead of tacitly accepting credit for my idea, he promptly said “I agree, that was a great idea that Sarah had.” A simple correction, said kindly with an edge of humor, honored my contribution while gently chiding our colleague. Most men have the capacity to listen to the words I say and follow the thread of the idea, and some realize that correct attribution is a simple respect that fosters effective collaboration.

A couple of weeks ago, Jen-Mei Wu, Judy Tuan and I were talking about code and sharing stories of our lives. With dark humor, I noted that for some men, it seems that my voice is unintelligible. I know they hear me, since they typically wait till I finish speaking before repeating themselves verbatim as if I had not spoken or asking a less knowledgeable man to explain in more detail. I joked that I needed a personal translator, a man who would attend meetings with me and repeat what I say for some of my colleagues who can’t seem to understand my words.

We wondered if this behavior might stem from the need to compensate for a cognitive disability where some men can hear female voices, yet struggle to discern meaning from sound. Without self-awareness of their own affliction, when they hear the garbled syllables, they assume the woman is not speaking clearly, and so they feel compelled to repeat their understanding of the words. Tech companies might identify men who are thus impaired and offer mansplaining-as-a-service as a benefit to accommodate this peculiar affliction.

I sought a word to describe this new insight about a potential root cause, perhaps a previously unknown form of aphasia where some men cannot cognitively process words when they are spoken by women. It seems important to separate the community service where a man will amplify a women’s ideas by repeating key points with attribution, as distinct from the bizarre echolalia commonly known as mansplaining which may be a further symptom of this affliction.

In reading further on this subject, I discovered some research indicating that there might be a physiological basis for this syndrome. Further study may be needed. Independent of the neurological processes involved, I suggest the word agynephasia to describe this phenomenon.

I urge men to support your colleagues who may be unaware of their disability. Until the tech companies start routine testing for this affliction and providing trained assistants, you can help by learning about the expertise of your colleagues and dinner guests, regardless of their race or gender, correctly attributing ideas, and helping to redirect the discussion if needed.

We’re programmers. We solve problems by focusing on something concrete that can be built with the tools at hand. We focused on increasing diversity in the SF Ruby meetup. By teaching workshops, engaging the local tech companies and all of the people who wanted to help, we moved the needle. Later we expanded to include outreach to other demographics who are underrepresented in tech (which turns out to be most people).

Last week I spoke at a Bridge Foundry event where we announced a new industry partner program. In preparing for this announcement, I spoke to Amanda Cooper (@MandaCoop) on our advisory board. She framed what we do as “you make the road by walking it.”

There was no clear path, but we had ideas that we thought could work. We did the work to implement our ideas. We took a data-driven approach to measuring impact. We open-sourced our process and materials. In doing the work, we created a path that others could follow. Or more accurately, inspired others to help create the path by walking it with us.

Over the years, I’ve watched students become senior software developers. I’ve seen how volunteering at the workshops has caused some ex-programmers to decide to become software engineers again. It’s not all about more diverse software developers — we want everyone to be able to learn these tech skills, if they want to. Coding skills are applicable across many disciplines and can be useful to simply understand the technology that people use every day.

Most students and volunteers are working software developers, and we’re seeing some particular problems in the tech industry where we think we can help.

Lack of good tech jobs

The tech industry has a diversity problem that goes well beyond the “pipeline” problem that can be address with skill training. There seem to be few workplaces where there is real opportunity to succeed based on individual skill and potential.

I believe that most companies genuinely want to create workplaces where people with the right skills and capabilities can deliver business impact. This should be very aligned with business goals. Unfortunately systemic bias gets in the way. There are patterns that need to and can be changed. There are bugs in the system that need to be fixed in order to attract and retain diverse talent.

I see some companies where the environment seems to be different. I hear about companies who want to do better. Help create the path by walking it with some folks who have a lot of experience solving these kinds of challenges: join the Bridge Foundry Industry Partner Program.

XXIX

Traveler, there is no path.
The path is made by walking.

Traveller, the path is your tracks
And nothing more.
Traveller, there is no path
The path is made by walking.
By walking you make a path
And turning, you look back
At a way you will never tread again
Traveller, there is no road
Only wakes in the sea.

― Antonio Machado, Border of a Dream: Selected Poems

However, I knew the characters once and wanted to make my study session more interesting. I had forgotten about half the characters since first studying Japanese four years ago and wanted to review using actual words. If I could learn the characters with the context of real language then I could learn vocabulary at the same time. I wondered if there were a “quick brown fox” (pangram) for Hiragana.

I quickly found いろは (iroha) an ancient Japanese poem:

いろはにほへと
ちりぬるを
わかよたれそ
つねならむ
うゐのおくやま
けふこえて
あさきゆめみし
ゑひもせす

This poem not just an arcane bit of trivia, but a real ABCs of Japanese, where the ordering from the poem is still used today. I found a wonderful video What is “いろは iroha”? that tells the story of this word which means “basic” or “fundamental” in Japanese. I learned that the first 7 characters are used for musical notes (the way we use A-G, in Japanese they use いろはにほへと. I read elsewhere that theater seats are often ordered this way.

I realized that if I could learn this poem, I would also learn other useful aspects of the Japanese language and a glimpse of the culture as well. I wanted to hear it while I studied, and found answers via my new twitter friend Charelle Collett (@Charcol1900)

Here’s someone singing it in a child-like ABCs — no idea what the words on the right are, but this is the very clear to follow along and practice reading while hearing the characters pronounced:

and here’s Hatsune Miku (Vocal software) singing it:

This second one is really interesting since it also shows the evolution of early Japanese script into modern Hiragana and then shows some more variants — here’s some detail on the first three.

1. Man’yōgana: an ancient writing system that employs Chinese characters to represent the Japanese language
2. Chinese Cursive Script from which Hiragana evolved
3. Modern Hiragana

Both the State Dept and Health and Human Services (HHS) are actively working to pilot the software within each agency to foster collaboration within different target communities. Developers at each agency are leveraging each other’s efforts by submitting changes (via pull requests) to a common shared codebase (hosted on github).

It’s exciting to see this cross-agency collaboration through open source. The software is designed to help agency employees collaborate across team boundaries, and it’s wonderful that we’re doing that with the software itself using the entirely different mechanisms of open source.

I’m relatively new to the project and still learning about it myself, but would welcome volunteer contributions — or feedback on how to make the project more welcoming to people who want to help. It uses Nodejs and Sails with Backbone on the front end, and we’ve just started writing some Chef recipes for automated deployment. There’s a lot of low-hanging fruit in the github issues list.

Would love to hear what you think about this project specifically or government open source in general!

As a citizen, I believe open source makes best use of our tax dollars:

• Leveraging open source tools & libraries is not just about saving licensing costs, it saves time. We can evaluate a library or tool by actually using it, without up-front analysis and a time-consuming procurement process.
• New contractors can pick up a project easily, which will drive competition and reduce switching costs.
• Different agencies in federal, state and local governments can easily leverage each other’s code through coder social networks like github. This happened recently with the 18F Answers platform, based on Honolulu Answers, developed by Code for America, and now being leveraged to improve the immigration experience (USCIS).

As a developer, open source encourages me to apply best practices: effectively communicating the impact of the code I write making choices that will yield high quality, secure code, and embracing volunteer contributions that are aligned with the project’s mission.

On a personal level, it is an amazing professional development opportunity. A long time ago, a conversation with Rob Savoy, forever changed how I thought about the personal impact of developing open source software. He said that, with rare exception, all the code he had written was available to him in any future project. Imagine if that were true for me… if the source code of After Effects, Flash video, and Shockwave (or their open source equivalents in a parallel universe) were available on my next project.

This is even more compelling for the now-defunct proprietary software I’ve create. Adobe ScreenReady turned any document into a high quality image with anti-aliasing and alpha channel (turning the “paper” into transparency). PACo/QuickPICS enabled long-format synchronized audio-video off CD-ROM (which at that time had a comparable bandwidth to a 14.4 modem). Both these products didn’t make sense to continue from a business perspective, but had passionate customers and could have evolved into powerful tools or libraries accelerating innovation in both private and public sectors.

At 18F the software we develop is for the people and by the people. Open source gives us a firm foundation to make a lasting impact for our country and for the world.

Before You Start

Make sure the women and people of color on your team already are happy. See if you can find out if is any aspect of your current workplace or team that might create a hostile or unproductive workplace for any team member. Fix that without making it the responsibility of minority folks. If your team is bigger than 2-3 people and you don’t have any women or people of color, be aware that you may have teammates who would alienate the person you are trying to recruit. Develop stated values. Publish a code of conduct. Create ways you can put yourselves in a diverse crowd with customers or community events, and talk to your team about how to be open and respectful to people who are different than they are.

Imagine Your Dream Team

Brainstorm 10 women or people of color that you would dream of hiring. People who would bring incredible talent, skills, energy and enthusiasm to your team if you could somehow inspire them to come work with you. Play the #one4one game with your team.

There are a small percentage of software engineers who are women, but quite a large number of them. Relative to the number of qualified women engineers in your region, the number of positions you have open to fill is tiny. Spend a bit of time doing web searches or just reflect on people you know or have heard about and put together a list of 10 amazing women and people of color who would be part of your dream team — if you could hire anyone who would it be? Look at the people who speak at conferences centered around your technology, blogs, books, etc. Look to your local meetups. If you have budget for relocation, broaden your search. Once you have your list of 10, methodically go through the list and try to meet each of them. Follow them on twitter, go to where they are (meetups, conferences), reach out and have coffee or lunch. Start a conversation about shared interest in technology. Seek out their opinion on something they are expert at. See if they are happy in their job. Would they consider a new one? If not, ask who they know who would be good. Do not qualify your request with gender or race.

If you are really lucky and good, one of your dream team will come work with you. If not now, sometime in the future. You might find a new advisor or a new friend. You have definitely expanded your network, and if you show up at events where women and people of color are speaking, who you admire and are relevant to the position you are hiring, your next team member may be in the audience.

Important Details

If you want a great team, you want to have a tough decision to make between two or three amazing candidates. Do the hard work. Get the details right.

Post the Job

A public link is the easiest was for people to help you recruit. It’s amazing how many people post their job late in the recruiting process or not at all.

Write a Good Job Description

Think about why you want diversity and add requirements that will find those people. For example, if you the person will be responsible for hiring, consider adding a requirement “experience leading diverse teams.” You are more likely to attract diverse talent and find someone who has a network of diverse talent, in addition to actually finding someone to lead the team you want to have.

Consider what you actually need in someone performing the job and include that in the job description. Give thought to the words you use. Find a few people with different backgrounds who are qualified for the job give you feedback on the job description.

Confidence != Competence

Interview for skills. Look for evidence they have done similar work. Ask about what they did individually to lead to outcomes in past work. Don’t get sucked in by bravado from people in the majority crowd. Don’t mistake quiet for weak. Watch your own biases. Be on the lookout for greatness that doesn’t look like you.

Always Be Recruiting

Get involved in a local meetup. If there aren’t diverse speakers, talk to the organizer and see if you could help make that happen.

Host a RailsBridge workshop, ClojureBridge workshop, or make a *Bridge for your language or framework. Host
Women Who Code hack night or study group, maybe Girl Geek Dinner. Even if you don’t find engineers from these groups who want to work for you, many women will be more likely to work for a company that is actively trying to be part of the solution.

If you can hire less experienced talent, recruit at women’s colleges (in the SF Bay area, I’ve heard great things about Mills, a local women’s college where the CS dept has a great reputation) and look for colleges which have a good diversity track record, like Harvey Mudd.

Background

At Blazing Cloud, I hired over 20 people with 50-50 gender balance, but I’m most proud of the other kinds of diversity — people with and without CS degrees, early experience in Java, C and SmallTalk, sailors and farmers, awkwardly dressed and stylishly hip. Whenever we did user research, chances are someone on the team knew a group in our target audience. Our diversity fostered creativity and was a key component to our success.

These tips are based on over 20 years of experience building technical teams. I wasn’t born knowing how to recruit women because I’m female. Most of the engineers I’ve worked with are white men, so I started with the same challenges as everyone else. Over the last ten years, I worked to develop a network and I have repeatedly applied these simple, yet time consuming techniques. You can too.