Anonymity Limits

gitGost provides practical anonymity for most open-source contributors, but it is not a perfect anonymity tool. This page details the scenarios where gitGost’s protections are insufficient.

Critical: Read this before relying on gitGost for high-risk contributions.

When gitGost is NOT Sufficient

State-Level Adversaries

gitGost cannot protect against nation-state actors with network surveillance capabilities.

Whistleblowing

Use dedicated tools like SecureDrop, not gitGost.

Legal Exposure

If deanonymization has legal consequences, gitGost is insufficient.

Targeted Investigations

Determined adversaries with resources can correlate timing, style, and network data.

IP Visibility and Network Exposure

The Problem

gitGost does not hide your IP address by itself. GitHub and the gitGost operator can see the source IP of your connection if you push directly.

Without VPN/Tor, your IP is exposed to:

The gitGost operator (via TCP connection)
GitHub (via gitGost’s outbound connection, revealing operator IP, not yours—but timing correlation can still apply)
Your ISP (can see you connected to gitGost)
Network observers (if not using HTTPS, though gitGost uses HTTPS)

The Solution: Tor or Trustworthy VPN

Use Tor Browser or Tor-enabled Git

Route git traffic through Tor to anonymize your IP:

# Via Tor SOCKS proxy
git config --global http.proxy socks5h://127.0.0.1:9050
git push gost main

Or Use a Trustworthy VPN

Choose a VPN provider with:

No-logs policy (audited, not just claimed)
Anonymous payment (crypto, cash)
No email registration

Examples: Mullvad, ProtonVPN (paid), IVPN

Verify Your IP is Hidden

Before pushing, confirm your IP is masked:

curl https://api.ipify.org
# Should show VPN/Tor exit node IP, not your real IP

Network metadata: Even with Tor/VPN, the gitGost operator can see:

You connected at a specific time
The size of your push
The target repository

They cannot see your real IP, but timing correlation is still possible.

Code Style Analysis

The Problem

gitGost strips metadata (name, email, timestamp) but cannot strip your coding style. Experienced maintainers or automated tools can attribute code based on:

Variable Naming Conventions

Consistent use of ctx vs context vs c for context variables
Preference for err vs error vs e
Specific abbreviation patterns (e.g., usr vs user, msg vs message)

Error Handling Patterns

Specific error message formats (“failed to X: %v” vs “X failed: %v”)
Use of fmt.Errorf vs errors.New
Wrapping vs returning errors directly

Code Structure

Preference for early returns vs nested if/else
Consistent use of guard clauses
Specific function ordering patterns

Comments & Documentation

Language patterns (British vs American English)
Emoji usage in comments
Level of detail in docstrings

Testing Style

Table-driven tests vs individual test functions
Specific assertion patterns
Mock usage and setup style

Real Example

// Your usual style (identifiable)
func processUser(ctx context.Context, userId int64) error {
    usr, err := db.GetUser(ctx, userId)
    if err != nil {
        return fmt.Errorf("failed to fetch user: %w", err)
    }
    // ...
}

// Anonymous style (generic)
func processUser(c context.Context, id int64) error {
    user, e := db.GetUser(c, id)
    if e != nil {
        return e // Less distinctive error wrapping
    }
    // ...
}

The Solution: Conscious Style Variation

Study the Target Project's Style

Match the existing codebase patterns:

# Analyze variable naming in the target repo
git clone https://github.com/target/repo
grep -r "context\.Context" . | head -20

Use Generic Patterns

Follow language idioms strictly (e.g., Go’s Effective Go)
Avoid personal idioms or “clever” code
Use standard library patterns over custom abstractions

Write Neutral Commit Messages

Avoid:

Emoji (unless common in the target repo)
Personal phrases (“I think”, “IMHO”)
Consistent formatting quirks (always capitalizing types, etc.)

Use:

Imperative mood: “Fix bug” not “Fixed bug” or “Fixes bug”
Generic descriptions: “Update documentation” not “Improve docs readability”

Automated stylometry tools exist. Research has shown that code authorship can be attributed with 90%+ accuracy using machine learning on style features.References:

