Sarah Jamie Lewis announces her candidacy for the Major Grants Review Committee

Governance
1

Dear Zcash Community,

I am posting here today to formally announce my candidacy for the Major Grant Review Committee.

Some of you will know me from my work as the Executive Director of the Open Privacy Research Society, a Canadian research non-profit that works with marginalized communities to build better technology. You may have heard about my involvement disclosing critical cryptographic vulnerabilities in e-voting software used in Switzerland and Australia. I’ve also been contributing and actively researching privacy and security issues in zcash related projects.

I began my career as a computer scientist for British Intelligence and spent a number of years working as a software-turned-security engineer for Amazon. I went onto work as an independent privacy researcher investigating everything from dark web deanonymization, to sex tech, to children’s toys. After publishing Queer Privacy in 2017, I became convinced of the need for a group that works solely with targeted communities to build technology focused on their risk models, and as such I have spent the last few years building a non-profit from the ground up.

I am announcing my candidacy today because the world needs censorship resistant, private transactions. The communities I live and work in need financial privacy. I believe that zcash has a rare combination of robust technology, a community of amazing technologists, and the beginnings of an ecosystem that can deliver on that vision.

I believe that my strong technical background and critical voice, combined with my experience building and managing a non-profit society can serve that vision well as a member of the Major Grant Review Committee.

Which brings me to my platform: Financial Privacy

  • Financial privacy demands a large number of active participants. Preference should be given to funding projects that will expand the number of ways that zcash can be used and the number of people who can use it. Projects must seek to extend their reach beyond the traditional crypto-sphere and into civil society, the arts, community support, social enterprise and activism.
  • Financial privacy demands a vigorous commitment to privacy at all levels of the stack. While security and privacy can never be a primary feature they are critical to success of the vision. I would strongly argue for the establishment of strict secure development standards and policies to be applied across all ecosystem projects at all stages of development. I would fight to ensure that the risk models of over-policed, over-targeted communities are at the forefront of such consideration as I believe the security of such communities is essential to the success of the vision.
  • Financial privacy demands transparency. After all, the thing you are supposed to be decentralizing is power. I am not a person who trusts easily nor do I think you should invest your trust in me without strict safeguards. If elected to serve on the crucial inaugural term I will seek to implement policies that demand intense scrutiny into committee decisions and grant outcomes. I would ensure the committee members are compensated fairly for the work they undertake while also ensuring that such compensation is public and subject to community review.

Disclosure: Last year Open Privacy was fortunate to receive a donation from the Zcash Foundation which we have so far used further our efforts building usable technology. In the event I was elected to serve on the committee I would excuse myself from any votes concerning any potential future funding that Open Privacy might apply or be considered for - both as a member of the committee and in my role as Executive Director at Open Privacy.

Thank you for your consideration, and I will endeavour to answer all questions posted to this thread regarding my candidacy.

29 Likes
2

@sarahjamielewis I have added a link your thread to the top post in the Megathread. Good Luck!

2 Likes
3

There is 100% you will have my support, we need an ethics freight train on this committee and I would be giving you my voting expecting you to be the voice of reason if you suspect collusion or any type of deception is taking place between other MGRC members.

3 Likes
4

Thanks for your support @PhusionPhil. While I do not consider collusion or deception between committee members to be a major risk [1], I do believe it is important that the committee sets strong policies around transparency of interests for both members, applicants and grantees such that any potential risk can be appropriately mitigated and that the outputs of such policies and mitigation processes are available for public review.

[1] I’m far more concerned about the committee providing an insufficient allocation of resources to ethical design review, security and auditing (/not evaluating these as part of the grant criteria at all or potentially worse, burdening grantees with that responsibility wholly and duplicating effort.)

5 Likes
5

If you go look at my comment on @mistfpga application you’ll see that I was quite adamant about him using his auditing knowledge and reverse engineering experience actively in the decision-making process. He brought up an interesting point though that the word audit holds a specific legal responsibility and he didn’t want to include that responsibility in his application because it would make it more complicated. So I see your concern but I think if we have someone on the team who acknowledges the importance of auditing and there’s a responsibility from the foundation to commit to those audits then it won’t be a problem.

Perhaps we could arrange a bilateral agreement between grant applicants and the community to perform a 3rd party audit but add a clause of sorts that guarantees the auditors from frivolous legal repercussions. We could define very precisely what we consider to be a pass and a fail for the audit, a fail would just require a revised application imo.

6

