DESIGN FROM THE MARGINS
Methodology to De-weaponize Tech
Implementation Guide
How do you build technology when the state, the platform, the employer — or the person holding the phone — may become the adversary?
Design from the Margins starts there.
Built from more than a decade of practice and interviews with 42 decentered people and advocates and 12 technologists, the guide turns lived experience of criminalization and marginalization into questions for research, product decisions, privacy, infrastructure, threat models, prototypes, and whether a tool should exist at all.
DESIGN FROM THE MARGINS. DE-WEAPONIZE TECH.
To de-weaponize tech is to strip it of its capacity to be used for surveillance, criminalization, or structural exclusion and abandonment.
“We are closest to the problem,
so we are also the closest to the solutions.”
-ANDRE APPARICIO
Reentry Strategist
NEITHER EDGE CASES.
NOR THE PERIPHERIES.
COMMUNITIES SET THE DESIGN CONDITIONS.
DFM starts with the decentered: people who are both highly marginalized and criminalized in their context.
Their experiences show where ordinary design choices break and leave gaps, especially: under surveillance, coercion, policing and institutional power.
Criminalization becomes a design lens: it changes the stakes of data, access, risk and trust, and makes hidden failure modes visible before they spread.
“Criminalization is [also] pushing people to hide. It's about erasing people's existence. Criminalization is surveillance. So [it’s about] those who are experiencing hyper-visibility and erasure simultaneously ”
-LORELEI LEE
writer, performer, sex worker, organizer, professor
What’s inside the guide?
From power and harm to the build itself:
The methodology is iterative rather than linear. Teams move back and forth as new harms appear, assumptions break and contexts shift.
You’ll find in here how to:
map harm before you build;
identify whose experience should set the design conditions;
treat criminalization as a design lens;
work with community experts and Guardrail Advisors;
organize for change inside tech institutions; question whether something should be built at all; design for forced access, hostile actors and shifts in power;
and carry that thinking into prototypes, threat models, red teams and difficult trade-offs.
THE GUIDE GETS CONCRETE
Buliding for:
forced device access
types of hostile actors
future-proofing
real access in crisis
Understanding:
defaults vs. granular controls
AI hype
threat modeling
red teaming
trade-offs
Case Studies, Contexts, Technologies
Built from what happens in the real world:
CONTEXT IN THE GUIDE
MENA queer apps, entrapment and device searches
Palestine checkpoints, navigation and military/surveillance tech
Kenya digital ID and border communities
Ethiopia telecom/SIM systems and Tigrayan targeting
El Salvador device searches and “gang” profiling
Iran online patrolling and internet shutdowns
Mexico & the US reproductive health and migrant surveillance
Sudan tech under war and displacement
India caste, prosthetics and techno-solutionism
TECHNOLOGIES & SYSTEMS
• dating & messaging • maps/navigation • digital ID & biometrics • facial recognition & recommender systems • reproductive-health tech • social media & moderation • cryptography/ZKPs • device access & identity verification •
From an app icon or notification sound to identity infrastructure and theoretical cryptography, the guide uses examples and interviewee expertise, to follow where design meets power.
“Everything here, unfortunately will likely be tested on migrants and refugees in one way or another.”
-KARLA
Colibres, Mexico’s southern border
The people inside the build have the leverage:
DFM focuses in part on tech workers because they have access to the actual levers: code, infrastructure, defaults, product decisions, research, review processes and internal objections.
In corporate tech, that means giving aligned builders a method for challenging harmful directions from within even if they are not the CEOs or top decision makers. Building allies means also building skills to push back on harmful designs and stealthy moves to build against abuse.
In public-interest and open-source tech, it gives under-resourced teams a way to ground good intentions in the realities of people most exposed to harm and ways to identify who to prioritize in build to provide for the biggest number of people.
The approach sits alongside — not in place of — organizing, unionizing and collective worker power.
Build with an adversarial lens to power
Implementing DFM today, amid a global authoritarian turn, requires designing for the decentered with an explicitly adversarial lens to power. It begins by assuming no institutional protection and proceeds from the premise that those with the greatest access will attempt to use it. This demands systems that protect against all levels of harm, especially the highest. Whether it’s states or the corporation or organization itself.
This is not a moral judgment about any specific organization or government, but a structural claim about power.
If systems are built so they cannot be abused by those with privileged access to internal levers, they will also be resilient against hackers, stalkers, abusers, and others with fewer resources.
DFM treats criminalization and institutional power as part of the technical environment. These are not just external social issues to address after launch. They are elements we need to build into tech. This guide helps in providing the ways to translate that.
“Our future isn’t inevitable, nor is it something corporations get to choose for us. We are the ones who decide what our future will be.”
-NAME REDACTED FOR PRIVACY
Scholar of Theoretical Cryptography
Some of our core tenets are:
Start and stay with the decentered. Keep the most harmed and least protected central from research through deployment.
Use criminalization is a design condition. Stress-test data, access, visibility, defaults and trust against real enforcement conditions.
Adopt an adversarial lens to power. Do not assume the state, company, employer or other institution will remain protective.
See design decisions as political acts. Every default, data flow and feature shifts who is protected, exposed, heard or excluded.
BUILD FOR PEOPLE NOT POWER
Need an in conspicuous version for a sensitive workplace or political environment? Contact De|Center