DEV Community: livrasand

What GitHub Doesn't Tell You About Your Privacy 🔍

livrasand — Wed, 21 Oct 2026 15:00:00 +0000

GitHub is an incredible platform for building software, collaborating with developers, and contributing to open source.

I use it every day. I maintain open-source projects, review code, manage releases, and collaborate with people around the world.

But there's something worth remembering: publishing code is not the same as publishing only code.

Every repository, commit, issue, pull request, and contribution can reveal information about the people behind it. Some of that information is obvious. Other details are easy to overlook.

In a previous article, I explored how your Git commit history can reveal more than you think. This time, I want to look at the bigger picture: the information developers expose when they work with GitHub, often without realizing it.

This isn't about avoiding GitHub. It's about understanding what you're sharing.

1. Your commit history is a timeline of your activity

A Git commit is more than a snapshot of your code.

It can contain:

The author and committer names.
Email addresses.
Timestamps.
Commit messages.
References to previous commits.
Changes to files and project structure.

Consider a commit created with the following command:

git log --format=fuller -n 1

Depending on the repository and commit, the output may include author and committer identities and timestamps.

Your commit messages can also reveal more than intended.

For example:

Fix authentication for internal staging server

Or:

Temporarily disable payment validation

These messages might expose internal architecture, development practices, or implementation details that weren't meant for a public audience.

A commit message isn't automatically dangerous. Context matters. But once a repository is public, its history can become a permanent record of your development process.

Before making a repository public, review its history, not just its latest files.

2. Your email address might be public

Git associates commits with author and committer identities. These identities commonly include an email address.

If you use your personal email for commits, it may appear in publicly accessible commit metadata.

GitHub provides a no-reply email address that you can use to help protect your personal email address when making commits.

You can inspect your current Git configuration with:

git config --get user.name
git config --get user.email

To configure your identity for future commits:

git config --global user.name "Your Name"
git config --global user.email "YOUR_NOREPLY_EMAIL"

Replace the example values with your preferred identity and the no-reply address associated with your GitHub account.

Keep in mind that changing your Git configuration affects future commits. It does not rewrite the identity recorded in existing commits.

Also, a no-reply email protects only one part of your identity. Your public profile, commit history, usernames, and other activity can still help people connect contributions to you.

Privacy isn't a single setting. It's a collection of decisions.

3. Deleted information isn't necessarily gone

Imagine you accidentally commit a file containing an API key.

You notice the mistake, delete the file, and push another commit.

Problem solved?

Not necessarily.

Git stores project history. Removing a file from the latest version doesn't automatically remove it from earlier commits.

Someone who can access the repository's history may still be able to retrieve the file and inspect its contents.

The same principle applies to:

Credentials accidentally committed to a repository.
Internal configuration files.
Personal information in test fixtures.
Private URLs and infrastructure details.
Files that were intended to remain local.

If a secret has been exposed, deleting it isn't enough. Revoke or rotate the credential first. Then assess the exposure, remove the sensitive material from the relevant history where appropriate, and follow the hosting platform's guidance for sensitive data removal.

Rewriting Git history can help remove exposed content, but it doesn't guarantee that every copy disappears. Forks, clones, cached content, and existing references may persist.

The best solution is prevention.

Use a .gitignore file, keep secrets outside your repository, and consider secret-scanning tools before pushing changes.

For example:

.env
.env.*
!.env.example
*.pem
*.key

This is only a starting point. Review these patterns against your project requirements, and never assume .gitignore protects a file that has already been tracked.

4. Your GitHub profile tells a story

Your public profile can reveal information beyond the repositories you maintain.

Depending on your settings and activity, visitors may discover:

Your public repositories and contribution history.
Your username across other websites.
Your professional interests and programming languages.
Your social links and personal website.
Your participation in issues, pull requests, and discussions.
Your working habits through timestamps and activity patterns.

Individually, these details might seem harmless.

Together, they can form a detailed picture of your professional life.

For example, someone might connect your GitHub username to another account, find your personal website, identify your employer from a repository, and use public activity to infer when you tend to work.

These connections aren't always accurate, and public information doesn't automatically create a security risk. However, the possibility is worth understanding.

If you want to reduce unnecessary exposure, review your profile and ask yourself a simple question:

Does every detail on this page need to be public?

You can share your work without sharing every aspect of your life.

5. Issues and pull requests can expose internal details

Code isn't the only information worth reviewing.

Issues, pull requests, discussions, and comments can contain details about your development environment and project infrastructure.

Examples include:

Screenshots containing usernames or local file paths.
Logs containing access tokens or session identifiers.
Stack traces that expose internal paths.
Descriptions of private infrastructure.
Links to internal dashboards or staging environments.
Reproduction steps containing real user data.

A screenshot can reveal more than the application you're trying to demonstrate. A log can include credentials even when the surrounding code looks harmless.

Before opening an issue or submitting a pull request, inspect the entire attachment, log, or code snippet.

When reporting bugs, use sanitized examples and synthetic data whenever possible.

And if you discover a security vulnerability, consider the project's private reporting mechanism rather than publishing exploit details immediately.

Open source works best when transparency is combined with responsible disclosure.