Auditing is a very overloaded term, so I’m going to break it down slightly to clarify meaning.

  • Financial Auditing: A full review of the books and operations of an entity - generally very expensive when it comes to small teams, and a major hurdle in the technical grant space as many grant committees require it. I do not think it wise to require such audits of grantees as it drastically slows the process and limits the potential pool of applicants. If there are special circumstances (i.e. very large grants) where such an audit would be prudent, I’d like to see it built into the budget of the grant.

  • Security Review / Auditing: Also a very overloaded term, sometimes part of a legal requirement (e.g. handling credit cards directly), sometimes not. It is very clear to me that several Zcash ecosystem grants have not had sufficient funding dedicated to security review and if elected I would push to have a standardized security review process be a mandatory requirement of a technical grants. This may involve funding a team dedicated to this work, or working with existing teams to conduct the reviews.

I’ll note at this point that I used to be a “Security Certifier” (and a Security Engineer) for Amazon and have extensive experience conducting security audits across a range of systems handling extremely sensitive data and managing external teams to run large scale, multi-month security engagements (both assessments and red teams) - I’ve also at this point found, reported and occasionally several vulnerabilities in existing Zcash ecosystem projects.

As such I understand the amount of work that goes into such reviews (from all sides), and even with a template and standardized process there is always going to be need for customized reviews for each grant (either when defining scope, or directly reviewing such consequences).

We could define very precisely what we consider to be a pass and a fail for the audit, a fail would just require a revised application imo.

Audits are rarely pass/fail - ideally an audit (whether financial or technical) provides an essential insight into how a system operates, what risks are prevalent, how those risks are being managed and how the system will evolve in the future.

An audit might occasionally raise a risk so severe that the programme needs to stop and immediately address it, but more often than not you end up with a long list of potential risks that need to be managed. - (see the updated Zbay Grant which acted on my suggestions to include more milestones for better tracking and managing risks as they develop.)

Ultimately, this is why I am skeptical of proposals that require the committee to work less than full time, someone needs to be keeping tracking of how the MGRC is distributing funds, what risks are at play (no grant is ever 0-risk), and how teams are dealing with them.

6 Likes
7

Hi,

There seems to be a lot of security engineers applying for this. That is always a good thing. I completely agree with how you are defining audit and the amount of work they involve.

For me, I have done FIPS ( Federal Information Processing Standards) testing and actual audits for Hardware Security Modules and Datacryptors. I have farmed this testing out to companies like NGS to get our products tested too.

I have also professionally done the much more ambiguous “security audits” these normally were as part of pen testing assignments. where the whole thing was the audit and I was responsible for a specific subsection (generally runtime analysis stuff and memory data management).

Real, legal audits, cost a lot of money and take a lot of time. You cant get FIPS certifications over night and without spending a lot of money (FIPS seems the most relevant one that I have had experience with.) For nearly all financial and government security audits part of the process is using a requirements based testing model (think of software like IBM DOORS to track progress) - This could well be a step too far. You would be forcing teams to adhere to a development process. This is generally very limiting for attracting developers, it certainly was an issue where I worked. This needs to be avoided if possible.

What I would like to see (and what I think people mean when they say audit) would be a certification scheme more inline with how console games are certified.

For developers to use the zcash trademark if they need to pass a series of tests. These would be requirements and unit tests. For wallet software this might include:

  • zcash logo must not be altered.
  • change must be sent to a zaddr
  • many other requirements.

These would be general, like the case of logo usage and they would be project specific unit tests set by the MGRC, like the case of change. @PhusionPhil is this more inline with what you were thinking?

I really think certification is the way to go not audits. I mean what would be audited against? what standards? We could come up with some eventually, but certification requirements is the first step in that direction.

Defining the standards for certification and doing the testing, including milestone testing really is not that big of a deal. It is certainly not a part time job in the first year, but after the standards are defined, the testcase database made and a bug tracker put in it is not full time work. I did this back in the day for the launch of the xbox, so I have relevant experience.

Sure but micromanagement is not part of this either. 6 week to 3 month milestones with community reports should not be an issue for the MGRC. Just tie funding to passing milestones. Then define passing the milestones based of unit tests and predefine requirements outline at grant approval time.

I think the work will be oddly weighted with it occurring in fits and spurts. so for 4 weeks there might be nothing to do, then you might be full time for 2 weeks. then part time for 2 weeks then nothing for 6 weeks. We just dont know. So there needs to be flexibility in the candidates.

I would love to hear what you think on this.

cheers,

steve.

1 Like
8

While I agree with you, to some extent, that certification standardization is a front-loaded process, I also think that tracking grants along any such standard is a very minor portion of what I would consider the work of the committee. These are the ideal cases and the major work of the committee needs to be focused on where these tests fail.

