Jennifer Anastasoff served as the head of people for the United States Digital Service (USDS). She grew that organization from a small team of three to an office of over 200 people in just two years.

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!

Email is the killer app of the Internet. Amidst many sharing and collaboration applications and services, most of us frequently fall back to email. Marc Stiegler suggests that email often “just works better”. Why is this?

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.

In cryptography we typically share a secret which allows us to decrypt future messages. Commonly this is a password that I make up and submit to a Web site, then later produce to verify I am the same person.

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