6. Your local machine can leak information too

Privacy problems don't always originate on GitHub.

Your development environment can accidentally introduce sensitive information into public repositories.

For example, a project might include:

.DS_Store
.vscode/settings.json
.idea/
debug.log
.env

Some of these files are harmless in many projects. Others may contain local paths, workspace preferences, environment-specific configuration, or credentials.

The important thing isn't to blindly exclude every configuration file. Some editor settings are useful to share with collaborators.

Instead, review what each file contains before committing it.

You can inspect the files Git is tracking with:

git ls-files

And inspect the changes you're about to commit with:

git diff --cached

These commands are simple, but they encourage a useful habit: inspect what you're actually publishing instead of assuming your repository contains only what you intended.

What about image metadata?

Screenshots, photographs, and other media can contain metadata such as timestamps, device information, and sometimes location coordinates.

Whether that information is present depends on the file format, device, application, and processing pipeline.

If you're publishing images, inspect their metadata before uploading them.

For JPEG files, you can use ExifTool:

exiftool image.jpg

To remove metadata from a copy of an image:

exiftool -all= -o cleaned.jpg image.jpg

Always verify the resulting file. Metadata removal behavior depends on the file type, and some formats contain information that requires additional handling.

I explored this topic in more detail in my article about wiping EXIF metadata before publishing open-source projects.

7. Public repositories can reveal your development infrastructure

A repository may expose more than application code.

Workflow files, build scripts, deployment configurations, and dependency manifests can reveal how a project is built and distributed.

For example, GitHub Actions workflows may show:

Which external actions your project uses.
How releases are built.
Which platforms are targeted.
Which deployment services are involved.
How permissions and credentials are handled.

This information is often intentionally public and helps people understand and reproduce your build process.

However, configuration mistakes can turn transparency into a security problem.

Never hardcode credentials in workflow files. Use appropriately scoped secrets, restrict workflow permissions, and review third-party actions before trusting them.

For sensitive workflows, pinning actions to full commit SHAs can reduce the risk of an upstream tag being moved to different code.

The goal isn't to hide your build process. It's to make the process understandable without exposing credentials or granting unnecessary access.

8. Can you contribute anonymously on GitHub?

This depends on what you mean by anonymous.

GitHub offers privacy-related features, including no-reply commit email addresses and options that limit some public profile information. These can help reduce exposure.

But using a different email address or hiding your email doesn't make your activity completely anonymous.

Your GitHub account, usernames, public contributions, commit metadata, and interactions can still be linked together. Git hosting services also need to process technical information to operate their infrastructure.

If you need stronger separation between your identity and your public contributions, think carefully about account identity, browser sessions, network exposure, commit metadata, and the information you publish.

Remember that a network intermediary or privacy gateway can introduce its own trust assumptions. It may reduce direct connections between your device and a destination, but it can also become another party that processes your requests.

No single tool can guarantee anonymity across every layer.

The right approach depends on your threat model: who you're trying to protect your identity from, what information you need to conceal, and what risks you're willing to accept.

9. A practical privacy checklist for developers

Before publishing a repository, creating an issue, or submitting a pull request, consider this checklist.

Review commit history before making an existing project public.
Check author and committer email addresses.
Search for credentials, tokens, private keys, and sensitive configuration.
Review .gitignore and ensure sensitive files aren't already tracked.
Inspect staged changes before committing.
Sanitize logs, screenshots, and bug reports.
Inspect image metadata when publishing photographs or screenshots.
Review workflow permissions and third-party GitHub Actions.
Remove unnecessary personal information from public profiles.
Use private vulnerability reporting when appropriate.
Rotate any credentials that have been exposed.
Remember that deleting a file doesn't erase every historical copy.

You don't need to become paranoid about every commit.

You just need to develop the habit of checking what you're sharing.

Final thoughts

GitHub is one of the most valuable tools in modern software development. Public repositories make collaboration possible, help developers learn from each other, and allow projects to grow beyond their original creators.

I don't think the answer is to stop sharing code.

I think the answer is to understand the boundaries between sharing your work and exposing information that doesn't need to be public.

Privacy isn't about hiding everything. It's about making informed decisions about what you reveal, to whom, and under what circumstances.

As developers, we spend a lot of time thinking about the security of the software we build. We should also spend some time thinking about the information our development workflows leave behind.

Because sometimes, the most revealing part of a repository isn't the code itself.

It's everything around it.

What about you? Have you ever discovered personal information, credentials, or unexpected metadata in a public repository? What steps do you take to protect your privacy when contributing to open source?

I'd love to hear your experiences in the comments.

I build open-source tools that explore privacy, user control, and more transparent software workflows. You can find my projects on GitHub.

Photo by: https://pixabay.com/photos/camera-spy-pigeon-surveillance-712122/

I Built a Gateway to Browse Git Repositories Without an Account

livrasand — Tue, 20 Oct 2026 15:00:00 +0000

Most developers are used to a simple assumption: if you want to participate in open source, you need an account on a platform like GitHub.

But what if you just want to explore a repository, read its code, report a bug, or submit a small fix without tying every action to your personal profile?

That question is one of the reasons I built gitGost.

Try it: https://gitgost.livrasand.com/

