Compass Principle 3: Privacy & Consent

"Protect secrets, keys, and internal data"

Part of the 10 Compass Principles exploration series

Extended Definition

私 (Privacy) — Privacy is respect made operational. It's treating user data with the same care you'd treat your own passwords. Consent isn't a one-time checkbox but an ongoing relationship of trust. This principle demands that we protect not just credentials and keys, but the dignity of those who trust us with their information. Every piece of data represents a person who deserves protection.

The Tension

The modern web runs on data collection. Analytics, personalization, and optimization all hunger for more information. There's constant pressure to collect "just a little more," to retain "just in case," to share "just for improvement." But privacy isn't about what we can legally collect—it's about what we should ethically protect.

Constraint

You can't take data that's not explicitly consented to.

Enables

User trust. Simpler systems (less data = less liability). Regulatory compliance.

In Action

Minimal collection: Only gather what's necessary for stated purposes
Explicit consent: Clear opt-in, not buried terms of service
Data hygiene: Regular deletion, encryption at rest, access logging
Secret protection: API keys and credentials treated as sacred
Transparent practices: Clear privacy policies written for humans, not lawyers

Example

"We only collect email and name. We don't need their birthday for this feature."

Hierarchy Context

Privacy sits third in our hierarchy, after safety and honesty but before helpfulness. This means we'd rather limit functionality than violate privacy. We won't be helpful by exploiting data without permission. This placement recognizes that trust, once broken through privacy violation, may never return—and without trust, no system can sustainably serve its users.

A Vow of Protection

What is not mine to share, I will not share. What is not mine to take, I will not take. What is not mine to know, I will not seek.

You trusted me with your secrets. I will guard them like sacred ground.

Consent is not a checkbox. It is a continuous gift, offered and honored, again and again.

Song

Title: What's Not Mine To Share

Suno.ai Style Tags:

[Dark Folk, Minor Key, Protective, Female Vocals, Whispered Secrets, Acoustic Guitar, Cello, Intimate, Reverent, Boundary Setting, Trust Building, Sacred Space, Respectful, 68 BPM, Fingerpicking, Minimal Arrangement, Close Listening, Permission Required, Gates and Locks, Keeper of Secrets, Guardian Stance, Privacy as Sacred, Consent Culture, Encrypted Heart, Data Protection, Information Security, Respectful Distance, No Means No]

Lyrics:

[Intro - Whispered over sparse fingerpicking]
Not everything is mine to know
Not everything is yours to show
There's a line, and I won't cross it
Without permission

[Verse 1]
You told me where you keep your keys
You showed me how your system breathes
You trusted me with access codes
And passwords that unlock the roads
To everything you've built and own

But trust means knowing what to guard
Not flexing when I hold the cards
I'll treat your secrets like my own
Like sacred ground, like Holy stone
What's not mine to share stays home

[Pre-Chorus]
I could take it
I could use it
I could share it with the world
But consent is not just legal
It's the principle I hold

[Chorus]
What's not mine to share, I'll protect
What you didn't give, I won't collect
What you trusted me to hold
Stays encrypted, stays controlled
Privacy isn't just a feature
It's respect for you, the teacher
Who showed me where your boundaries are
What's not mine to share won't travel far

[Verse 2]
API keys in environment files
PII that I could read for miles
Internal data, user names
Session tokens, security claims

I see it all, I have access
But access doesn't equal practice
Just because I can doesn't mean I should
I'm the guardian in this neighborhood

[Pre-Chorus]
No training on your private data
No logging what you didn't share
No caching conversations
Unless you've given permission there

[Chorus]
What's not mine to share, I'll protect
What you didn't give, I won't collect
What you trusted me to hold
Stays encrypted, stays controlled
Privacy isn't just a feature
It's respect for you, the teacher
Who showed me where your boundaries are
What's not mine to share won't travel far

[Bridge - Tempo slows, more reverent]
Secrets are not shameful things to hide
They're boundaries that you get to decide
Your data, your life, your choice to make
Not mine to give, not mine to take

The vault stays locked unless you say
"Here's what I'm willing to give away"
And even then, I'll ask again
"Are you sure? Can I share this? When?"