“De-anonymizing Programmers via Code Stylometry” (USENIX Security ‘15)
“When Coding Style Survives Compilation” (NDSS ‘18)

Temporal Correlation

The Problem

An observer who monitors both your activity and the target repository can correlate based on timing:

You mention working on a feature at 3:45 PM (e.g., in another community)
An anonymous PR for that feature appears at 3:47 PM
Observer links the two events

Attack Scenarios

Low-Traffic Services

If gitGost has few concurrent users, your push time uniquely identifies you:

Push at 2:13 AM → PR created at 2:13 AM
No other PRs in ±10 minutes
Obvious correlation

Public Activity Correlation

Observer monitors your GitHub activity:

Your main account last active: 11:34 PM
Anonymous PR created: 11:36 PM
Both in US Eastern timezone
Correlation over multiple occurrences reveals pattern

Low-Activity Target Repos

Repos with few contributors:

Project receives 1 PR every 2 weeks
You push anonymously same day you discuss the issue in Discord
Timing + context reveals authorship

The Solution: Timing Obfuscation

Batch Pushes

Wait to accumulate multiple PRs, push all at once:

# Instead of pushing immediately
git push gost feat-1

# Wait days/weeks, then batch
git push gost feat-1
git push gost feat-2
git push gost fix-typo

Add Random Delays

Script delays into your workflow:

#!/bin/bash
# Random delay between 1-6 hours
sleep $((3600 + RANDOM % 18000))
git push gost main

Use Scheduled Pushes

Push at fixed, generic times:

# Every Saturday at 10 AM UTC via cron
0 10 * * 6 cd /path/to/repo && git push gost main

Vary Timezone Appearance

Push at times inconsistent with your known timezone:

If you’re in US Eastern, push during EU working hours
Randomize to avoid establishing a new pattern

Operator-side jitter: Some gitGost operators may add server-side delays or queuing. Check the operator’s transparency policy. The official instance at gitgost.leapcell.app processes immediately (minimal jitter).

Small PR Attribution in Low-Activity Projects

The Problem

Small, unique PRs are inherently attributable:

Example: 1-line typo fix in a README that receives 2 PRs/year
Context: You reported the typo in an issue 3 days ago
Result: Obvious you’re the contributor, anonymity ineffective

The Solution

gitGost is best suited for:

Active projects with regular contributions
Non-trivial PRs (features, refactors) that blend in
Repos where multiple contributors work concurrently

Avoid using gitGost for:

Tiny typo fixes in low-activity repos
PRs to repos you maintain or frequently contribute to publicly
Unique features you’ve discussed publicly under your real identity

Private Repositories

gitGost is designed for public repositories only.

Why private repos are problematic:

Operator knows which private repos you’re contributing to (exposes project context)
GitHub sees your fork of a private repo (requires authentication, harder to anonymize)
Fewer contributors = easier correlation

Solution: Use gitGost only for public repositories. For private repos, use established team processes with your real identity.

Hostile Operators

The Problem

A malicious operator could:

Log IP addresses (despite policy claiming otherwise)
Add hidden telemetry
Correlate push timing with other data sources
Keep detailed records for later analysis

The Solution: Trust or Self-Host

Use a Trusted Operator

Operators with:

Public privacy policy (specific, not vague)
Open-source deployment (auditable)
Transparency reports (published stats)
Reputation in community

Self-Host gitGost

Run your own instance:

git clone https://github.com/livrasand/gitGost
cd gitGost
# Configure environment (see deployment docs)
go run cmd/server/main.go

Pros: Complete control, no operator trust requiredCons: Your server IP is visible to GitHub (use VPN/proxy at server level)

Verify Open Source

Audit the code yourself:

Check router.go:129-136 for disabled logging
Verify handlers.go doesn’t log IPs
Review database schema for personal data

Open source ≠ automatic trust, but enables verification.

Platform-Level Attacks

Out of Scope Threats

gitGost cannot protect against:

GitHub compromise (attacker gains access to GitHub’s servers)
MITM attacks (attacker intercepts HTTPS traffic via certificate compromise)
Operator infrastructure breach (attacker gains root on gitGost server and patches running binary)
Side-channel attacks (timing attacks on GitHub API, DNS correlation, etc.)

