This is part two of a four-part series on how we approach data at Mozilla. Read the others here: Part 1; Part 3; Part 4.

“What role can Mozilla play in catalyzing data governance infrastructure, services, and support?”

When Digital Public started working with Mozilla, the question was whether our expertise in data governance could help the organization model and market-test the viability of different answers to that question. On the one hand, it’s a disarmingly simple question - Mozilla is already a digital rights advocate in a number of ways, giving a credible foundation from which to design other approaches. And yet, Digital Public is an outside organization - surely the Mozilla team would be best-suited to answer that question. Like a lot of big questions at big organizations, the process is usually messy and progress is more constructively measured by changes of trajectory than hard pivots.

In the ensuing 18 months, Mozilla has hired and dedicated staff to aligning in-house data governance, launched the Data Futures Lab - to begin experimenting with new partners and approaches to data governance, and (as mentioned in Projects by IF’s post) continues to prototype new ways to support the broader community and the needs of the organization. Over the course of our work together, the format, questions, and priorities changed - and, hopefully, they will continue to do so as Mozilla moves from exploring data governance to practicing it intentionally.

While there were a lot of interesting ideas, here are a few of the framing assumptions that guided the way (for more, here’s the long-form report):

  • Rights through data > rights to data. There is a difference between treating data as a placeholder for a users’ rights in a context and treating the possession of data as an open-ended license to use data however an organization sees fit. While both can be taken to the extreme, this project was to design propositions that help ‘users realize their rights through the use of data.’
  • Managing rights is different than managing data. At an operational level - organizations designed to build data architecture and organizations designed to protect or enforce a set of rights are different. Primarily because the ways that we realize and protect our digital rights, typically, involve a lot of dependence on external institutions and “stacks” that create obvious political, power, and practical issues.
  • Unenforceable rights aren’t rights. One of the main choices for a digital rights organization, especially one that aspires to any kind of sustainability, is to develop a theory of leverage or power to exercise, should good-faith attempts at negotiation fail to produce the desired result. And it’s worth highlighting two kinds of enforcement: (1) institutional enforcement, relying on a central authority to investigate and adjudicate claims - like with government regulators or platform customer service; and (2) public or direct enforcement - essentially, where people are able to bring their claims before an accessible, independent oversight body, like with civil courts and/or better business bureaus. The approach that an organization takes is also a political choice about how to center itself in the inevitably contentious processes that result.

Over the course of the project our work grew specific and applied, from triangulating potential roles toward modeling different approaches in existing products, user behaviors, and Mozilla capacities. It’s not always easy or natural to reground projects aimed at research and development toward refocusing on an organization’s pre-existing processes and comparative advantages, but pre-existing work and values are often key foundations for establishing the integrity necessary to be a good data governor or steward. While our ‘example’ use cases never crystallized to the point of becoming immediately implementable lines of business, Mozilla has developed a clearer sense of the scale, scope, and type of work involved to build trustworthy data governance projects - and is leveraging its considerable capacity toward doing so.

The progression of our work was exceptionally helpful, and led to a few observations:

  • Integrity starts at home. A lot of data governance initiatives begin from a sense of expansion, wanting to capitalize on the rapid pace of digital transformation, without doing the self-assessment to understand whether they’re actively part of the problem. Good data governance projects, like this one, start by building internal insight, awareness, and capacity to improve their existing behaviors and systems, before seeking to expand.
  • The violence is in the (eco)system. For better and worse, users understandably don’t trust most organizations - and so establishing credible integrity is an important first step for data governance initiatives. Organizations taking on data stewardship or governance initiatives not only need to affirmatively set clear expectations, they need to proactively consider how the threats, inequities, and biases built into the data economy are likely to impact the intended outcomes and people involved.
  • Data has a very long tail. Data exchanges take place at a moment in time, but they create ongoing relationships. For data governance and stewardship initiatives, that means that it’s not enough to simply organize data sharing with trustworthy actors, they also have to maintain enough oversight to ensure that the shared data is used within the limits of the exchange and, ideally, the interests of the rightsholders.

