What GitHub exposes about you: Name, Location, and more

GitHub Digital Footprint

Your activity on the internet can expose a lot of Personally Identifiable Information (PII) about you. This information could potentially be used by malicious actors to target you or the company you work for. Furthermore, one might want to limit the amount of information they make available about themselves online for privacy reasons.

GitHub is the world's most popular Git provider and the home of countless open source projects. However, many people don't understand what information GitHub can reveal about them, either directly or indirectly.

For the examples in this post, I will be using my own GitHub profile (mobeigi) as well as anonymised data that belongs to some of my colleagues.

Leaking PII

When you sign up to GitHub, you can choose to provide information about yourself that is displayed on your profile. This may include your full name, company, location, email, website and socials. Any information you disclose here is obviously intended to be public. However, many users prefer not to reveal their real name and email address for privacy reasons or to prevent bots from scraping their email address and sending them spam emails.

While users can choose what to show on their profile, it's important to note that any publicly visible commit you make on GitHub is also available in its raw patch form.

Consider this commit that I recently created:
https://github.com/mobeigi/mobeigi.com/commit/d6ba63bdea639a3661c7bbe6d50bfb6636079337

By appending .patch to the end of the GitHub commit URL, we are able to see the raw patch:
https://github.com/mobeigi/mobeigi.com/commit/d6ba63bdea639a3661c7bbe6d50bfb6636079337.patch

At the top of the raw patch, we see various headers that are part of the Git patch header format:

From d30d7988fc91eff78a4ca6416a3b73d3aa8bc686 Mon Sep 17 00:00:00 2001
From: Mo Beigi <me@mobeigi.com>
Date: Fri, 9 May 2025 16:45:39 +1000
Subject: [PATCH 1/4] Update homepage update time on sitemap

These are the same headers you will see when performing a git log command.

So, what information do these headers actually reveal about the author of the commit?

Name and email address

The author name and email address are immediately visible in the From header. This is the same information that one would have configured in their local git installation via:

git config user.name "John Doe"

git config user.email "email@example.com"

If you would prefer to avoid leaking your name and email via your commits, you can:

• Set your Git user name to something anonymised: git config user.name "Ghost"
• Use GitHub's private email address feature. GitHub provides users with an anonymised email like 12345678+yourusername@users.noreply.github.com. You can find your personalised email under: GitHub → Settings → Emails → "Keep my email address private". Then update your Git config user email: git config user.email "12345678+yourusername@users.noreply.github.com".

To apply the changes globally, add the --global flag to each git config command.

Location

The Date header also reveals when this commit was made. This is very significant.

To begin with, the Date includes my local time zone offset. Assuming I made the commit on a machine in my local time zone with a synchronised clock, this strongly suggests I was in one of the following UTC+10:00 regions at the time:

• Australia (New South Wales, Victoria, Tasmania, Australian Capital Territory) [during non-DST months].
• Papua New Guinea.
• Northern Mariana Islands.
• Guam.
• Micronesia (Chuuk, Yap).
• Marshall Islands (western regions).
• Russia (Primorsky Krai, Khabarovsk Krai).

This can directly leak a user's primary residence.

Now, consider these commit patches from my colleague Alex, who frequently travels abroad to support clients on-premises:

From a1f2e3d4c5b6a798b0a1c2d3e4f5g6h7i8j9k0l1 Mon Sep 17 00:00:00 2001
From: Alex Redacted <alex@example.com>
Date: Mon, 17 Mar 2025 09:15:42 +1000
Subject: [PATCH] redacted subject

From b2c3d4e5f6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1 Mon Sep 17 00:00:00 2001
From: Alex Redacted <alex@example.com>
Date: Wed, 19 Mar 2025 14:48:33 -0700
Subject: [PATCH 1/5] redacted subject

From e5f6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1p2q3r4 Mon Sep 17 00:00:00 2001
From: Alex Redacted <alex@example.com>
Date: Mon, 24 Mar 2025 08:37:00 -0500
Subject: [PATCH] redacted subject

From f6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1p2q3r4s5 Mon Sep 17 00:00:00 2001
From: Alex Redacted <alex@example.com>
Date: Tue, 25 Mar 2025 11:04:17 +1000
Subject: [PATCH 1/3] redacted subject

Since their work laptop automatically synchronises its clock based on location — and Git uses the local system time when creating commits — we can reconstruct their travel history purely from commit metadata.

In this case, the user began in Sydney, Australia, then flew to a client based in California, USA, before travelling onward to Texas, USA, and finally returned home to Sydney. Each location shift is reflected in the time zone offsets embedded in their commits. By comparing the timestamps, we can also make educated guesses about how long the user spent at each destination.

There are serious risks associated with leaking an individual's current location, including threats to physical security (such as being targeted for burglary), corporate reconnaissance, and targeted social engineering attacks.

If protecting your general location is important to you, you can set the author date and committer date explicitly on each commit:

GIT_COMMITTER_DATE="Fri, 10 May 2025 06:00:00 +0000" git commit --date="Fri, 10 May 2025 06:00:00 +0000"

Alternatively, you can configure your shell to temporarily use UTC by setting the TZ environment variable, as Git will use TZ if it’s set:

export TZ=UTC

Git Commit Date Example - Local Time vs Fixed UTC:

Please keep in mind that prior commits will still include the original Git headers. As a result, a common tactic when confronted with GitHub private emails or UTC time zone dates is to check older commits for PII leaks. This can only be mitigated by completely rewriting all prior commits across all repositories, which is often not feasible.

Working hours and holidays

It’s surprisingly easy to extract a developer’s working hours and even their sleep schedule just by looking at their commit history. If a developer is primarily using GitHub as part of their day job, their commit activity will highlight their core working hours and sleep patterns.

Many users also have the Git contribution graph enabled, which shows their Git commit activity over time:

This contribution graph can be configured to also include private commits (which may belong to a private repository or organisation), although it's important to note that this option is disabled by default.

The contribution graph can indirectly reveal when a developer is taking time off from work. A developer who commits many times daily but misses a day is likely sick or taking a personal day. A sudden lack of commits for an extended period likely indicates the developer has gone on holiday.

For example, consider the contribution graph of my colleague Will over the last year:

It clearly shows a gap in July of 2024, consistent with the typical duration of an international holiday.

Knowing when a developer is inactive opens the door to sophisticated social engineering and phishing attacks. For example, an attacker could craft a fake email impersonating the absent developer, claiming they urgently need access to a system or repository while away. Since the real developer is known to be offline, colleagues may be less likely to verify the request, increasing the chances of a successful phishing attempt.

So am I safe?

In most cases, yes.

For the majority of developers, having your name, email address, or location publicly visible is generally low risk. Unless you're working on highly sensitive projects or hold a role that makes you a prime target for social engineering, you likely don’t need to take active steps to mitigate these leaks. But it’s still worth knowing what Git metadata reveals and how easily it can be used to build a profile of you, intentionally or not.