You clearly don’t understand how this works, do you?

Let’s start from the beginning: Your suggested app, “classyshark3xodus”, notes that the database it uses is the concatenation of the existing exodus-privacy trackers, as well as an addendum list of 31 “additions”. Most importantly, this list comes from the repository linked here.

Let’s ignore, for a moment, that this clearly implies that the creator of this app lied about the database it uses (because it’s very clearly not some official “new” Exodus database, but a hodgepodge mashup made by some complete stranger on the Internet…) The repository for the addendum list states that the Sentry listing comes from the Exodus Tracker Investigation Program (ETIP). Thus, we expect that there should be a page on the ETIP for Sentry, and indeed there is one here.

We can see that the description for this tracker is… hold your breath… to report unhandled exceptions to an online service. It’s almost as if… that was the exact, entire, unmitigated stated purpose of the fucking software in the first place! Also note that the stated category is… again, hold your breath… crash reporting. Again, this is exactly the stated purpose of the SDK, which was advertised on their own site.

This means you already lied multiple times about the intended purpose of Sentry. Your own source states that Sentry is not an “analytics company”, but a “crash reporting” service. Again, this is what we have already clearly established by a very cursory, trivial look at the software itself. Oh, also, it’s also stated in the ETIP that Sentry is not even listed in Exodus as a tracker. Gee, I sure wonder why…?

I also had the displeasure of going through with downloading this app from F-droid and testing it on Fennec as you stated. As expected for the simplistic process of “does the fully qualified name of this class begin with this specific filter?” Sentry classes show up.

I know what I’m doing, so let’s dig into some of the classes. The vast majority of them are actually dummy classes that do not contain any fields or functions that mutate state. For example, io.sentry.UserFeedback:

package io.sentry;
import java.lang.String;

public final class UserFeedBack extends Object
{
/*
 * Field Definitions.
 */
/*
 * Declared Constructors
 */
    public final String toString() { ... }
}

The reason for this is that F-Droid runs ProGuard on compiled artifacts from source, which optimizes away unused Java bytecode. This means we can be sure that the APK we received only consists of the instructions actually used by the APK. An empty class file also means that it is a stateless class, and for the sake of OOP is effectively a no-op that can’t perform anything.

So with that being said, let’s dig straight into the io.sentry.protocol.User class. We should expect this to contain the most sensitive user information sent to this “analytics” company, such as email addresses, geo locations, and… uhh wait…

package io.sentry.protocol;
import java.lang.Object;

public final class User extends Object
{
/*
 * Field Definitions.
 */
/*
 * Declared Constructors
 */
  public User() { ... }
  public final boolean equal(Object) { ... }
  public final int hashCode() { ... }
}

It’s a dummy class! That means it can’t store anything about the user because it doesn’t do any of that in the first place, thus being optimized away by ProGuard. Oops.

So, how about io.sentry.protocol.Session?

package io.sentry;
import ...

public final class Session extends Object
{
/*
 * Field Definitions.
 */
    public String abnormalMechanism;
    public final String distinctId;
    public Double duration;
    public final String environment;
    public final AtomicInteger errorCount;
    public Boolean init;
    public final String ipAddress;
    public final String release;
    public Long sequence;
    public final UUID sessionId;
    public final Object sessionLock;
    public final Date started;
    public Session$State status;
    public Date timestamp;
    public String userAgent;
/*
 * Declared Constructors.
 */
    public Session(Session$State, Date, Date, int, String, UUID, Boolean, Long, Double, String, String, String, String, String) { ... }
    public final Session clone() { ... }
    public final volatile Object clone() throws CloneNotSupportedException { ... }
}

Finally, a class with actual state! We can see from here that a Sentry session can contain the following information:

• The user’s IP address. Pro tip – any time you connect to the Internet, your outmost IP address is always shared with any destination servers you connect to. This is in the design of the protocol.
• The ‘userAgent’. According to this line, the user agent is sent as the User-Agent header of the HTTP request to Sentry’s servers. This value is composed of the app’s chosen programming language and platform of choice of the user, along with the version of the Sentry SDK.
• The user environment. From these lines this is simply whether the user is operating in a production or development environment; e.g. the typical Fennec user will be running in a “production environment.” Standard stuff.
• Information related to the internal Sentry session, such as error counts, session length, error status, time the session started, etc. This information is intrinsically anonymous, since it’s tied to the operation of the application itself and not the user.

So what potentially personal information does Sentry “leak” in a session?

• The user IP address
• The platform of the user (for Fennec, it is always Android)
• … that’s it.

In other words… this is a typical crash log… containing the unhandled exception which caused the crash… that is then sent over to a server over the Internet via a specific user’s Internet connection (leaking an IP by necessity of the protocol). In other words… this is a crash reporting service. 🤦

As war said, you don’t know what Sentry does. Actually, you don’t understand how any of this works. This is a privacy community first and foremost, but I also expect that FOSS “enthusiasts” such as yourself actually understand how to work with FOSS.