I didn’t really know it was a skill to have: to listen to people and very immediately draw something related to what they were talking about and present their ideas in a visual way.

Sometimes this is also called making “sketch notes.” He goes on to talk about a general phenomenon where you discover that you can do a thing that you never thought was a thing:

There are so many things that, if you are not given the opportunity, if somebody doesn’t see that within you, or thinks maybe you should just come along and try this thing that I’ve organized, there are things that you don’t even realize that you can do.

I think there are two parts of this that are transformational, that I’ve experienced myself and occasionally been able to spark in others.

1. Naming a pattern of actions or behavior: this is an act of creating that is rare and powerful. Discovering something is a skill that one can be good at and apply with intention is aided by that skill having a name.
2. Recognizing the spark within someone else: seeing a capability, especially latent potential, within someone and naming it, inviting that person to experiment with a new skill, encouraging creative action in the world.

There should be a word for the making of words that is more than coining a term, where the naming of a thing helps people do (or not do) whatever that is.

I’ve thought a lot about how the term mansplaining has helped a generation notice and often modify behavior. I learned about restorative justice as a framework for transforming guilt into responsibility. I remember when, at an early RailsBridge workshop, I applied lessons from my kid’s preschool to the challenge of how to teach without grabbing the keyboard (“Use your words”).

I love the idea of a word for a skill providing a path to developing that skill, connecting to a community, and finding paid work.

The whole podcast with Dan Berry and B. Mure is worth listening to for any creative folk or if you enjoy comics or visual storytelling and want a glimpse of that world.

https://bmuredraws.com/

Rust empowers you to reach farther, to program with confidence in a wider variety of domains than you did before. — Rust Language Book forward

Overview themes

2020 roadmap: finish what’s started, fulfill the promise

2021 edition: scalability – Can newcomers to Rust create a real-world, complex system without recreating basic components or contributing to the language itself?

• more scalable systems written in Rust
• experienced C/C++ engineers can easily transition to Rust
• more scalable ecosystem
  • commonly needed libraries are available
  • new engineers can easily become contributors

Keep doing

• Tooling is great! rustup toolchain, feature flags, online/offline docs make it easy to experiment with new Rust/crate features, even as a relatively new Rust programmer.
• Transparency (like this call for blog posts, RFC process including roadmap)
• Focus on good docs & good error reporting is incredibly helpful. Keep iterating on this!

Feature requests