Referring back to a reply I gave in the main thread on the MGRC I think it likely that the committee will be called upon to spent a lot of time responding to deviations from the milestones and ensuring that grant money is invested effectively - I feel the need to emphasize that that often means the most work happens when things don’t go to plan:

I also think it is worth pointing out that even if we were to accept the idea that the work of the committee might taper off once all the processes and procedures have been put in place, time still needs to be spent building and field testing those processes and procedures in the first place. We can debate the potential steady states of the review committee, but we must acknowledge that the initial term will very much be not a steady-state, it will require dedicated effort from committee members (and with planning that effort should eventually become sublinear to the number of grants). As you put it:

It is certainly not a part time job in the first year

Some more specific thoughts:

This seems explicitly outside of the scope of the MGRC given that it has no authority over the zcash trademark (while I could see such a scheme in the future of the MGRC, I don’t think it is a wise use of the MGRC time or resources in the initial few years).

As I mentioned, I don’t think audits are the most effective mechanism for evaluating grant recipients or outcomes but there are several domains in which audits can and might be considered (although these would primarily be financial / organizational audits and I will stress again that I think these should be the exception to applicants, not the rule)

That being said, I will clarify:

The MGRC is in a position to help set standards of excellence and practice - and back that up with funding to help teams reach those levels.

Privacy and Anonymity are very peculiar risk models that aren’t served well by most commercially focused security review processes. As Zcash starts gathering a larger number of apps promising the mitigations of such risks I think it is vital that we don’t repeat the mistakes we have seen in other ecosystems and in the early days of the zcash app ecosystem where anonymity is heralded and then apps fall over and expose users at the first hurdle or inappropriately promise anonymity in the name of zcash while doing little to mitigate risks outside of the ones that zcash can protect against.

I think this includes an expectation (and funding of):

  • Ethics Review for studies and software (see the Zbay link in my previous post for an example) to discover and capture risks. Grantees (and the committee) have a responsibility to ensure that they aren’t harming the communities they are purporting to support - this means setting up and engaging in ethics reviews and responding to the outcomes. Sometimes this will mean stopping a grant, other times it will be reworking it. I have lost count of the number of community groups, charities and marginalized people I know who will not touch cryptocurrency because earlier groups showed up promising the world, parachuted in a bunch of half working technology and then left those groups to clean up the mess. We need to be better than that.

  • Design Review milestones than include explicit risk models and mitigations. One of my biggest fears around Zcash is we end up with a large ecosystem in 5 years that does nothing to advance financial privacy or censorship, and Zcash suffers the same fate as many other privacy ecosystem projects - offering great privacy at one layer while ignoring all others.

  • Peer Review of new technologies and software outside of traditional academia and industry committees (e.g. community review where grants are targeting specific groups) - the MGRC should act as a bridge between various parts of the ecosystem, connecting and encouraging work between groups to avoid rework and encourage reuse and integration.

All of that is why I think it is important to push for an active and full time inaugural committee; some of these processes will shape out, others won’t. But developing them in concert with grant applicants, recipients and the community at large is going to take dedicated time and effort. Anything beyond is speculative.

6 Likes
9

The certification scheme would very much appeal to me. Thank you for clarifying the audit process for the community as well as myself @sarahjamielewis

2 Likes
10

There is a lot of talk right now in the main MGRC thread regarding compensation and related issues.

These are issues that are most likely to be decided at the ballot rather than prior, so in the interests for transparency I will lay out my position on this topic explicitly:

If elected to the MGRC I will vote for internal processes that:

  • Require 2-3 MGRC members to work full time (as outlined in this thread) - sourcing and meeting with applicants, reviewing applications, developing metrics and all the other work I previously talked about in the main thread:

  • Compensate MRGC members for that work. As wonderful as the mission is, missions don’t feed people and we need to establish that this committee is not just for those that are already wealthy or who already have secured positions within the ecosystem. If the community values diversity of thought, opinions and backgrounds then it is essential that MGRC members are paid for the work that they do, and is seen as a viable option to as many people as possible.

  • I will vote for processes that denote this compensation as a mixture of ZEC and/or ZEC futures to ensure that committee members have skin in the game.

  • Minimize the influence of ECC and ZF employees, associates and/or affiliates in the running of the MGRC. One of the primary goals of the MGRC is the decentralization the ecosystem, there are rightfully concerns within the community that capture of MGRC seats by such affiliates risks turning the MGRC into a proxy arena for the two incumbents in this space. It is vital that the MGRC establishes independence and primary accountability to the community.

