Skip to content

Security: CanaryInAMine/Canary

Security

SECURITY.md

Security Policy

This document covers two distinct security topics:

  1. Reporting vulnerabilities in Canary's code
  2. Operational security guidance for users investigating sensitive topics

Reporting Vulnerabilities

Supported Versions

Version Supported
0.1.x

Reporting a Vulnerability

If you discover a security vulnerability in Canary, please report it responsibly:

  1. Do not open a public GitHub issue
  2. Email the maintainers at the address in the repository (or use GitHub's private vulnerability reporting if enabled)
  3. Include:
    • Description of the vulnerability
    • Steps to reproduce
    • Potential impact
    • Suggested fix (if any)

We aim to acknowledge reports within 48 hours and provide a fix timeline within 7 days.


Operational Security for Users

Canary is designed for investigating potentially sensitive topics. While all data sources are public, the act of investigation may draw attention. This guide helps you protect yourself.

Threat Model

Consider who might be interested in your investigation:

Threat Risk Level Mitigation
Subjects of investigation Medium Use pseudonyms, secure communications
Network observers Low-Medium VPN/Tor for scraping and research
Device compromise Low Full-disk encryption, screen locks
Legal discovery Variable Understand local shield laws

Before You Begin

1. Secure Your Environment

[ ] Device has full-disk encryption enabled
[ ] Screen lock is configured (short timeout)
[ ] OS and browser are up to date
[ ] No unnecessary browser extensions installed
[ ] Using a dedicated browser profile or VM

2. Network Privacy

For routine research:

  • A reputable commercial VPN is sufficient
  • Choose servers outside jurisdictions of interest

For sensitive investigations:

  • Consider Tor Browser for web research
  • Use Tails OS for maximum compartmentalization
  • Be aware that Tor exit nodes can see unencrypted traffic

What Canary accesses:

  • State licensing databases (public government websites)
  • US Census Bureau API (geocoding)
  • Optional: FEC, SAM.gov, and other federal APIs
  • Optional: AI providers if configured (see Privacy section below)

3. Data Storage

Canary stores all data locally in data/canary.db (SQLite). Consider:

[ ] Database location is on encrypted storage
[ ] Backup strategy that maintains confidentiality
[ ] Clear plan for secure deletion when investigation concludes

Secure deletion on different platforms:

  • macOS: rm -P data/canary.db (3-pass overwrite)
  • Linux: shred -u data/canary.db
  • Windows: Use a secure deletion tool

During Investigation

1. Pseudonymous Research

If you need to create accounts (for API keys, etc.):

  • Use a dedicated email address (ProtonMail, Tutanota)
  • Never reuse usernames from personal accounts
  • Pay with privacy-preserving methods if subscriptions are needed

2. Note-Taking Hygiene

  • Keep investigation notes in encrypted storage
  • Avoid cloud sync for sensitive working documents
  • Use Signal or encrypted email for collaborator communication

3. AI Provider Privacy

If using AI features:

Provider Data Sent Privacy Notes
Ollama Nothing external Runs 100% locally
LM Studio Nothing external Runs 100% locally
OpenAI Query text Subject to OpenAI data policies
Anthropic Query text Subject to Anthropic data policies
Google Query text Subject to Google data policies
xAI Query text Subject to xAI data policies

Recommendation: Use local providers (Ollama, LM Studio) for sensitive investigations. Cloud providers may log queries.

4. Evidence Collection

When attaching evidence files:

  • Strip metadata from images before import (exiftool -all= photo.jpg)
  • PDF files may contain author/creation metadata
  • Screenshots may contain identifying information in browser UI

Sharing Findings

1. Before Publication

[ ] Findings independently verified
[ ] Legal review completed (if publishing)
[ ] Subjects given opportunity to respond (journalistic ethics)
[ ] Personal information of uninvolved parties redacted

2. Exporting Data

When sharing databases or reports:

  • Export only necessary records, not entire database
  • Review exports for unintended personal data
  • Use encrypted channels for sharing (Signal, encrypted email)

3. Protecting Sources

If your investigation involved tips or sources:

  • Never include source-identifying information in Canary
  • Keep source communications separate from investigation data
  • Consider legal protections available in your jurisdiction

Legal Considerations

This is not legal advice. Consult qualified counsel for your jurisdiction.

  • Accessing public records is generally lawful
  • Web scraping of public data is generally permitted (see hiQ v. LinkedIn)
  • Publishing findings may have defamation implications
  • Journalist shield laws vary by jurisdiction
  • FOIA/public records requests are complementary tools

Incident Response

If you believe your investigation has been compromised:

  1. Stop using the affected device/account
  2. Preserve evidence of the compromise
  3. Assess what data may have been accessed
  4. Notify affected parties if appropriate
  5. Report to relevant authorities if criminal activity suspected

Additional Resources


Security by Design

Canary incorporates these security principles:

Principle Implementation
Local-first No cloud accounts, no telemetry, no external databases
Minimal permissions Only accesses explicitly requested data sources
Secure storage API keys stored in OS keyring, not config files
No phone-home Zero analytics, zero tracking, zero remote calls except data fetching
Transparent code Open source for full auditability

Questions

For security questions not covered here, open a GitHub Discussion or contact maintainers directly.

There aren’t any published security advisories