• safety beyond memory safety and concurrency. For example: URL parsing should be in std have a shared implementation that supports common use cases — it’s risky for Internet apps to not have a stable, well vetted URL parser, why are there three? (That’s a rhetorical question. I know why, but don’t think there need to be. See twitter discussion [Update 12/16/2019: I’d like to see convergence in URL parsers (or perhaps a shared common library) the way the community seems to be converging around serde.]
• async all the things! I think this is already the plan. I look forward to async I/O (network and files) to be supported in the std library. I appreciate the thoughtfulness about safety, factoring out useful core concepts (like Pin/Task), and ensuring compatibility with Futures and Tokio crates. Consider other async use cases: GPU, OpenGL
• lifetimes visualization would accelerate learning curve on resolving compiler errors, good ideas in this thread

Slow down to speed up

In my experience writing documentation often uncovers design issues and bugs. RFC template has a guide-level explanation section, which is great, and taking that one step further to writing baseline docs before declaring a feature “stable” would create positive pressure for community focus. Some ideas for process improvements…

• A crisp “definition of done” could help focus the community. Consider adding requirements to releasing ‘stable’
  • RFC updated to reflect what was completed and is still open
  • stable reference docs are complete or include link to RFC
• Consider WIP limits: how limiting work-in-progress increases speed

It seems in keep with Rust values to create a strong incentive to support contributing writers who are working to take the feature over-the-line and encourage new engineers to contribute. It is easier for new contributors to work with APIs that are documented or clearly dive into a work-in-progress, aware that they are contributing to finishing something.

Other Improvements

• Documentation shouldn’t require deep knowledge of Rust (example: https://stackoverflow.com/questions/56402818/how-do-i-interpret-the-signature-of-read-until-and-what-is-asyncread-bufread-i/56403568#56403568)

Background

The reason I’m learning Rust is that I am experienced engineer with a need to write performant, low-profile client/server code. I’m excited about the idea of writing one body of code that can (potentially) work across native desktop, mobile, servers… and with cross-compilation to WebAssembly (Wasm), also browsers and edge servers.

Arguably, C works for all my needs, it even cross-compiles to Wasm. I want to like Rust better. I do in theory, but in practice, it’s got a lot of sharp edges (which is saying a lot when comparing it to C).

Updated Dec 2019 to modify the introduction, so excerpt is useful (if rust2020 summary post is ever updated. Original text below:

answering the Rust programming language call for blog posts as input to the 2020 roadmap

Caveat: I am new to Rust. There’s probably stuff I don’t even know about that is more important than anything here. This is just me doing my part to give back to the awesome Rust community.

Requires food processor to grind up various ingredients.

Ingredients

Nut loaf

1 1/4 cups (180 g) nuts (raw or roasted cashews, raw walnuts, raw pecans)
1/4 cup (33.5 g) sunflower seeds (or more cashews)
2 tsp oil (or 1/4 cup broth)
1 cup (160 g) chopped onion
4 cloves of garlic chopped
1 cup (96 g) chopped mushrooms (shitake or hen of the wood)
1 cup (140 g) cubed butternut squash
1 tsp each thyme, sage, rosemary, oregano
1 tsp smoked paprika
1/2 tsp black pepper
1/4 tsp each cinnamon and nutmeg
1/2 to 3/4 tsp salt
2 tbsp soy sauce or tamari
2 eggs (or 2 flax eggs for vegan)
2/3 cup (81 g) breadcrumbs

Sauce

1/4 cup roasted red peppers
1.5 tbsp soy sauce/tamari (or use 1/4 tsp salt + 1 tbsp broth for soyfree)
2 tbsp maple syrup
2 tsp apple cider vinegar
1/2 tsp (0.5 tsp) garlic powder

Instructions

Preheat the oven to 350 degrees F.

1. Toast the raw nuts and sunflower seeds in the oven at 325 deg F (160 C) for 5 mins.
2. Food processor: pulse nuts and seeds to a somewhat coarse meal
3. In skillet over medium heat for 2 mins
   • oil or broth.
   • onion, garlic and a pinch of salt
4. Add mushrooms and a pinch of salt and cook until some golden edges. (3-4 mins)
5. Add butternut squash and mix in. Add a splash of water, cover and cook until the squash is tender.
6. Mash and transfer to a bowl.
7. Add in the spices, salt and mix in.
8. Add the chopped nuts and seeds, soy sauce, eggs, breadcrumbs and mix well.
9. Taste and adjust salt, herbs and flavor. ** The flavor will get more pronounced on baking. If the mixture is too wet, add a tbsp or so flour. You want it to be just slightly sticky. If too dry or crumbly, add a splash of broth. If you like sweeter, profile, add a tbsp of tomato paste or some chopped dried fruit such as dried cranberries or apricots.
10. Transfer to a parchment lined pan. (I used lightly oiled cookie sheet.) Lightly press to shape. Do not pack too much.
11. Bake for 25 to 30 mins.

Sauce:
1. Blend roasted red peppers into a smooth paste
2. Mix the rest of ingredients in a sauce pan over low heat for 15-20 minutes.
3. Taste and adjust as needed.

Take the loaf out of the oven. Spread the glaze over the loaf and then bake again for 20 to 30 mins. Let cool for 15 mins before removing from the pan. Then cool completely before slicing. Serve with gravy or cranberry sauce or both!

If we believe that a particular person is trust-worthy, to trust their digital representation, we somehow need to identify that some bits that travel across wires or air actually originate from that person.

In today’s Web, we have a network of trusted authorities, typically my social network or email provider creates a relationship with me and I prove my identity with a password. The challenge is that they also house all of my personal data — could there be a way for me to identify myself without making myself vulnerable to the whims or errors of these companies? New models are emerging.

• Mobile Drivers License: British Columbia and U.S. Commerce Department’s National Institute of Standards and Technology (NIST) have funded development of a new kind of digital ID. Folks are working on ways to validate the identity and “claims” of an individual. This is not just for fraud detection. It also potentially protects the privacy of an individual, in contrast to a traditional drivers license, where I must reveal my home address while proving that I’m over 21.

• Decentralized Identifier (DID): a standard way for individuals and organizations to create permanent, globally unique, cryptographically verifiable identifiers entirely under the identity owner’s control. Sovrin Foundation Whitepaper

• With blockchains, every public key can now have its own address, enabling a decentralized self-service registry for public keys.

• Trust without shared secrets. In cryptography we typically share a secret which allows us to decrypt future messages. But the best way to keep a secret is not to tell anyone. We can actually verify a secret without knowing it. Zero-knowledge proof

• Object capabilities. In the real world we have physical objects that we can transfer for very specific authorization (e.g. a key to your car) whereas digital keys must be kept secret to avoid replication — what if authorization were couple with objects in the digital world. Some basic examples illustrate the framework, discussed further in false dichotomy of control vs sharing.

Full notes from IIW 26: PDF Proceedings, wiki

More about IIW

The Internet Identity Workshop (IIW) gathers experts across the industry to solve this particular question. People share their understanding of the problem and potential solutions in this unique unconference twice a year. I always learn unexpected and useful technical solutions, and more importantly gain a deeper understanding of this challenging problem of identity.

Attention to detail

Making software feel effortless isn’t effortless. I was impressed by the EmberJS team focus on backwards compatibility and agility, as well as the impressive performance of glimmer components. They were doing the kind of important, detailed work that doesn’t easily fit into a sound bite.

I told Leah that it reminded me of the work we do at Bridge Foundry, where significant positive change is composed of so many small actions. Leah echoed back all my feelings in her concise reply: “Reality is boring and full of hard work”

As I prepared for this talk, I realized that I don’t actually believe that reality is boring. Reality is messy and difficult. I thought about the hardship of when my kid was a toddler, of crumbs and sticky i-dont-even-know-what-that-was, being so bone tired all the time and also the wildflower in the kitchen and that moment of sun shining through the window casting a shadow on the wall that was so beautiful and I might not have noticed if not for a three year old that noticed everything.

So when I listened to the 2016 talk where Yehudah said that “instability is a drag on innovation” (Stability without stagnation, slide 5), I realized that we need to talk more about the people who are slowly and steadily fixing the broken things in this world. I was reminded of my colleagues in the government, both the techies who served a limited term, and the folks who dedicate their lives to service.

Small fixes to big problems

In the closing keynote for EmberConf 2019, I spoke about the parallels between the work of building (and fixing) software systems and the people systems that seem to rule our lives.

This talk was very much in the context of the Ember community, in honor of their hard work making good software that works well. I hope my words will inspire new voices to tell their own stories about what works well, of their own moments of mundane heroism or those they witness.

Notes

Below are some notes that I prepared in advance, that aren’t exactly what I said, and some things that I cut from the talk, since I always have more stories I’d like to tell.

Intro

At EmberConf 2019, Yehudah Katz in the opening keynote talked about the decisions we make, about how they encode our values and communicate to the world what we truly believe. Later in the day, Melanie Sumner talked about the things we choose to put in our software that no one asks for because we’re professionals.

We write tests and structure our websites for accessibility because we want our software to work and we choose frameworks that make our work easier. We choose to use the tools that give us power to move fast and make great things.

We live in a world where hype eclipses reality. You know how it goes… that new shiny thing that was invented yesterday makes headlines. Often when we put in the effort to make software that works well that doesn’t sound so exciting.

Maybe you have experienced that time when some heroic team worked weekends and nights to deliver in time and save the company, maybe you were even on one of those teams, I know I was, and at the time, sometimes I didn’t notice another other team that delivered solid code on time with no fuss. These days I think a lot about what we consider to be heroic.

Heroes are born through the stories we tell. We have the opportunity to define what we consider to be legendary. We each can decide what we value, the stories of success that we choose to tell.

Reality is messy. Designing and building things that are easy to use and work well is hard. It seems like people don’t want to hear about all the boring details. I’ll tell you a secret. The details aren’t boring. It’s just sometimes we need to work inside a broken system, or one that isn’t finished yet…. Reality is awesome, but things are little broken right now, things we see on the news, on twitter, things I can’t find in the Ember docs…

I joke, but sometimes it’s hard to know what to do.

Sometimes I just feel like reality is broken. This isn’t what I signed up for. This isn’t how they told me it was going to be… but I’m all grown up now, and I’ve picked up some techniques I’d like to share, about how we can change the rules

Today I’m going to share a few stories, a few details that I consider epic. And with these tales, I will share a very basic story of software engineers doing the thing we know how to do. Solving problems, shaping reality into something usable and practical. Because the world needs our skills.

Additional Notes, things I didn’t say

Abstractions make something more easily consumable — what are the essential things, or in a different context, the essential things?

What is success? have I adopted the mannerisms of the patriarchy? “Step forward, step back”

Do your homework! “This entire black history month has been like a terrible sociology 101 class where no one did the reading.” — Clint Smith

Alternate Conclusion

You’ve heard a lot of people here on stage say things. I’d like each of you to think about the stage upon which you live your own life. Each one of us has the power to change the world. In fact, we have no other option. With every word and action, we make change.

The world is pretty strange right now. People are divided. People are frustrated. No matter what side you are on, living in the world today, I think we can all agree that reality is broken. However, small actions can build on each other. Our presence has ripple effects that we rarely consider.

Who has the power to create this reality we live in? As it turns out, we all cooperate in making it so.

There’s a larger concept in this mythology about power, which does not necessarily imply evil. The artifacts and tools that we create have power and purpose. In our modern world, open data and open source software can be powerful forces that create positive impact. With open source software, freely distributed libraries and applications influence behavior, affecting properties of the systems that rule our lives. By making certain things easy for other software developers, one small piece of code can have outsize effects on unrelated commercial software. Open and easily accessible datasets can create positive economic impact that can be more evenly distributed than investments of capital.

If you don’t know the story, or if it has been a while, you can catch up on the lore, reading Tolkien Gateway’s background on the Ring Verse or listen to Tolkien reading the Ring Verse on YouTube.

Tolkien’s reflection on power

Tolkien’s ring mythology aptly illustrates that to exercise power, one must give it away (and risk losing it), which he explains in one of his letters. Dr. Rhona Beare’s correspondence led Tolkien to elaborate on the rings of power as a mythical representation of power or, in his words, potency:

The Ring of Sauron is only one of the various mythical treatments of the placing of one’s life, or power, in some external object, which is thus exposed to capture or destruction with disastrous results to oneself…

a mythical way of representing the truth that potency (or
perhaps rather potentiality) if it is to be exercised, and produce results, has to be externalised and so as it were passed, to a greater or less degree, out of one’s direct control. A man who wishes to exert
‘power’ must have subjects, who are not himself. But he then depends on them.
— 14 October 1958 [1]

Whether it is capital investment, the intellectual property of source code, knowledge that you have collected as data or a small golden ring, you can amplify your power by giving it away, but then you must rely on others. Like Frodo, we can all exercise free will in deciding what to do with the power we are given. Destroy the ring, keep the elven chain mail shirt, go adventuring or enjoy our home in the shire. We decide.

[1] originally published in a booklet, later in The Letters of J.R.R. Tolkien, pdf)

I work in the tech industry.

I started programming when I was twelve. My first commercial software was a Mac application. People bought our software and we sent them a box with a paper manual and some floppy disks. I thought sexism was something I would only experience from old men and young jerks. There were a lot of messed up things in the world, but on this point I thought my generation was cool.

Now I work on distributed systems. People fill out a web form and enter their credit card and then just start using our software. It runs 24×7 on computers all over the world.

We write good code. We have tests that run automatically when we change anything, and extra checklists when we make something new. We still write bugs, and even if our code were perfect, it runs on hardware that can fail. So we create data centers with redundant systems, and just in case there’s a storm or earthquake, we run some more copies of the software on the other side of the planet. We do all that work, and still, we prepare for a production outages — that’s what we call it when things are so bad that people will start noticing. It’s inevitable. It happens. In fact, it happens so much it’s routine. We prepare. We create systems to alert us as early warning signals, so we can do something to avert catastrophic failure.

No matter how much we prepare. No matter how hard we work. No matter how brilliant we are at writing code. It happens.

By the time there’s a production outage, We’ve already worked through all the solutions in the standard playbook and nothing worked. Maybe we’ve already looped in a few colleagues who happen to be awake or nearby. We start improvising. We try anything that is both fast and safe. As we pull in some experts, we hope we’ve written all the important things down.

Afterwards, we’ll do a root cause analysis. It could be a mistake we made 6 months ago that’s been quietly corrupting data. Maybe we made an incorrect assumption, or some other system changed and we weren’t notified. Sometimes we could have prevented the problem. Sometimes the root cause is entirely outside of our control.

Sexism is like a production outage.

We learn to expect it. We create systems that mitigate risk. We learn the rules. We study the written laws and policy, because we find that the unspoken rules we learned as kids don’t make any sense. Guidelines about appropriate behavior box us in so tightly we can’t actually get anything done. Sometimes you can ignore the rules.

If you have the privilege of working with men who will respect you, it can work pretty well to pretend these unwritten rules don’t exist. If you want to move to a new team or a new position, you make a judgement call: is the opportunity worth the risk?

There are places I won’t work. Being part of the next unicorn startup isn’t worth the kinds of production outages I would expect there — it’s too disruptive to get any work done.

To be successful in the software industry, we need to take risks — make new software, work with new teams. Men take risks too and can experience their own production outages. And I’m sure I can’t imagine your situation, but from what I’ve observed in the United States, there’s a class of privileged white cis men where failure is a sign of positive risk taking. For blacks and latinos, it seems that failure is more often perceived as failure, or condescendingly, as a lack of preparation that is not their fault. Asian men seem to have fewer production outages in their early careers, then at some point they stop advancing and hit the bamboo ceiling.

I’m not sure the tech industry is really worse than any other place to work, but it does seem different. I wonder if its because many of us were like me. I expected it to be different. When I encountered obstacles, I just worked harder. I thought everyone was held to the same high standards, but when I look back, I’m not sure that’s true. If you have to defend your ideas and plans more than your colleague, that slows you down. If you don’t ask permission, it’s more likely you will be held accountable for your failure, so you have to make sure you don’t fail. We need to take risks to do great things, but for some of us, there are more risks and the risks are bigger.

The “leaky pipeline” is well-documented. Through my own lived experience and hundreds of women I’ve known as fellow travelers in this strange world of the tech industry, I see patterns that seem to be invisible to most of my male colleagues. This metaphor of the effects of sexism as a production outage helps me develop strategies and advise other women when they face obstacles. If there is only one woman on a team, it’s hard to tell the difference between sexism and incompetence. Is she being treated differently? Did he just make a mistake? The research is interesting, but when it happens to you, it doesn’t matter. You can do root cause analysis later. Right now, you need to put your life on hold and deal with a production outage.

On today’s Friction Podcast, she talks with Bob Sutton about fixing government friction

I had been a Presidential Innovation Fellow in 2013, living through a government shutdown and witnessing the failure of healthcare.gov. Then hearing about the slow and steady work that revived it, over a matter of months to a functioning website that allowed people to signup for services that they needed.

Later, when I was at 18F, I collaborated with Jennifer on a few projects. We worked behind the scenes to bring stories of results to the tech folks in San Francisco and elsewhere across the country.

In those early days, before the USDS had a website, I don’t recall the formal statement of values that she talks about on the podcast. I worked closely with many of the folks at USDS and these values were evidenced in the work:

• Hire and empower great people.
• Find the truth, tell the truth.
• Optimize for results, not optics.
• Go where the work is.
• Create momentum.

Maybe they were on the wall somewhere at USDS HQ when I was there for a meeting or just to unwind with people facing the same tough challenges. I do remember the hockey table and that room with the wires in the old townhouse where Teddy Rosevelt used to live with his family. Working in spaces where great history happened couldn’t feel more surreal than trying to figure out if it was really true that A/B testing was illegal.

In the interview, Jennifer talk about how people would say that “in government, we’re not allowed to break the rules…” However, a lot of time it was how the rules were interpreted: “if it doesn’t explicitly say something is possible, than it’s not possible. And that’s just not the case.”

But you can’t just reinterpret things by yourself. We needed technical folks who could work with lawyers and policy experts, doing the challenging work of figuring out a solution that would work and was legal. I have great respect and empathy for the government workers who would routinely say “no” out of fear. It is pretty scary to realize that something you might do in the normal course of your work might actually break a law, which could literally cause you or your boss to be called in front of Congress to explain your actions.

“There’s very little room in all of this for a hero narrative,” she says in the podcast. We accomplished much by giving credit to our government colleagues who stepped up and took a leadership role in this work. We were temporary employees. We could go back to our easy tech jobs, and these folks would need to continue the work. There’s a different kind of hero narrative, which requires each of us to step up in the moment, say the thing in the meeting that no one wants to say, or ask the naive question, or simply read a thousand pages of regulation until you find that one clause that let’s you do the thing. You perform the everyday heroics that let you try something new, and that sets a pattern for you and your colleagues, and future generations of government workers, to be empowered to effectively help the people they serve.

Jennifer Anastasoff is my kind of hero.

Listen to the full interview with Jennifer Anastasoff and hear about the everyday heroics of the how people really make history.

p.s. The work continues. Consider applying as an Innovation Fellow — deadline is July 6th!

Digital communication is fast across distances and allows access to incredible volumes of information, yet digital access controls typically force us into a false dichotomy of control vs sharing.

Looking at physical models of sharing and access control, we can see that we already have well-established models where we can give up control temporarily, yet not completely.

Alan Karp illustrated this nicely at last week’s Internet Identity Workshop (IIW) in a quick anecdote:

Marc gave me the key to his car so I could park in in my garage. I couldn’t do it, so I gave the key to my kid, and asked my neighbor to do it for me. She stopped by my house, got the key and used it to park Marc’s car in my garage.

The car key scenario is clear. In addition to possession of they key, there’s even another layer of control — if my kid doesn’t have a driver’s license, then he can’t drive the car, even if he holds the key.

When we translate this story to our modern digital realm, it sounds crazy:

Marc gave me his password so I could copy a file from his computer to mine. I couldn’t do it, so I gave Marc’s password to my kid, and asked my neighbor to do it for me. She stopped by my house so my kid could tell her my password, and then she used it to copy the file from Marc’s computer to mine.

After the conference, I read Marc Stiegler’s 2009 paper Rich Sharing for the Web details key features of sharing that we have in the real world that are illustrated in the anecdote that Alan so effectively rattled off.

These 6 features (enumerated below) enable people to create networks of access rights that implement the Principle of Least Authority (POLA). The key is to limit how much you need to trust someone before sharing. “Systems that do not implement these 6 features will feel rigid and inadequately functional once enough users are involved, forcing the users to seek alternate means to work around the limitations in those applications.”

1. Dynamic: I can grant access quickly and effortlessly (without involving an administrator).
2. Attenuated: To give you permission to do or see one thing, I don’t have to give you permission to do everything. (e.g. valet key allows driving, but not access to the trunk)
3. Chained: Authority may be delegated (and re-delegated).
4. Composable: I have permission to drive a car from the State of California, and Marc’s car key. I require both permissions together to drive the car.
5. Cross-jurisdiction: There are three families involved, each with its own policies, yet there’s no
   need to communicate policies to another jurisdiction. In the example, I didn’t need to ask Marc to change his policy to grant my neighbor permission to drive his car.
6. Accountable: If Marc finds a new scratch on his car, he knows to ask me to pay for the repair. It’s up to me to collect from my neighbor. Digital access control systems will typically record who did which action, but don’t record who asked an administrator to grant permission.

Note: Accountability is not always directly linked to delegation. Marc would likely hold me accountable if his car got scratched, even if my neighbor had damaged the car when parking it in the garage. Whereas, if it isn’t my garage, bur rather a repair shop where my neighbor drops off the car for Marc, then if the repair shop damages the car, Marc would hold them responsible.

How does this work for email?

The following examples from Marc’s paper were edited for brevity:

• Dynamic: You can send email to anyone any time.
• Attenuated: When I email you an attachment, I’m sending a read-only copy. You don’t have access to my whole hard drive and you don’t expect that modifying it will change my copy.
• Chained: I can forward you an email. You can then forward it to someone else.
• Cross-Domain: I can send email to people at other companies and organizations with permissions from their IT dept.
• Composable: I can include an attachment from email originating at one company with text or another attachment from another email and send it to whoever I want.
• Accountable: If Alice asks Bob to edit a file and email it back, and Bob asks Carol to edit the file, and
  Bob then emails it back, Alice will hold Bob responsible if the edits are erroneous. If Carol (whom Alice
  may not know) emails her result directly to Alice, either Alice will ask Carol who she is before accepting
  the changes, or if Carol includes the history of messages in the message, Alice will directly see, once
  again, that she should hold Bob responsible.

Further reading

Alan Karp’s IoT Position Paper compares several sharing tools across these 6 features and also discusses ZBAC (authoriZation-Based Access Control) where authorization is known as a “capability.” An object capability is an unforgeable token that both designates a resource and grants permission to access it.

I missed Kazue Sako’s Zero Knowledge Proofs 101 presentation at IIW last week, but Rachel Myers shared an impressively simply retelling in the car on the way back to San Francisco, which inspired me to read the notes and review the proof for myself. I’ve attempted to reproduce this simple explanation below, also noting additional sources and related articles.

Zero Knowledge Proofs (ZPKs) are very useful when applied to internet identity — with an interactive exchange you can prove you know a secret without actually revealing the secret.

Understanding Zero Knowledge Proofs with simple math:

x -> f(x)

Simple one way function. Easy to go one way from x to f(x) but mathematically hard to go from f(x) to x.

The most common example is a hash function. Wired: What is Password Hashing? provides an accessible introduction to why hash functions are important to cryptographic applications today.

f(x) = g ^ x mod p

Known(public): g, p
* g is a constant
* p has to be prime

Easy to know x and compute g ^ x mod p but difficult to do in reverse.

Interactive Proof

Alice wants to prove Bob that she knows x without giving any information about x. Bob already knows f(x). Alice can make f(x) public and then prove that she knows x through an interactive exchange with anyone on the Internet, in this case, Bob.

1. Alice publishes f(x): g^x mod p
2. Alice picks random number r
3. Alice sends Bob u = g^r mod p
4. Now Bob has artifact based on that random number, but can’t actually calculate the random number
5. Bob returns a challenge e. Either 0 or 1
6. Alice responds with v:
   If 0, v = r
   If 1, v = r + x
7. Bob can now calculate:
   If e == 0: Bob has the random number r, as well as the publicly known variables and can check if u == g^v mod p
   If e == 1: u*f(x) = g^v (mod p)

I believe step 6 is true based on Congruence of Powers, though I’m not sure that I’ve transcribed e==1 case accurately with my limited ascii representation.

If r is true random, equally distributed between zero and (p-1), this does not leak any information about x, which is pretty neat, yet not sufficient.

In order to ensure that Alice cannot be impersonated, multiple iterations are required along with the use of large numbers (see IIW session notes).

Further Reading

• Comparing Information Without Leaking It Ronald Fagin, Moni Naor, Peter Winkler, 1996.
• The Knowledge Complexity of Interactive Proof-Systems: original 1985 paper by Shafi Goldwasser, Silvio Micali, and Charles Rackoff
• How to Explain Zero-Knowledge Protocols to Your Children Quisquater, Jean-Jacques; Guillou, Louis C.; Berson, Thomas A. (1990). Advances in Cryptology – CRYPTO ’89: Proceedings. 435: 628–631.
• Applied Kid Cryptography or How To Convince Your Children You Are Not Cheating Moni Naor, Yael Naor, Omer Reingold, 1999