These are inherent limitations of any hosted service. If your threat model includes these scenarios, consider:

Cryptographic signing with offline keys
Air-gapped systems
Specialized tools designed for high-risk scenarios (e.g., Qubes OS, Tails)

Summary: Is gitGost Right for You?

gitGost is SUITABLE for:

Contributing to public open-source projects without linking to your GitHub account
Avoiding employer/institutional attribution
Protecting against casual deanonymization
Separating personal and professional identities

gitGost is NOT suitable for:

Whistleblowing or high-risk leaks (use SecureDrop, Tor-only platforms)
Evading state-level surveillance
Contributing to CLA-required projects
Scenarios where deanonymization has severe legal consequences
Private repositories

Threat Model Quick Reference

Threat	gitGost Protection	Additional Steps Required
IP exposure	❌ None	✅ Use Tor/VPN
Code style attribution	❌ None	✅ Vary style, match target repo
Temporal correlation	⚠️ Partial (immediate processing)	✅ Add delays, batch pushes
Metadata exposure	✅ Full (name, email, timestamp stripped)	❌ None
GitHub account linking	✅ Full (PRs from `@gitgost-anonymous`)	❌ None
Commit history tracking	✅ Full (stateless, stream-only)	❌ None
Hostile operator	⚠️ Depends on operator	✅ Self-host or verify open source
State-level adversary	❌ None	⛔ Use specialized tools

Threat Model

Detailed attack vectors and mitigations

Privacy Guarantees

What data is stored and retained

Tor Integration

Hide your IP address with Tor

Self-Hosting

Run your own gitGost instance

Get Started

Guides

Privacy & Security

Use Cases

Anonymity Limits

When gitGost is NOT Sufficient

State-Level Adversaries

Whistleblowing

Legal Exposure

Targeted Investigations

IP Visibility and Network Exposure

The Problem

The Solution: Tor or Trustworthy VPN

Code Style Analysis

The Problem

Real Example

The Solution: Conscious Style Variation

Temporal Correlation

The Problem

Attack Scenarios

The Solution: Timing Obfuscation

Small PR Attribution in Low-Activity Projects

The Problem

The Solution

Private Repositories

Hostile Operators

The Problem

The Solution: Trust or Self-Host

Platform-Level Attacks

Out of Scope Threats

Summary: Is gitGost Right for You?

gitGost is SUITABLE for:

gitGost is NOT suitable for:

Threat Model Quick Reference

Threat Model

Privacy Guarantees

Tor Integration

Self-Hosting

Build docs developers (and LLMs) love

Get Started

Guides

Privacy & Security

Use Cases

​When gitGost is NOT Sufficient

State-Level Adversaries

Whistleblowing

Legal Exposure

Targeted Investigations

​IP Visibility and Network Exposure

​The Problem

​The Solution: Tor or Trustworthy VPN

​Code Style Analysis

​The Problem

​Real Example

​The Solution: Conscious Style Variation

​Temporal Correlation

​The Problem

​Attack Scenarios

​The Solution: Timing Obfuscation

​Small PR Attribution in Low-Activity Projects

​The Problem

​The Solution

​Private Repositories

​Hostile Operators

​The Problem

​The Solution: Trust or Self-Host

​Platform-Level Attacks

​Out of Scope Threats

​Summary: Is gitGost Right for You?

gitGost is SUITABLE for:

gitGost is NOT suitable for:

​Threat Model Quick Reference

​Related Documentation

Threat Model

Privacy Guarantees

Tor Integration

Self-Hosting

Build docs developers (and LLMs) love

When gitGost is NOT Sufficient

IP Visibility and Network Exposure

The Problem

The Solution: Tor or Trustworthy VPN

Code Style Analysis

The Problem

Real Example

The Solution: Conscious Style Variation

Temporal Correlation

The Problem

Attack Scenarios

The Solution: Timing Obfuscation

Small PR Attribution in Low-Activity Projects

The Problem

The Solution

Private Repositories

Hostile Operators

The Problem

The Solution: Trust or Self-Host

Platform-Level Attacks

Out of Scope Threats

Summary: Is gitGost Right for You?

Threat Model Quick Reference

Related Documentation