Source code: https://github.com/livrasand/gitGost

The problem with identity by default

Open source is built around public collaboration. That openness is valuable, but it can also create a permanent record of personal activity.

A public contribution can expose more than the code itself. Depending on how you contribute, your profile, commit author information, email address, timestamps, and activity history may become searchable and connected to your identity.

For many developers, this isn't a problem.

For others, it can be an unnecessary risk.

Maybe you want to fix a typo without adding another permanent entry to your contribution history. Maybe you want to participate in a controversial project without linking it to your professional profile. Or perhaps you simply prefer to share your work without sharing more personal information than necessary.

I don't think contributing to open source should always require that trade-off.

Privacy shouldn't be a prerequisite you have to sacrifice to participate in open source.

What is gitGost?

gitGost is an open-source, privacy-focused gateway for browsing and contributing to Git repositories.

It lets you explore repositories without creating an account on the platform you're browsing. It also provides a way to submit contributions without directly attaching your personal platform identity to them.

The project currently supports GitHub, GitLab, and Codeberg, with additional Git platforms planned.

You can browse repository files, branches, commits, releases, tags, issues, pull requests, wikis, and other project information through its web interface.

No account is required just to explore.

The goal isn't to replace GitHub or other Git platforms. It's to offer another way to access and participate in the open-source ecosystem.

Browsing without an account

Sometimes you don't need a social profile, a contribution graph, or another account.

You just need the code.

With gitGost, you can explore repositories and discover projects without signing in. That makes it useful for reading source code, checking a project's activity, reviewing releases, and learning from other developers' work.

It also reduces the need to expose your browsing activity to a platform through a personal account.

This is a simple idea, but I think it's worth building tools around: accessing public code shouldn't always require establishing a personal identity first.

Contributing anonymously with Git

I also wanted gitGost to work with the tools developers already use.

You don't need a special Git client or a browser extension to submit a code contribution. You can use Git from your terminal and add gitGost as another remote.

For example, suppose you want to contribute a documentation fix to a public repository.

First, add the gitGost remote:

git remote add gost https://gitgost.livrasand.com/v1/gh/username/repo

Create a branch and make your changes as usual:

git checkout -b fix-documentation
git commit -am "fix: correct a typo in the documentation"

Then push your branch through gitGost:

git push gost fix-documentation:main

The gateway processes the contribution and, for supported workflows, opens a pull request through its anonymous contribution identity.

The exact behavior depends on the target platform and the configured workflow, but the idea is straightforward: you can use your existing Git workflow without directly linking the contribution to your personal platform account.

No need to replace Git. No need to learn a new version control system.

Just another remote.

What about commit metadata?

Git commits can contain author names, email addresses, and timestamps. That information can remain in repository history long after the original contribution was made.

gitGost is designed to minimize this exposure by stripping identifying authorship metadata from supported contribution workflows and using a neutral identity for pull requests.

This helps reduce direct links between a contribution and a personal profile.

However, metadata is only one part of the problem.

Your code can reveal information through distinctive coding patterns. Commit messages may contain recognizable phrases. The timing of a contribution can be correlated with activity elsewhere. Files you upload may contain EXIF or other embedded metadata.

An anonymous contribution is not automatically an unidentifiable contribution.

That's why I prefer to describe gitGost as a privacy tool with explicit limitations, rather than promise perfect anonymity.

An important limitation: your IP address

There is something users should understand before using gitGost.

The destination platform does not automatically see your original IP address, but the gitGost server can.

When you connect directly to the public gitGost instance, the server receives your network connection. Routing a contribution through a gateway changes which IP address the destination platform sees; it does not, by itself, hide your IP from the gateway operator.

If you need stronger network-level privacy, consider routing your connection through Tor or another trusted privacy network. That still doesn't eliminate every possible identification risk.

You should also consider code style, timing correlation, commit content, and metadata embedded in files.

For a detailed explanation of the project's assumptions and limitations, see the gitGost threat model.

I believe privacy tools should explain what they protect against, what they don't protect against, and which parties still need to be trusted.

Anything less would be misleading.

Privacy and accountability can coexist

Anonymous contributions can be abused. That's a real concern, and ignoring it would make the project less useful for everyone.

gitGost is intended for legitimate, good-faith contributions, not harassment, spam, malicious code, or evading bans and moderation.

The project includes rate limits, repository and commit size restrictions, validation, and other safeguards to reduce abuse. Contributions still go through the destination project's review process, and maintainers retain control over whether they accept changes.

Repository maintainers can also opt out of anonymous contributions through a .gitgost.yml configuration file:

DENY_ALL: true

Privacy doesn't mean that maintainers lose control of their projects.

It means contributors can have another option when personal attribution isn't necessary.

Why make it open source?

A privacy tool asks users to trust the software handling their requests. That makes transparency especially important.

gitGost is licensed under AGPL-3.0. You can inspect the implementation, report problems, contribute improvements, or run your own instance.

Self-hosting gives you more control over the infrastructure you trust, although it also means you're responsible for operating and securing it.

I don't want privacy to be a promise that users have to accept on faith. I'd rather make the implementation available for people to examine.

Who is gitGost for?