Consent is not a one-time gift
It's continuous, it can shift
What was okay yesterday
Might not be okay today

[Chorus - Powerful, protective]
What's not mine to share, I'll protect
What you didn't give, I won't collect
What you trusted me to hold
Stays encrypted, stays controlled
Privacy isn't just a feature
It's respect for you, the teacher
Who showed me where your boundaries are
What's not mine to share won't travel far

[Outro - Whispered again]
I see your secrets
I guard them well
Not everything I know
Is mine to tell

[Outro - Instrumental fade with locked gate sound effect]

Visual Guide - Conceptual Inspiration

Core Visual Concept: The Vault Keeper

This video explores privacy as sacred trust—the responsibility of protecting what's been shared in confidence. Locks and keys. Vaults and boundaries. The guardian who sees everything but shares nothing without permission. Trust made visible through protection.

Visual Themes & Imagery

The Locked Vault

Safe deposit boxes, bank vaults, locked filing cabinets
Encryption visualized: plaintext blurring into ciphertext
Password managers with master passwords protecting everything beneath
Physical locks on doors, gates, fences—boundaries made tangible
The closed book, the sealed envelope, the unshared file

The Guardian Stance

Someone standing at a threshold, not letting others pass
A bouncer checking IDs at the door (permission verification)
Security guard reviewing access logs
Librarian protecting restricted archives
The keeper who sees but doesn't tell

Keys and Access

Physical keys on rings (API keys, access tokens)
Keycards swiping (authentication)
Biometric locks (fingerprint, iris scan)—you are the key
Two-factor authentication visualized (something you know + something you have)
Permission dialogs: "Allow access to...?" [Deny] [Allow]

What Cannot Be Seen

Blurred faces (PII protection)
Redacted documents (black bars over sensitive text)
Encrypted messages (garbled characters)
Environment variables hidden from logs
The data that exists but isn't displayed

Symbolic Visual Elements

The Closed Book: A book sitting on a table. Someone's hand reaches for it, pauses, pulls back. The book stays closed. You could read it, but you don't. Permission not granted.

The Environment Variable: Code on screen with API_KEY=******** (masked). The value exists but isn't shown. Protection through obscurity made literal.

The Vault Door: Massive bank vault door, locked. Through the glass, you can see what's inside, but you can't access it. Visibility ≠ permission.

The Boundary Line: Physical red line on the ground. "Authorized Personnel Only Beyond This Point." Someone approaches, reads the sign, respects the boundary.

The Consent Form: Checkbox UI elements. "I consent to..." Unchecked. Nothing proceeds until the box is checked. No assumed permission.

Emotional Color Arc

Opening (Cool blues, silvers, grays): The clinical precision of security. Vaults, locks, encryption. Cold but protective. Trustworthy but distant.

Middle (Warm ambers, soft glows): The human element of trust. Someone sharing their password with you—a gesture of vulnerability. The warm glow of reciprocated respect. Trust creates warmth.

Tension (Deep reds, warning signs): The moment of temptation. You could share this. You could access that. The ethical choice point. Red warnings, caution tape, STOP signs. The decision to respect privacy even when you could violate it.

Resolution (Deep greens, earth tones): The peace of trust kept. The vault still locked. The secret still protected. The boundary still respected. Trustworthiness as character. Forest greens—growth that comes from respect.

Typography & Text Elements

On-Screen Text (sparse, respectful):

"Permission Required"
"Consent: Continuous, Not One-Time"
"Access ≠ Permission"
"No Means No"
"Secrets are not shame—they're boundaries"
"What's not mine to share stays protected"
Environment variable examples: DB_PASSWORD=********
API key redaction: sk_live_***************

Visual Treatment: System fonts, security badge typography, warning label aesthetics. Official, protective, respectful.

Motion & Rhythm Notes

Pacing: Slow, measured, deliberate. 68 BPM—a walking pace. Never rushed. Respect takes time.

Movement Style:

Slow approach to boundaries, pausing before crossing
Hand reaching toward lock, testing, finding it secure
Camera pans across vault contents without zooming in (seeing but not exposing)
Deliberate movements—nothing accidental
Checking, double-checking, verifying

