contains BugSnag, needs TRACKING antifeature

FairEmail ( contains BugSnag analytics but the user is not informed of this until it’s too late.

The analytics are opt-in so it’s not as bad as what I discovered a few days ago in Frost, but still, users need to be informed of this. There’s also no mention of this in the app description, as a matter of fact, it says “No analytics and no tracking” which is a blatant lie because the BugSnag signature is present even in the F-Droid version of the applicaiton.

1 Like

I don’t think we should mark opt-in analytics as tracking.

says “No analytics and no tracking”

This should rather mention that there’s opt-in analytics then!

I understand, the description definitely needs to be updated to reflect the presence of opt-in analytics. The developer seems to have used them properly, no connections to bugsnag are opened when analytics are disabled.

I thought the tracking antifeature was needed for all projects that use analytics, opt-in or not, because I noticed that Fennec has it and it has opt-in analytics.

The antifeature description says:

tracks and/or reports your activity to somewhere, even when it can be turned off

Which would apply to opt-out.

I don’t know about fennec, why it does have the antifeature.

It already has this as an antifeature.

That’s great, they must have added it recently because it wasn’t there when I opened this topic.

Which antifeature exactly? Tracking? IMHO not warranted… It’s OPTIN, say no/cancel at that dialogue.

Well I guess the description of the antifeature is kind of ambiguous:

tracks and/or reports your activity to somewhere, even when it can be turned off

This certainly applies to opt-out, but what about opt-in? Izzy probably thought that it does but whoever merged FairEmail did not. I’d like to hear @Izzy’s opinion. (Granted that properly implemented opt-in analytics like in this case are not a big deal like opt-out or forced analytics)

Did you ask M66B to update the description? Clarifying the error logging opt-in is a nice idea. :+1:

I do not think that the app needs to have an antifeature for tracking if it is opt-in. :thinking:

I sent him an email when I opened this topic (he has no issue tracker on github).

1 Like

If it’s opt-in (and FOSS of course), and it’s clear to the user what toggling it on means (so no “tricking-in” or “you must turn this on or feature X will stay disabled” – not that I would expect such from Marcel, so take this as “speaking generally”) it should be fine. That would be a clear declaration of consent.

This too

Did this now:

Bugsnag is disabled by default and you’ll be asked if you want to enable it on first run. There is an info button which leads to this FAQ with detailed information about what Bugsnag does.

You could see error reporting as a form of Analytics, but in my interpretation it should be used for marketing to be called Analytics, which it isn’t. Tracking is in my idea even a step further and requires data to be sent not anonymously.

Bugsnag is disabled by default and explicitly opt-in, so there is no analytics and no tracking by default.

I like to be 100 % transparent, so I have changed the description to this:

Is this okay for everybody?


@M66B If you want to “appear” in F-Droid client “kiosk/new” opening screen, you need a /metadata in your repo root/ ; check simplified ; there are other advanced metadata: check Auto-generate an app website based on Fastlane/F-Droid metadata

@oF2pks can you please check if this is correct?



Open source, privacy friendly email app for Android - M66B/FairEmail

In particular, I am not sure if it is possible to use markdown in " *.txt files in the old, custom, F-Droid text-based format" (

Am I right that a pull request needs to be done to make this work?

Yes, to remove the current Description from the metadata, so it gets picked up, on the next app update, from your repo.

1 Like

Any chance to add screenshots as well?

Can you please take care of this?

Let’s first get this to work. I will add screenshots later.