I built gitGost for developers who want more control over how their public contributions are associated with their identities.

That might mean someone who wants to avoid unnecessary email exposure, a developer who doesn't want every small fix attached to a professional profile, or someone contributing to a project where public attribution could create personal or professional complications.

It can also be useful for people who simply want to browse public repositories without creating yet another account.

You don't need a dramatic reason to care about privacy.

Sometimes, not wanting to publish more personal information than necessary is reason enough.

Try it, inspect it, or contribute

gitGost is an ongoing open-source project, and there is still plenty of work to do.

If you're interested in privacy, Git infrastructure, or making open source more accessible, I'd appreciate your feedback and contributions.

Explore the web interface: https://gitgost.livrasand.com/
Read the source code: https://github.com/livrasand/gitGost
Review the threat model: https://github.com/livrasand/gitGost/blob/main/THREAT_MODEL.md
Read the license: https://github.com/livrasand/gitGost/blob/main/LICENSE

I'm not trying to remove identity from every part of software development. There are many situations where attribution is useful and deserved.

I just believe developers should have a choice.

Open source can be public without requiring every participant to expose their personal identity in the same way.

Browse freely. Contribute responsibly. Be a gost. 👻

Cover photo by: unsplash.com · A person is coding on a laptop at night. photo – Free Image on Unsplash

Your Desktop Apps Deserve Updates Straight from the Source

livrasand — Sun, 18 Oct 2026 14:56:29 +0000

When we install software on our computers, we rarely think about the journey a new version takes before reaching us.

We download applications from websites, install package managers, add third-party repositories, or wait for someone else to package the latest release. These approaches can be convenient, but they also introduce another question:

Why should updating an open-source application depend on someone other than its original developer?

For desktop applications distributed through GitHub, GitLab, Gitea, Forgejo, and similar platforms, the release artifacts are often already available. Developers publish binaries, attach them to releases, and make them accessible to anyone.

Yet discovering and downloading those files can still be a surprisingly manual process.

That's the problem I'm exploring with Updainium.

The Desktop Update Problem

Consider a simple scenario.

You use an open-source application that you downloaded six months ago. The developer has released three new versions since then, including security fixes and improvements.

How do you find out?

Perhaps you bookmarked the repository. Maybe you follow the developer on social media. Or perhaps you periodically open the application's website to check whether a new version is available.

Now imagine doing this for ten, twenty, or fifty applications.

The problem isn't that downloading software is difficult. It's that keeping track of independently maintained applications becomes tedious when every project has its own release page, naming conventions, and distribution methods.

Package managers solve part of this problem, but they aren't always the ideal solution for every project.

Some applications aren't available in your package manager. Others depend on community-maintained manifests or repositories. And sometimes, you simply want the binary published by the project's own maintainers.

Package Managers Aren't the Enemy

Let's be clear: package managers are excellent tools.

Homebrew, APT, winget, and other package management systems make software installation and maintenance much easier. They provide convenient workflows and, depending on the ecosystem, additional verification and dependency management.

However, they introduce a distribution layer between the original project and the user.

Depending on the package and ecosystem, that layer might involve a third-party maintainer, a separate release schedule, or a packaging process that doesn't perfectly match the upstream project's releases.

That's not necessarily a bad thing. It's simply a different distribution model.

But there is another option: let users discover and download release files directly from the source.

Meet Updainium

Updainium is an open-source desktop application inspired by Obtainium, adapted for desktop software distribution.

Instead of manually checking every repository, you can use Updainium to track public projects across supported Git hosting platforms.

The idea is straightforward:

Add a public repository.
Configure the file extension you want to download.
Let Updainium check the project's releases.
Download the matching release asset when you need it.

For example, depending on the assets published by a project, you might look for .dmg files on macOS, .exe installers on Windows, or .AppImage packages on Linux.

You don't need every project to follow the same naming convention or distribute its software through a single centralized store. You choose the artifact type that fits your workflow.

The goal is to make upstream releases easier to discover and download.

Why I Built It with Tauri, Rust, and Svelte

Updainium is built with Tauri, using Rust for its backend and Svelte for its interface.

I wanted a desktop utility that could remain lightweight while still providing a native application experience.

Rust handles backend operations, including application logic and file handling. Svelte powers the user interface, while Tauri connects the two without requiring a traditional heavyweight desktop application stack.

This combination is a practical fit for a tool whose job is to monitor releases and download files rather than run a large collection of background services.

It also keeps the project hackable. The source is available under the GPL-3.0 license, so developers can inspect how it works, modify it, and contribute improvements under the terms of that license.

Direct Downloads Don't Automatically Mean More Security

There is an important distinction between downloading directly from a project's release page and knowing that a file is safe.

A direct download doesn't automatically guarantee authenticity, integrity, or security.

A compromised maintainer account, malicious release, or vulnerable application can still put users at risk. Likewise, downloading a binary from an upstream repository doesn't necessarily mean it has been independently audited.

That's why software distribution should be transparent about what it does and what it doesn't guarantee.

Updainium focuses on discovering releases and downloading matching files. It isn't a substitute for signature verification, checksums, reproducible builds, or a project's security practices.