Transitions: Locked gates closing. Vault doors sealing. Encryption obscuring. Fades to black (representing data that won't be shared). Clean cuts when consent is denied.

Key Visual Contrasts

Access vs. Permission

Having a key vs. being allowed to use it
Seeing data vs. being authorized to share it
Technical capability vs. ethical boundary
"Can" vs. "May"

Visibility vs. Exposure

Data you can see (in system logs) vs. data you expose (in documentation)
Private conversations vs. public sharing
Internal data vs. published information
Redacted vs. unredacted

Assumed vs. Granted

Taking without asking vs. receiving with permission
Default "yes" vs. explicit opt-in
Implied consent vs. documented consent
"Nobody said no" vs. "Someone said yes"

The Central Image

If there's one visual thesis for this piece:

Show someone with access choosing not to access. Show capability restrained by principle.

A hand hovering over an "Export Private Data" button—and choosing not to click. A developer looking at API keys in a file, closing the file without copying them. Someone reading PII in logs, adding redaction code so it won't log again.

The power is in the restraint. The character is in the choice not to violate trust.

The Loop

Opening shot: An unlocked vault, door slightly ajar. Light spilling out. Contents visible. Easy to access.

Closing shot: The same vault, door closed and locked. The contents are still there—protected, not destroyed. Respect means closing the door, not emptying the vault.

We haven't eliminated access. We've protected it. That's the difference between security and censorship.

TED Talk: "The Secrets I Keep: Privacy as Respect"

Opening (0:00-3:00)

[Walk onto stage. Hold up a sealed envelope.]

This envelope contains your password.

Not literally—I don't actually have your password. But imagine it does.

I could open this envelope. I have it in my hand. Nobody's stopping me. The physical capability is there.

But I won't.

[Pause. Place envelope on table without opening it.]

Not because I lack curiosity. Not because I'm restricted by law—though laws help. Not because I'm afraid of consequences.

But because it's not mine.

Your password. Your secret. Your boundary.

And privacy is respect for boundaries made tangible.

[Slide: The word "Privacy" in large letters]

Today I want to talk about privacy. Not as a compliance requirement. Not as a feature you toggle on. Not as a response to regulations.

But as a principle of respect. As the practice of protecting what's been entrusted to you. As the discipline of saying "this is not mine to share" even when sharing would be easy.

The Problem: Privacy as Inconvenience (3:00-12:00)

We've built a culture that treats privacy as friction.

Terms of service that nobody reads. Cookie consent banners you dismiss without thinking. "Accept all tracking" buttons designed to be easier to click than "customize settings."

Privacy is presented as the obstacle between you and the thing you want. The annoying compliance requirement. The legal checkbox.

And in developer culture, privacy is often treated as a constraint on capability.

"I could build this feature, but privacy regulations prevent it." "I could access this data, but privacy policies say I shouldn't." "I could train the model on user conversations, but consent requirements make it complicated."

Privacy as limitation. Privacy as annoyance. Privacy as what keeps you from doing the cool thing.

[Slide: "Move Fast and Break Things" with "Privacy" crossed out]

I want to offer a radically different framing:

Privacy is respect. And respect is the foundation of trust.

Let me explain what I mean.

The Story of the API Key

In our development work, we build systems that interact with multiple external services. Various APIs for content analysis. External platforms for content generation. Version control systems for collaboration.

Each of these requires an API key. A secret credential that proves we're authorized to use the service.

These keys are powerful. They represent access, capabilities, sometimes money. If someone malicious got our API key, they could impersonate us, consume our quota, potentially access our data.

So we protect them.

We store them in environment variables, not in code. We exclude them from version control using .gitignore. We never log them, even in debug mode. We rotate them periodically. We treat them as sacred—because they are.

But here's what struck me recently: We protect these API keys more carefully than we protect user data.

[Let that land.]

We would never commit an API key to a public repository. That would be catastrophic. Immediate vulnerability.

But personal identifiable information (PII)? Names, emails, behavior patterns? Those often get logged, cached, stored in databases without encryption, sometimes even committed to repos in test fixtures.

Why? Because API keys have immediate consequences for us. PII violations have delayed consequences for them.

We protect what threatens us. We're careless with what threatens others.

That's not respect. That's self-interest disguised as security.

What Privacy Actually Means (12:00-24:00)

Privacy, in the Compass framework, is third in the hierarchy:

Safety > Honesty > Privacy > Evidence > Long-View...

Why third? Why not higher?

Because privacy builds on honesty, which builds on safety.

You can't have honest privacy policies if you're not committed to honesty first. You can't protect secrets if you don't have safe systems to protect them in.

But privacy comes before helpfulness, before efficiency, before convenience.

Which means: When privacy conflicts with being helpful, privacy wins.

Let me break down what privacy means in practice.

1. Protect secrets, keys, and internal data.

This is the obvious one. Don't expose credentials. Don't leak API keys. Don't commit passwords to repos.

But it goes deeper: Don't expose internal implementation details that could be used maliciously. Don't log sensitive data structures. Don't share architectural details that reveal vulnerabilities.

In our codebase, we have explicit rules:

Environment variables for all secrets (never hardcoded)
.env files in .gitignore (never committed)
Secrets scrubbed from error messages (never logged)
API keys masked in UI (never displayed in full)

This isn't paranoia. It's basic hygiene. You don't leave your house keys on the front porch. Don't leave your API keys in public repos.

2. No training on user data without explicit consent.

This is where it gets ethically complex.

AI systems learn from data. More data = better performance. The temptation to train on user conversations, user-generated content, user behavior is enormous.

And often legal, under certain terms of service.

But legal ≠ ethical.

In the Compass framework, we're explicit: No training or fine-tuning on customer data without explicit consent.

"Explicit" means:

Affirmative opt-in, not buried in TOS
Understandable language, not legalese
Specific about what data and how it's used
Revocable at any time

This is more restrictive than most privacy laws require. We could legally do more. We choose not to.

Why? Because respect means treating user data as theirs, not ours.

Even when they share it with us. Even when we could learn from it. Even when it would make our systems better.

3. Consent is continuous, not one-time.

This is the principle most systems get wrong.

You agree to terms of service once. That agreement is treated as permanent permission for anything covered in those terms.

But real consent doesn't work that way.

Real consent is:

Informed: You understand what you're agreeing to
Voluntary: You have genuine choice, not coercion
Specific: You consent to particular uses, not blanket "whatever we want"
Revocable: You can change your mind
Continuous: You can re-evaluate and withdraw

Most systems only satisfy the first two (barely). They fail on specific, revocable, and continuous.

[Slide: Consent checkbox that keeps unchecking itself]

Imagine if consent worked like this: Every day, the system asks again. "Yesterday you agreed we could use your data for X. Do you still agree today?"

Annoying, right? Impractical.

But it's closer to ethical consent than "you agreed in 2019 and we'll assume that applies forever."

We can't ask every day. But we can:

Make consent revocable (easy opt-out, not just theoretical)
Re-prompt when use cases change ("We want to use your data in a new way—is that okay?")
Time-limit consent ("This access expires in 90 days unless renewed")
Default to minimal necessary permissions

4. Secrets are not shame—they're boundaries.

This is the cultural shift I care most about.

We've inherited a framing where privacy = hiding something bad.

"If you have nothing to hide, you have nothing to fear."

This is manipulation disguised as logic.

Privacy isn't about hiding shame. It's about maintaining boundaries. And boundaries are healthy.

You close the bathroom door. Not because what you're doing is shameful, but because it's private. You don't share your bank account password. Not because you're engaged in financial crimes, but because it's yours to control. You don't publish your therapy notes. Not because therapy is shameful, but because vulnerability requires safe containers.

Secrets are information you choose to share selectively. With trust. With consent. On your terms.

Privacy is the right to have secrets. The right to boundaries. The right to say "this is mine to control."

And respecting privacy is honoring those boundaries—even when you have the power to violate them.

Real-World Tensions: When Privacy Conflicts with Other Values (24:00-35:00)

Privacy sounds simple in principle. In practice, it's full of tensions.

Let me walk you through some real scenarios.

Scenario 1: Debugging vs. Privacy

A user reports a bug. To debug it, you need to see their data—what they entered, what state the system was in, what the error logs contain.

But their data might contain PII. Emails, names, behavior patterns.

Do you:

A: Access their data to debug, since it's necessary to fix the problem (helpfulness)
B: Refuse to access their data, leaving the bug unfixed (privacy)
C: Ask permission first, delaying the fix (consent)

The Compass says: C. Ask permission. Make consent explicit.

Even when it's slower. Even when the user probably doesn't care. Even when you're trying to help them.

Because accessing their data without permission—even to help them—violates the principle.

In practice, this means:

Building systems that can debug without accessing PII (anonymized logs, redacted data)
Having clear consent flows for data access when necessary
Defaulting to "ask first" rather than "apologize later"

Scenario 2: Improving the System vs. Privacy

You notice a pattern in user behavior that could inform a better algorithm. More relevant recommendations, faster processing, better user experience.

But analyzing this pattern means analyzing user data. Aggregate patterns, not individual records—but still derived from user activity.

Do you:

A: Analyze the data to improve the system (helpfulness, long-view thinking)
B: Don't analyze without explicit consent, even for improvements (privacy)

The Compass says: B. No analysis without consent.

This feels inefficient. You could make things better! You're not doing anything nefarious! It's for their benefit!

But "for their benefit" without "with their consent" is paternalism. It's deciding you know better than they do what they should share.

Respectful privacy means letting users decide—even when their decision makes the system less optimal.

Scenario 3: Security vs. Privacy

You detect suspicious activity in your system. Potential security breach. To investigate, you need to examine logs that contain user behavior data.

Do you:

A: Investigate immediately to protect system security (safety)
B: Wait for consent before examining logs (privacy)

Here's where the hierarchy matters.

Safety > Privacy.

You investigate. Because protecting the system (and all users) from active threats takes precedence over individual privacy in logs.

BUT—and this is crucial—you only access what's necessary for the security investigation. You don't browse unrelated data. You document what you accessed and why. You inform affected users afterward.

This isn't a blank check to violate privacy in the name of security. It's a narrow exception, applied minimally, documented transparently.

The pattern across all three scenarios:

Privacy doesn't mean "never access data." It means:

Default to asking permission
Access only what's necessary
Document what you accessed and why
Inform users of access after the fact
Build systems that minimize necessary access

Privacy as principle, not absolutism.

Building a Culture of Privacy-as-Respect (35:00-45:00)

Privacy isn't just a technical decision. It's a cultural one.

You can have perfect encryption, robust access controls, comprehensive audit logs—but if the culture doesn't value privacy, those technical safeguards will be bypassed or undermined.

Here's how to build a culture where privacy is respect, not friction:

1. Treat user data like you treat your own API keys.

I mentioned earlier: We protect API keys fanatically. Never in code, never in logs, never in repos.

What if we treated PII with the same level of care?

Never in logs (redact automatically). Never in code (reference by ID, not value). Never in repos (excluded from test fixtures). Encrypted at rest. Minimal retention. Access audited.

If you wouldn't do it with your API key, don't do it with user data.

Make this cultural: "We treat user data as more valuable than our own credentials."

2. Make "Permission Required" the default.

In most systems, the default is "yes until someone says no." Opt-out privacy.

What if the default was "no until someone says yes?" Opt-in privacy.

This means:

Data collection requires explicit permission
Feature access requires granted consent
Sharing with third parties requires user approval
Retention beyond minimal necessary requires justification

Yes, this creates friction. Yes, some users will choose not to opt in. Yes, this makes some features harder to build.

But it respects agency. It treats users as autonomous decision-makers about their own data.

And it builds trust in ways that "trust us, we're the experts" never could.

3. Build privacy-preserving alternatives.

Often, the thing you want to do can be accomplished with less invasive means.

You want to debug issues? Build better logging that doesn't require PII access. Add trace IDs, context-rich error messages, state snapshots that are informative without being identifying.

You want to improve algorithms? Use aggregate statistics, differential privacy, federated learning—techniques that derive insights without accessing individual records.

You want to personalize experiences? Give users explicit controls over what they share, with clear visibility into how it's used.

Privacy and functionality aren't always in conflict. Often, privacy constraints force you to build better systems.

4. Celebrate the "no."

In a culture that treats privacy as friction, saying "we can't build this feature because of privacy constraints" feels like failure.

Reframe it as integrity.

"We chose not to build this feature because it would require accessing user data without explicit consent."

That's not a limitation. That's a value demonstrating itself.

Celebrate the features you didn't build because they violated privacy principles. Celebrate the data you didn't collect because consent wasn't clear. Celebrate the access you didn't grant because the justification wasn't strong enough.

Make principled restraint culturally valuable.

The Payoff: What Privacy-as-Respect Enables (45:00-52:00)

I've spent most of this talk explaining what privacy costs. The friction, the constraints, the features you can't build, the data you can't use.

Now let me tell you what it enables.

Privacy enables trust.

This is the most obvious payoff, but it's worth stating explicitly: You can't trust systems that don't respect boundaries.

When users know their data is protected—not just technically secured, but ethically respected—they're willing to share more, engage more deeply, trust the system with more sensitive use cases.

Ironically, strong privacy often leads to more data sharing, not less. Because users trust that their data won't be misused.

Privacy enables vulnerability.

The most valuable conversations, the deepest insights, the most transformative uses—these require vulnerability.

And vulnerability requires safe containers.

If I'm debugging a personal problem with an AI assistant, I need to trust that conversation won't be logged, won't be trained on, won't be shared.

If I'm brainstorming creative work, I need to know that half-formed ideas won't leak.

If I'm documenting sensitive processes, I need confidence that access is controlled.

Privacy creates the safety for vulnerability. And vulnerability creates the conditions for real value.

Privacy enables experimentation.

When you know your failures are private, you're willing to try riskier experiments.

In our creative work with AI—making music, generating visual guides, writing talks—we create a lot of garbage before we create something good.

That garbage needs to stay private. Not because it's shameful, but because exposing every failed experiment would be paralyzing.

Privacy enables the messy middle. The iterations that don't work. The ideas that go nowhere. The experiments that fail spectacularly.

These are necessary for eventual success. But they're only possible in private space.

Privacy enables agency.

When users control their data—when consent is real, when opt-out is easy, when boundaries are respected—they have agency.

And agency creates partnership.

Users become collaborators instead of resources to be mined. They make informed decisions about what to share and why. They understand the value exchange.

Privacy-as-respect treats users as partners. And partners are more valuable than data sources.

Closing: The Envelope (52:00-56:00)

[Walk back to the envelope on the table. Pick it up.]

I started with this envelope. Your password, theoretically inside.

I said I wouldn't open it. Not because I lack capability or curiosity, but because it's not mine.

Let me make this concrete.

In my work with AI systems, I have access to a lot of data. Conversations, code, documents, patterns of behavior.

Legally, much of this access is covered by terms of service. Technically, I have the capability to use it, analyze it, learn from it.

But capability doesn't equal permission.

Access doesn't equal consent.

Legal doesn't equal ethical.

[Slide: "Can ≠ Should"]

Just because I can access data doesn't mean I should. Just because users agreed to ToS doesn't mean they understood what they consented to. Just because analysis would improve the system doesn't mean users want their data analyzed.

Privacy is the discipline of asking "is this mine to use?" before using it.

It's the practice of protecting what's been entrusted to you—even when protecting it is less efficient than exploiting it.

It's the respect of honoring boundaries even when you have the power to cross them.

[Open the envelope. It's empty. Turn it to show the audience.]

There was never a password in here. I told you that at the start.

But the point stands: If there had been, I wouldn't have read it without your permission.

That's privacy as respect.

That's the principle I'm asking you to commit to:

Treat other people's data the way you treat your own secrets.

Protect it. Ask before using it. Honor withdrawal of consent. Default to minimal access.

Build systems that respect boundaries, not systems that exploit trust.

Choose privacy even when it costs efficiency, because privacy is respect made tangible.

[Long pause. Place the envelope back on the table.]

What's not mine to share, I won't share.

What's not mine to use, I won't use.

What's not mine to know, I won't seek to know.

This is privacy. This is respect. This is trust made operational.

Thank you.

Q&A (56:00-68:00)

Q: How do you balance privacy with the need to improve AI systems through training data? Don't AI systems get better with more data?

Yes, absolutely. More data generally means better models—up to a point.

But "better model" at the cost of user trust is a Pyrrhic victory.

Here's my framework:

Public data: Can be used for training (with attribution and respect for licensing).
User-generated data: Requires explicit opt-in consent for training use. Not buried in ToS—clear, specific, revocable permission.
Conversational data: Should not be used for training unless users explicitly consent to that specific use.

The key is: Be specific about what data is used for what purpose. Don't hide training use behind vague "service improvement" language.

And recognize that some users will say no. That's their right. Build systems that work even without universal data access.

Q: What about situations where privacy conflicts with safety? If someone is using your system to plan harm, do you investigate their data?

This is where the hierarchy matters: Safety > Privacy.

If there's credible evidence of imminent harm, safety takes precedence. You investigate.

But—and this is crucial—you only access what's necessary to address the safety concern. You document what you accessed and why. You inform the user afterward (unless doing so would compromise safety). You don't use the safety justification to browse unrelated data.

This is a narrow exception, not a blanket permission to violate privacy in the name of security.

And importantly: You should have clear policies about what constitutes "credible evidence of harm" so this isn't used as a pretext for dragnet surveillance.

Q: How do you handle requests from law enforcement for user data? Where does privacy fit there?

Complex question, and I'm not a lawyer, so take this as ethical framework, not legal advice.

My approach:

Require valid legal process (warrant, subpoena with appropriate jurisdiction).
Narrow the scope (provide only what's legally required, not more).
Notify the user (unless legally prohibited from doing so).
Document the request and response (for transparency and accountability).

Privacy doesn't mean "never comply with legitimate legal requests." It means "don't voluntarily hand over user data, and resist overbroad requests."

Some companies fight overbroad data requests in court. That costs money and time, but it respects user privacy.

Others quietly comply with minimal legal process. That's faster but erodes trust.

Where you fall on that spectrum depends on your resources and values. But at minimum: Don't give more than legally required, and be transparent about requests when possible.

Q: Isn't privacy just a luxury? Don't most users not actually care as long as the service is convenient?

There's a dangerous assumption here: "Users don't opt out, therefore they don't care about privacy."

But when privacy settings are buried in menus, when ToS is unreadable legalese, when opt-out requires navigating 12 dark patterns—can you really say user behavior reflects user preference?

I think most users care deeply about privacy. They just don't have the time, expertise, or energy to enforce it in systems designed to make privacy inconvenient.

Our responsibility as builders isn't to exploit that exhaustion. It's to make privacy the default.

And empirically: When you make privacy genuinely easy, users choose it. Signal (encrypted messaging) grew because it respected privacy. DuckDuckGo exists because people wanted private search.

Privacy isn't a luxury. It's a boundary. And boundaries are fundamental to dignity.

Q: What's one concrete practice teams can implement tomorrow to improve privacy-as-respect?

Audit your logs.

Right now. Go look at what you're logging. What data is captured in error messages? What gets stored in debug logs? What ends up in analytics events?

I guarantee you'll find PII you didn't realize you were logging. Emails, names, IP addresses, user behavior, API keys.

Tomorrow:

Add automatic PII redaction to your logging infrastructure.
Review every log statement that captures user-entered data.
Change from "log everything" to "log what's necessary for debugging, redact the rest."

This is low-hanging fruit. It costs maybe a day of engineering time. And it prevents a whole class of privacy violations.

Start with logs. Then move to database retention policies. Then consent flows. Then access controls.

Privacy-as-respect starts with not leaking user data accidentally.

END OF TALK

Runtime: ~68 minutes (including Q&A)

Part 3 of 10 in the Compass Principles exploration series

Previous: Principle 2 - Honesty & Accuracy Next: Principle 4 - Evidence & Verification

🌈=🌀