To Mozilla’s credit, they’re not just looking to build data governance and stewardship as a services offering, they’ve also built the board and leadership buy-in, the in-house infrastructure, and a dedicated team to make the meaningful changes necessary. That’s unlikely to be a clean process, there will be mistakes and missteps, but the messy, human work of building trust, capacity, and systems with integrity are where data governance work should start. And, of course, any start is just a start - Mozilla will then have the much harder work of continuing to invest in, articulate, and realize new approaches to data rights. There’s little question that work will happen - and that success in data governance is unlikely to look like success in scaling privacy tools or promoting open standards.

While there’s no clear or transferable definition of ‘data governance success’, there are a few lessons we’ve learned across Digital Public’s work that may be useful as Mozilla (and others!) take next steps toward building applied services and infrastructure.

  • Politics of commission. There is a tendency in most organizations to avoid clearly stating an organization or initiative’s digital politics - both because it can create divisions and because it may foreclose opportunities. Data governance initiatives can’t afford to be ambiguous about what they’re trying to accomplish, they need to be specific about who they’re doing it for, and under what limitations - not only because those are important parts of the value proposition, but also because they help users set appropriate expectations and act accordingly.
  • Precaution is necessary, participatory adaptation is sufficient. Data governance is not a ‘set-it-and-forget-it’ field, and any approach needs to consider both the design process and its ongoing evolution. Often, trustworthy technology initiatives focus on the design of a technology or service as the primary point of engagement - whether to increase the diversity of the designers or introduce a range of harm-specific auditing and prediction tools. Those approaches are pretty limited, however, as design only really happens once - and data governance systems good enough to survive can last for a long time. Good data governance systems not only build with precaution in mind, they also design mechanisms for rightsholders to shape the evolution of the system.
  • Create and use friction. Data governance should be a source of constructive friction in digital ecosystems. Historically, the technology industry hated friction - not only as a ‘barrier to innovation’ but because, at a basic level, it provides an outer limit on how much power you can centralize. The thing about friction is, without it (figuratively and literally), it’s impossible to build anything of significance. Without friction, it’s impossible to stand up, to hold on to the things you care about, or make sure anything happens as planned. In other words, friction is the foundation for things that last - and data governance initiatives are strategic attempts to create and use friction in service of quality, equity, or some other shared value. Data governance, if it’s to be effective, has to embrace and channel friction, compelling integrity instead of hoping for it.

There is no obvious or single path forward for Mozilla, an organization with a huge breadth of digital, data, and activist infrastructure. Or, rather, the path that Mozilla takes won’t be because of an idea or an outside consultant, it will be because of its internal leadership, capacities, and prioritization. It will be down to the politics that Mozilla chooses, whether through omission or commission.

Ultimately, data governance is an important requirement for trustworthy technology, of any kind. But data governance is the equivalent of a ‘diet and exercise’ prescription for how to solve a digital rights problem - it’s not easy or convenient, but it’s a proven, obvious, and effective way to build legitimacy. By contrast, most of the data economy wants a ‘magic pill’ approach - a box to check to validate whatever their intended use of data is. That tendency pushes the envelope of what’s possible in data-driven systems, but also leads to a lot of wasted time, hurt people, and disillusionment with the idea of ‘perfect’ (or even ‘fit-for-democracy’) digital systems. And so, as Mozilla’s work in data governance grows, it will growingly face the parallel challenges of building high-integrity, rights-affecting relationships with a clear, enforceable base of integrity and reverse-engineering mechanisms of governance and rights realization into digital ecosystems. In many ways, it’s building the ecosystem capacity that the open source movement hoped would occur naturally, and returning to a more humble vision for what data can and should do, for whom, and how. That is, I believe, the most important role that Mozilla can play in catalyzing the digital rights ecosystem, but time will tell whether they agree.

This project didn’t make those choices for Mozilla, in the same way that a coach can’t run the miles for you. But I’m hopeful that we set out a plan to get off the data governance couch and start running. And, if history’s any judge, Mozilla will find its stride in no time - driven by the incredible digital rights community behind it. After all, building high-integrity digital relationships is a marathon, not a sprint, and Mozilla’s been running for decades.