Whenever a project publishes checksums or signed artifacts, users should take advantage of those verification mechanisms.

The point isn't to blindly trust the source. It's to give users a more direct route to the software they have chosen, while leaving room for independent verification.

What About APIs and Web Scraping?

Not every Git hosting service exposes the same information through a standardized API.

Some sources provide structured release data, while others may require Updainium to gather information from their web pages.

That creates a limitation worth acknowledging: scraping depends on the structure of the website. If a platform changes its HTML or release page layout, tracking can break until compatibility is restored.

This is an engineering trade-off, not something that should be hidden behind marketing language.

The long-term goal is to make release tracking reliable across supported platforms while remaining transparent about compatibility limitations.

A Different Philosophy for Desktop Software

Updainium isn't intended to become another platform that controls how you develop, distribute, or maintain software.

Its development follows a deliberately simple set of principles:

No AI features.
No telemetry.
No subscriptions.
No automatic installation or updates.
No Contributor License Agreements (CLAs).
No proprietary server components.

These aren't claims that every other software project should follow the same rules. They're decisions about the kind of tool I want to build and maintain.

For me, an update manager should help users stay informed and obtain software, not take control of their machines.

That's why Updainium doesn't automatically install updates. Discovering a new release and deciding to install it should remain separate actions.

Automation is useful, but it shouldn't eliminate user consent.

What's Next?

Updainium is still evolving.

The project is open to improvements that make release discovery, downloading, configuration, and everyday desktop use more reliable.

I'm particularly interested in feedback from developers who maintain desktop applications and users who prefer obtaining their software directly from upstream projects.

If you've ever had to maintain a collection of manually downloaded applications, I'd like to hear how you currently handle updates and what you'd improve about that workflow.

Try Updainium

You can explore the source code, inspect the implementation, report bugs, and follow development here:

GitHub repository: https://github.com/livrasand/Updainium
License: GPL-3.0

If you find the project useful, consider starring the repository or contributing a human-reviewed improvement.

Desktop software distribution doesn't need to be complicated to be useful.

Sometimes, the best improvement is simply making it easier to get the software you already trust—from the people who actually build it.

Download Your Desktop Apps Directly from the Source with Updainium 🚀

livrasand — Fri, 02 Oct 2026 20:25:28 +0000

In the mobile ecosystem, tools like Obtainium have revolutionized how power users install and update applications, allowing them to bypass official app stores and download release packages directly from open-source repositories. But what about our desktop operating systems?

Traditional package managers (like Homebrew, apt, or winget) are great, but official repos often lag behind or rely on third-party maintainers. Sometimes, you simply want the official binary, fresh out of the developer's release pipeline.

Today, I’m excited to announce Updainium, a native desktop application designed to track public repositories and download release files straight from the original source.

What is Updainium?

Inspired by the incredible Obtainium, but natively tailored for your desktop operating system. Updainium tracks public repositories on platforms like GitHub, GitLab, Gitea, Forgejo, and compatible services.

The workflow is straightforward:

Add a repository you want to track.
Choose a target file extension (e.g., .AppImage, .exe, .dmg, .tar.gz).
Updainium checks for the latest release.
Download and open the matching file directly on your desktop with a single click.

No more manually checking GitHub "Releases" tabs every time a new update comes out for your favorite tool.

Built with Rust and Svelte (Tauri)

For a desktop utility like this to be useful, it needs to be fast and light on RAM.

That’s why Updainium’s architecture is built on top of Tauri:

Rust Backend: Delivers native performance, secure file handling, and minimal resource consumption.
Svelte Frontend: Provides a clean, responsive, and extremely lightweight user interface.

Technical Limitations & Transparency

We want to be transparent about how data is retrieved under the hood. While some platforms offer clean public APIs, data gathering for certain sources relies on Web scraping.

This means that if one of those platforms significantly changes its web layout, tracking might temporarily break until a patch is released. It’s a necessary trade-off when official APIs are rate-limited or unavailable.

Our Policy on AI Contributions

If you explore the repository, you'll notice an AI_POLICY.md file. We hold a strict stance for Updainium's development: autonomous contributions generated by AI are prohibited.

We do not accept issues, pull requests, or comments generated by autonomous AI agents without meaningful human oversight. We want to ensure that every line of code, discussion, and bug report originates from real human developers who understand the context and implications of their changes.

Try It Out & Contribute (As a Human)

Updainium has its v1.0.0 release live. If you’re the kind of developer or power user who values software delivered directly from the source without middlemen, this tool is built for you.

You can inspect the source code under the AGPL-3.0 license on the repository.

If you like the idea and want to support open-source desktop tooling, consider starring the repo! See you in the commits!

Wiping EXIF Metadata Before Publishing Open Source Projects

livrasand — Fri, 11 Sep 2026 16:21:58 +0000

When developers focus on Git privacy, they usually think about stripping author names and emails from commit histories. However, there is a massive privacy leak hiding in plain sight: binary files.

If your repository or Pull Request includes screenshots, diagrams, architectural PDFs, or sample images, those files may contain embedded EXIF and document metadata. This hidden data can expose your exact GPS coordinates, camera/device models, username paths, creation timestamps, and software versions—regardless of how clean your Git commit log is.