I believe that all of the above are essential for the MGRC to be successful.

3 Likes
11

So MGRC employees should be compensated for hours worked.
But your proposal, as with a number of people’s, seems to want to implicitly make compensation an incentive by making it in ZEC and thus subject to appreciation.

What do you make of the fact that we had such incentivization for the past four years for ECC leadership and it is, unarguably, a failure. For the past 4 years zcash has trended down relative to most cryptocurrencies of merit. From that we can either conclude Zcash is doing well and therefore market performance isn’t what we want to incentivize or we can conclude Zcash is doing poorly and it wasn’t an effective incentive. What will be different going forward?

1 Like
12

Skin in the game is necessary but not sufficient for success.

Zcash launched with a lot of hype and was unable to deliver on much of the hype for (what I see as) a few key reasons:

  • Both ECC and ZF spent a lot of time (months to cumulative years of time) arguing with each other instead of (directly) investing in the ecosystem. What ecosystem investment there were came across (at least from an external perspective) flustered, in-considered, and led to the creation of countless security vulnerabilities across the zcash ecosystem.
  • During that 4 year period ECC also played a year long shell game with a critical vulnerability which, despite maybe being the best way to handle it, also deeply damaged the zcash brand.
  • Finally, how Zcash fairs in absolute terms is pretty meaningless - Zcash, and the rest of cryptospace, are inextricably tied to the price of Bitcoin (at least for the foreseeable future), which is tied to all the other integrations and short-lived experiments going on in that space. Zcash price relative to Bitcoin on any significant scale is a flat line. The decline of the last 4 years can be attributed almost 100% to the decline in the price of Bitcoin and related offerings.

The MGRC doesn’t control the price of Bitcoin. The only levers it has to incentivize people are ZEC, ZEC Futures, derivatives thereof and some amount of power within the Zcash ecosystem. There is inherent risk in someone aligning themselves to those incentives - and we must not forget that those who serve on the MGRC are taking on that risk.

Are other systems needed to maximize the output of the MGRC? Absolutely, and I’ve talked in this thread and elsewhere about the processes and policies that I would bring to vote on the committee to bring ethical and security and risk review criteria into the grant process, track the progress of grants beyond one-and-done checkpoints and bind committee members to strict disclosure policies for conflicts of interests.

Should you also vote for people who are in it for the mission? Absolutely, I think my bio speaks for itself in that regard. But as I outlined above, missions don’t feed people, and some incentives structure is needed - and the MGRC only has a few levers to play with.

4 Likes
13

I agree your bio speaks for yourself and I think i’m going to ask this question of everyone. I don’t mean to pick on you . In the main MGRC thread the incentives issue came up and at least there, it seemed to be giving people a false hope. “If incentives are aligned, things will be good.” So, implicitly, we need not create other structures/incentives to make sure the right things happen.

You are right we care about relative performance, not absolute. But it’s gone down relative to everything. The below graph is log scale and shows a steady decline relative to BTC. It’s a 10x slip. The same would be true of Eth. And we’ve dropped in relative market cap by a large amount. We can ignore the market, but everyone suggesting incentives is saying we should listen to it. So , let’s listen to its past performance.

image
image2400×1052 128 KB

I’m skeptical we can attribute this to ZFND and ECC fighting. That’s a development over the last year when the trend is much longer than that. And the market largely ignored the security issue. But I could be wrong there and maybe those are the mistakes that lead us here. The question is, what do we do going forward to avoid those kind of mistakes. Because incentives clearly didn’t cut it. We need other mechanisms.

5 Likes
14

Well it hasn’t helped that there is little marketing and not enough effort to get Z addresses on exchanges so far. I assume that is because the wallets are not ready yet. Whenever ZEC holders want the ECC/ZF to do things that would help the price of ZEC they always say they don’t want to influence the price. Yet they expect people to invest in Zcash to give them money to continue developing and the holders have gotten little to nothing in return. This has also directly affected the incentive alignment. So thus far it has been a combination of still needing development and promotion. The ECC is happy to give their work away and not get the value back for their holders. That is one of many reasons why Ethereum is doing well and will continue to do so. How does sharing or giving away the tech benefit ZEC holders? They should be required to use Zcash in the other projects that use Zcash technology.

If Zcash doesn’t move to Z addresses and monetize its’ technology it will fail.Also, Zcash is GPDR compliant and has/will have? viewing keys so why is it not more accepted? It should be an accepted privacy coin for those reasons. I am still optimistic the value will go up, but these issues need to be addressed. I think most of this is moot, however until the wallets are mature to fully enable z address functionality.