In this practical tutorial, we will cover how to audit and strip binary metadata using exiftool, and how to pair it with gitGost for end-to-end contribution anonymity.

1. The Invisible Risk: What Binary Files Leak

Standard Git commit anonymization strips user.name, user.email, and commit timestamps. But Git treats binary files as opaque blobs, leaving internal file metadata untouched.

Common files that leak personal metadata include:

Images (.png, .jpg, .webp): EXIF tags containing GPS location, device serial numbers, software build info, and original creation dates.
PDF Documents: Embedded author names, local file directory paths (e.g., /Users/yourname/Documents/...), and editing history.
Office Documents (.docx, .xlsx): Company names, author profiles, and revision trackings.

If you upload a screenshot of a bug fix, an attacker or automated scraper can extract your location or local system username directly from the file.

2. Auditing and Cleaning Metadata with `exiftool`

The industry standard for inspecting and stripping file metadata is exiftool.

Step 1: Install `exiftool`

macOS: brew install exiftool
Linux (Ubuntu/Debian): sudo apt install libimage-exiftool-perl
Windows: Download the executable from the official site or install via choco install exiftool.

Step 2: Inspect Hidden Metadata

Before modifying a file, check what metadata it currently exposes:

exiftool screenshot.png

Look closely at fields like Camera Model, GPS Position, Create Date, and Software.

Step 3: Strip All Metadata

To wipe all internal tags cleanly, run:

exiftool -all= -overwrite_original screenshot.png

Note: The -overwrite_original flag prevents exiftool from creating backup files (_original), ensuring no uncleaned copies remain in your working directory.

To process an entire folder of assets before committing:

exiftool -all= -overwrite_original -ext png -ext jpg -ext pdf ./docs/images/

3. End-to-End Privacy: Pairing `exiftool` with gitGost

Wiping file metadata is only half the battle. If you attach cleaned images to a commit and push from your personal account, your Git author details and IP address will still be exposed.

To achieve strong anonymity across both files and Git logs, use gitGost.

What is gitGost?

gitGost is an open-source, AGPL-3.0 proxy written in Go that allows you to push code and create Pull Requests without exposing accounts, tokens, or commit metadata. PRs are automatically created on your behalf by the neutral @gitgost-anonymous bot.

Complete Anonymous Contribution Workflow

Clean your assets:

exiftool -all= -overwrite_original diagram.png

Commit your changes locally:
```
git add diagram.png
git commit -m "docs: add updated architecture diagram"
```
(Pro tip: Write a detailed commit message, as gitGost uses your commit message as the PR description.)
Add the gitGost remote:
```
git remote add gost https://gitgost.fly.dev/owner/repository
```
(gitGost supports public repositories on both GitHub and GitLab.)
Push anonymously:
```
git push gost main
```
Optional (IP Masking via Tor):
While gitGost removes author name, email, and timestamps, the proxy server can still see your IP address. To mask your IP, wrap your push with torsocks:
```
torsocks git push gost main
```

4. Threat Model & Boundaries

Understanding the boundaries of your toolchain is essential for privacy:

What gitGost + exiftool protects against: Public exposure of author name/email, binary EXIF/GPS leaks, account-to-PR association, and passive metadata scraping by recruiters or bots.
Operational limits: gitGost enforces repository size caps 500 MB, commit limits 10 MB, and rate limits 5 PRs/IP/hour to prevent abuse.
What it does NOT protect against: Code style analysis (stylometry) or targeted surveillance by nation-state actors.

Conclusion: Clean Code, Clean Files

Privacy in open source requires a layered approach. By stripping binary EXIF metadata with exiftool and pushing through gitGost, you ensure that neither your assets nor your Git logs become permanent liabilities.

Frequently Asked Questions (FAQ)

Can I contribute to GitHub anonymously?
Yes. Tools such as gitGost allow developers to create anonymous Pull Requests without exposing their GitHub account, name, or email address.

Does GitHub strip EXIF data from uploaded images?
No. GitHub preserves the raw binary content of committed files, meaning any embedded EXIF or GPS data remains publicly readable in the repository history.

Is anonymous open-source contribution legitimate?
Yes. Many developers use anonymity to avoid employer conflicts, political risks, harassment, or unwanted profiling by recruiters.

If you care about developer privacy, consider starring the gitGost repository on GitHub!

Your Git Commit History Is More Public Than You Think 🕵️‍♂️

livrasand — Wed, 01 Jul 2026 15:52:13 +0000

In the open source world, we often say that "your code is your resume." However, what many developers forget is that every time they run a git push, they're handing over much more than just lines of code. They're delivering a permanent digital trail that can be tracked, analyzed, and used against them years later.

This article is an educational guide about privacy in Git and how the metadata you generate every second can compromise your security and your professional future.

The command that reveals your "naked identity"

If you want to see exactly what you're sharing with the world, open your terminal in any repository and run the following command:

git log --format=fuller

Unlike the standard log, the fuller format breaks down the complete anatomy of your contributions. This is where most developers are shocked to see what they're actually leaking:

1. Name and Email (Direct Exposure)

Git stores your user.name and user.email locally in every commit. This data:

Is harvested by spam bots for marketing databases.
Allows recruiters to map all your historical activity, even on projects you no longer represent.
Exposes you to doxxing attacks if you contribute to controversial projects.

2. Dates and Timestamps (Time Analysis)

Git not only saves the day, but also the exact second and time zone of the authorship and commit. This allows you to create an activity pattern:

What time do you usually code?
Are you working on personal projects during office hours?
What geographical area are you actually in?

3. File Patterns and Metadata

In addition to text, if you upload binaries (PDFs or images), these usually contain EXIF metadata (GPS coordinates, camera model, etc.) that Git doesn't clean up by default.

The Problem with "Permanent Logs"

GitHub is, by design, an accountability platform, not a privacy one. Once a commit enters the public history, deleting it is extremely difficult and often pointless if the repository has already been cloned or indexed by third-party services.

This creates a HR liability risk: a contribution made today could be judged in a completely different context five years from now.

The Solution: Enter GitGost 👻

For those times when you want your code to speak for itself, without any identifying tags, there's GitGost.

GitGost is an open-source proxy designed to offer strong anonymity for your contributions. It requires no accounts, tokens, or complex browser configurations.

How Does It Work?

Instead of uploading code directly to GitHub with your identity, you submit it through GitGost. The server:

Clean all your metadata (name, email, timestamps).
Replace the authorship with the neutral bot @gitgost-anonymous.
Automatically create a Pull Request in the target repository.

Quick Workflow:

1. Add the GitGost remote

git remote add gost https://gitgost.fly.dev/owner/repo

2. Push your branch (without logs or tokens)

git push gost main

Is this just for "hackers"?

Absolutely not. Anonymity in open source has legitimate and ethical use cases:

Employees who want to fix bugs in competing tools without violating exclusivity clauses.
Activists and journalists in censored regions who need to contribute to privacy tools without personal risk.
Developers who simply want to fix an annoying typo without it defining their public profile forever.

Conclusion: Be a ghost, fix the internet

Privacy isn't about hiding something bad; it's about having the power to choose what you share. If you believe developers deserve the right to contribute without being permanently profiled, it's time to start auditing your metadata.

Frequently Asked Questions (FAQ)

Can I contribute to GitHub anonymously?
Yes. Tools like gitGost allow you to create anonymous pull requests without exposing your GitHub account, name, or email address.

Does GitHub expose my email address?
Potentially, yes. Git commits contain author metadata (email) unless they are specifically anonymized before being published.

Is anonymous open source contribution legitimate?
Yes. Many developers use anonymity to avoid harassment, workplace conflicts, political risks, or unwanted profiling by recruiters.

If you're passionate about privacy, check out the gitGost repository and leave a star to support the right to anonymity in development.

How to Contribute to GitHub Anonymously in 2026

livrasand — Mon, 29 Jun 2026 17:23:00 +0000

In the world of open source, your code is your resume. But sometimes, you want the code to speak for itself without attaching your legal name, your company’s email, or a permanent timestamp to it. Whether it's to avoid HR liabilities, contribute to controversial projects, or simply stay private, contributing anonymously to GitHub is a skill every modern developer should have.

In this guide, we’ll explore why your current Git workflow is "leaking" data and how tools like gitGost are changing the game for privacy in 2026.

Why GitHub Contributions are Permanent

GitHub is designed for accountability, not anonymity. By default, every time you push code, you are creating a permanent public record. This "contribution graph" can become a liability over time:

HR and Recruiters: Your activity can be used to judge your "productivity" or interests during hiring processes.
Email Harvesting: Spammers and scrapers crawl commit histories to build databases of active developer emails.
Political Risks: In some jurisdictions, contributing to specific tools or repositories can lead to real-world consequences.

What Information Your Git Commits Actually Expose

If you run git log --format=fuller on any of your repositories, you’ll see the "naked" truth. A standard Git commit exposes:

Full Name and Email: Your local user.name and user.email settings.
Timestamps: When exactly you authored the code (often revealing your timezone and work habits).
Metadata: Hidden info in binary files (like images or PDFs) through EXIF data.
Identity Correlation: Passive metadata that links your personal GitHub account to every Pull Request you open.

Anonymous Accounts vs. True Anonymity

Many developers think creating a "burner" GitHub account is enough. It's not.
Secondary accounts still carry metadata in the commits. Furthermore, GitHub’s own platform telemetry can often link your accounts via IP addresses or browser fingerprints. True anonymity requires stripping all identifying metadata before the code even reaches a remote server.

The Solution: Using gitGost

gitGost is an open-source proxy designed for "strong anonymity" in Git contributions. It allows you to contribute to any public repository without an account, a token, or metadata.

How to use gitGost (The One-Command Setup)

The beauty of gitGost is that it requires no browser extensions or complex setups. Just add a remote and push:

Add the Gost remote:

git remote add gost https://gitgost.fly.dev/owner/repo

Push your changes:
```
git push gost your-branch
```

What happens next?
gitGost's neutral bot, @gitgost-anonymous, creates a Pull Request on your behalf. Your name, email, and timestamps are stripped and replaced with generic metadata. Your commit message automatically becomes the PR description, so make sure to provide context there.