1 Like
15

I agree we need wallets but I want to draw a line between individual technical choices and the way choices are made. When people talk about incentives, they are saying we need to make sure choices are made by a correct process. It seems to be obvious to everyone we need something to cause that to happen. Multiple people are talking about incentives and it’s not primarily because they themselves want money, it’s because they think we need to fill the decision making/governance mechanism void. And I agree. But there’s no way, given zec’s market performance to argue incentives are it. Either it failed to work because it didn’t cause us to do well in the market for four years, or it failed to work because we don’t care about market performance. So we need something else to fill the void. Something else that will lead people to develop wallets, or custom assets, or scaling, or whatever other technical fix it is.

2 Likes
16

Hi !
Can you be more clear about what you intend to fund ?
Your resume says you worked with “marginalized” and “targeted” communities (sounds like politically charged words), is it a hint that you want to focus spending money that won’t directly benefit the common folks ?

If yes, I think this is a big strategic mistake and looks like an easy money grab from the Zcash community to the benefits of only few people.

17

They are politically charged words. In many cases they are risk models where failure means death or imprisonment. As Emma Goldman once remarked “As an anarchist my place has always been on the side of the persecuted.”

I work with sex workers, queer communities, activists and journalists because they are the communities that have the most to lose from a lack of privacy. They are communities that understand what is at stake. They live their risk models.

If you can’t protect the privacy of those that society deems deviant or criminal then you can’t protect the privacy of anyone.

is it a hint that you want to focus spending money that won’t directly benefit the common folks ?

This is an incredibly naive take. Do you want “privacy” or do you want privacy? To me the core robustness, dare I say the anti-fragility, of the privacy and security (and thus the future) of Zcash must be on the margins, on the extreme ends of the risks that undermine freedom - that means building systems that understand those extremes, and can work with them to ensure that everyone shares in the power that the system controls.

My research has always focused on those extremes. It’s why I first started delving into the extent of deanonymzation vulnerabilities on dark web drug markets - because if people who have skin the game when it comes to not getting caught screw up the technology then guess what? "common folks " don’t stand a chance in hell.

Can you be more clear about what you intend to fund ?

Here is a short and incomplete wish list:

  • Wallets that have a utility beyond the simple sending and receiving of transactions - I’d like to see more thought given to:
    • Organizational Accounting - Beyond CSV export and into integrating with various other software, providing safe & automated tracking of worth against various other assets (BTC / USD etc.)
    • Trading Integration - One day soon I’d like to see sheilded zcash become an option on decentralized exchanges like Bisq, but even basic integration would go a long way
    • Donations
  • Research and Development into Memo based applications (more experiments like Zbay and Token Based Services) and the future of memos within the Zcash ecosystem.
  • Projects within targeted communities to understand the limits of Zcash adoption within those communities. Projects within those communities to experiment with possible on-the-ground applications. Along with the development of an ethical review process (as I helped Zbay design: Request for feedback on Zbay user-interview design) to ensure that such work is held to the highest standards and prevents the parachuting that haunts the rest of this space.
  • Libraries to make efficient / secure in-app light client integration a (secure & private) possibility.
  • Security and Privacy reviews of the software and hardware stacks around Zcash (Tor, new Mixnets, User Interface Libraries, Kernel Extensions etc.) to ensure that holes in our environment don’t compromise the privacy of Zcash and Zcash Ecosystem projects.
9 Likes
18

Thanks for the answer, I understand better. :+1:
I’ve always seen Zcash privacy as an all-inclusive one so it raised me an eye brow, but I’m happy to see the kind of project you would fund

20

OK, just read this. I will remove a redundant question (apologies).
Right after reading this, I feel jazzed about your candidacy.
I feel like you articulate and represent many of my concerns and interests.

Of course… there are other candidate threads to read…

But I would vote for you, if I could vote right now!

21

Given your expertise, it seems reasonable to ask how you would handle things in the face of a bug like this?

It seems like there’re a couple of ways to respond:

  1. Generally what’s the right approach to such a situation?
  2. Given the actual counterfeiting vuln mitigation that occurred what did you learn? How would you apply that Zcash-specific learning to the next vuln?

If the way the vuln was handled was maybe the best way, what are the other hypothetical ways in contention for best?

Specific to the MGRC role, if the MGRC is involved in technical audits (which sounds good to me), how would disclosure of vulnerabilities be handled? Would it differ significantly from how the ECC disclosed the linked vuln?

6 Likes