Enhanced Privacy: Using Tor and Stripping Metadata

For developers who need a higher level of protection (protecting against IP identification), combining gitGost with Tor is the gold standard.

1. Hiding your IP with `torsocks`

gitGost strips your commit data, but the server still sees your IP. To mask it, use torsocks:

# Install on Linux
sudo apt install torsocks
# Push through Tor
torsocks git push gost main

Note: Tor is slower due to its three-layer encryption, so expect the push to take a few minutes.

2. Stripping Binary Metadata with `exiftool`

If your contribution includes images or PDFs, they might contain GPS coordinates or device info. Use exiftool before committing:

exiftool -all= -overwrite_original image.png

The gitGost Threat Model

Anonymity is never absolute. It’s important to understand what gitGost protects you against and what it doesn't:

It protects against: Public exposure of name/email, direct association with your personal account, and passive metadata collection by recruiters or scrapers.
It does NOT protect against: Stylometry (code style analysis), advanced temporal correlation, or nation-states with infrastructure-level access.

Explicit Assumption: You must use a trustworthy network (VPN/Tor) and avoid mixing anonymous and personal contributions in the same repository to stay safe.

Conclusion: Be a Ghost, Fix the Internet

Privacy is a right, even for developers. gitGost was built for responsible, good-faith contributions where identity is unnecessary. It's about giving you the choice to "disappear" after you've made the internet a little better.

Frequently Asked Questions (FAQ)

Can I contribute to GitHub anonymously?
Yes. Tools like gitGost allow you to create anonymous pull requests without exposing your account or metadata.

Does GitHub expose my email address?
Yes, unless you specifically use a proxy or anonymize your Git metadata.

Is anonymous contribution legitimate?
Absolutely. It is used by activists, journalists, and developers wanting to avoid profiling or employer conflicts.

If you believe developers deserve the right to privacy, consider starring the gitGost repository.

DEV Community: livrasand

What GitHub Doesn't Tell You About Your Privacy 🔍

1. Your commit history is a timeline of your activity

2. Your email address might be public

3. Deleted information isn't necessarily gone

4. Your GitHub profile tells a story

5. Issues and pull requests can expose internal details

6. Your local machine can leak information too

What about image metadata?

7. Public repositories can reveal your development infrastructure

8. Can you contribute anonymously on GitHub?

9. A practical privacy checklist for developers

Final thoughts

I Built a Gateway to Browse Git Repositories Without an Account

The problem with identity by default

What is gitGost?

Browsing without an account

Contributing anonymously with Git

What about commit metadata?

An important limitation: your IP address

Privacy and accountability can coexist

Why make it open source?

Who is gitGost for?

Try it, inspect it, or contribute

Your Desktop Apps Deserve Updates Straight from the Source

The Desktop Update Problem

Package Managers Aren't the Enemy

Meet Updainium

Why I Built It with Tauri, Rust, and Svelte

Direct Downloads Don't Automatically Mean More Security

What About APIs and Web Scraping?

A Different Philosophy for Desktop Software

What's Next?

Try Updainium

Download Your Desktop Apps Directly from the Source with Updainium 🚀

What is Updainium?

Built with Rust and Svelte (Tauri)

Technical Limitations & Transparency

Our Policy on AI Contributions

Try It Out & Contribute (As a Human)

Wiping EXIF Metadata Before Publishing Open Source Projects

1. The Invisible Risk: What Binary Files Leak

2. Auditing and Cleaning Metadata with exiftool

Step 1: Install exiftool

Step 2: Inspect Hidden Metadata

Step 3: Strip All Metadata

3. End-to-End Privacy: Pairing exiftool with gitGost

What is gitGost?

Complete Anonymous Contribution Workflow

4. Threat Model & Boundaries

Conclusion: Clean Code, Clean Files

Frequently Asked Questions (FAQ)

Your Git Commit History Is More Public Than You Think 🕵️‍♂️

The command that reveals your "naked identity"

1. Name and Email (Direct Exposure)

2. Dates and Timestamps (Time Analysis)

3. File Patterns and Metadata

The Problem with "Permanent Logs"

The Solution: Enter GitGost 👻

How Does It Work?

Quick Workflow:

1. Add the GitGost remote

2. Push your branch (without logs or tokens)

Is this just for "hackers"?

Conclusion: Be a ghost, fix the internet

Frequently Asked Questions (FAQ)

How to Contribute to GitHub Anonymously in 2026

Why GitHub Contributions are Permanent

What Information Your Git Commits Actually Expose

Anonymous Accounts vs. True Anonymity

The Solution: Using gitGost

How to use gitGost (The One-Command Setup)

Enhanced Privacy: Using Tor and Stripping Metadata

1. Hiding your IP with torsocks

2. Stripping Binary Metadata with exiftool

The gitGost Threat Model

Conclusion: Be a Ghost, Fix the Internet

Frequently Asked Questions (FAQ)

2. Auditing and Cleaning Metadata with `exiftool`

Step 1: Install `exiftool`

3. End-to-End Privacy: Pairing `exiftool` with gitGost

1. Hiding your IP with `torsocks`

2. Stripping Binary Metadata with `exiftool`