com.google.android.gms:play-services-fido ends up in the build and pulls in other parts of the Google Play Services client library

[mysterious-github]

Adjust and GoogleAdMob trackers

How to find trackers:

1. Open trackers analyser, such as Aurora Warden.
2. Scan all apps.
3. You'll see the result:

[CharmCityCrab]

In the past, it's been reported that Iceraven generates some false positives on tests like that because the tests are scanning for certain words or indicators in the code but aren't actually checking to see if any data is really being collected and sent anywhere.

Basically, Iceraven has to retain some of the words and hooks associated with proprietary telemetry to make the browser work without doing a code overhaul that is much more massive than the scope of the fork. But they try to tear out the parts that actually send out your data places.

My guess is almost any Fenix fork would show positives on those tests, even though, like Iceraven, many try to eliminate proprietary telemetry or telemetry in general. It's just easier to build when something that's supposed to point to a telemetry component has a stub to point at and make it think it's there (Even though it isn't).

With that said, it's always possible that some new version of Fenix will change the way it does telemetry and that'll get filtered down to Iceraven accidentally. So, what I would suggest if this explanation doesn't satisfy you and you think something is up, is to use an Android program similar to Wireshark to monitor outgoing connections. If you can find Iceraven actually connecting to telemetry servers apart from those on pages it's loading, that would be an issue that I think the developer of the browser would want to know about so he can fix it. He hates telemetry as best I can tell from his public comments.

[SkewedZeppelin]

It is not a false positive like Fennec F-Droid or Mull.
If you decompile Iceraven you will find the proprietary Google Play Services library in full.

[CharmCityCrab]

@interfect Any thoughts on this? There was another guy who posted and removed firewall records that seemed to show connection attempts.

[interfect]

What we're supposed to be doing is shipping this code to replace some Google code that e.g. provides an advertising ID to Mozilla's own telemetry code. The Mozilla telemetry code is still built and shipped, but turned off, because it didn't seem feasible to chase it down and unhook it from the rest of the project.

I think I'm successfully not including com.google.android.gms:play-services-ads-identifier; there's a dependency variable defined with a version of it, in buildSrc/src/main/java/Dependencies.kt, just like for com.google.android.gms:oss-licenses-plugin, but it doesn't go anywhere. Moreover, nothing is conflicting with my fake version of the advertising ID code.

I checked ./gradlew app:dependencies, and it does look like we get some client libraries under com.google.android.gms:

forkReleaseRuntimeClasspath - Runtime classpath of compilation 'forkRelease' (target  (androidJvm)).
+--- androidx.databinding:viewbinding:7.0.0
|    \--- androidx.annotation:annotation:1.0.0 -> 1.2.0
+--- org.jetbrains.kotlin:kotlin-parcelize-runtime:1.5.31
|    +--- org.jetbrains.kotlin:kotlin-stdlib:1.5.31
|    |    +--- org.jetbrains:annotations:13.0
|    |    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.5.31
|    \--- org.jetbrains.kotlin:kotlin-android-extensions-runtime:1.5.31
|         \--- org.jetbrains.kotlin:kotlin-stdlib:1.5.31 (*)
+--- org.mozilla.components:browser-engine-gecko:96.0.15
|    +--- org.mozilla.geckoview:geckoview-omni:96.0.20220126154723
|    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.20 -> 1.5.31
|    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.5.31 (*)
|    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.5.31
|    |    |         \--- org.jetbrains.kotlin:kotlin-stdlib:1.5.31 (*)
|    |    +--- androidx.annotation:annotation:1.1.0 -> 1.2.0
|    |    +--- androidx.legacy:legacy-support-v4:1.0.0
...
|    |    +--- com.google.android.gms:play-services-fido:18.1.0
|    |    |    +--- com.google.android.gms:play-services-base:17.0.0
|    |    |    |    +--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
|    |    |    |    +--- androidx.core:core:1.0.0 -> 1.5.0 (*)
|    |    |    |    +--- androidx.fragment:fragment:1.0.0 -> 1.3.4 (*)
|    |    |    |    +--- com.google.android.gms:play-services-basement:17.0.0
|    |    |    |    |    +--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
|    |    |    |    |    +--- androidx.core:core:1.0.0 -> 1.5.0 (*)
|    |    |    |    |    \--- androidx.fragment:fragment:1.0.0 -> 1.3.4 (*)
|    |    |    |    \--- com.google.android.gms:play-services-tasks:17.0.0
|    |    |    |         \--- com.google.android.gms:play-services-basement:17.0.0 (*)
|    |    |    +--- com.google.android.gms:play-services-basement:17.0.0 (*)
|    |    |    \--- com.google.android.gms:play-services-tasks:17.0.0 (*)
|    |    +--- org.yaml:snakeyaml:1.24

So it looks like the browser engine (org.mozilla.components:browser-engine-gecko from android-components) pulls in org.mozilla.geckoview:geckoview-omni (which I think builds from the main Mozilla Gecko source tree in Mercurial), which pulls in com.google.android.gms:play-services-fido (for letting you use a hardware 2-factor authentication token), which then pulls in some more Google Play Services stuff that it uses.

So we end up shipping some of Google's closed-source client libraries, but they aren't supposed to be collecting analytics to send to me or Mozilla. Who knows if they also have their own internal tracking code to make everything that uses a Google Play Services library tell Google about it.

I think I may have looked at this and deemed it good enough; this isn't itself an advertising or telemetry library, and I don't think there's a license issue here (otherwise Mozilla couldn't ship this either). Removing it might require forking android-components, which I've deemed to be out of scope for this project, and also would remove the 2-factor authentication token feature. (If it even works right now; Google might ban Iceraven from accessing it.) But I see why someone might not want even ostensibly non-tracking-related proprietary Google code in their builds.

I think that Geckoview comes in -omni and -lite versions, which may or may not correspond to including or not including proprietary dependencies. It looks like in release 94 Mozilla swapped android-components over to use the -omni version, which might or might not corespond to when I had to drop my stub com.google.android.gms.common.GooglePlayServicesNotAvailableException due to conflicts, which I guess is when we started shipping the FIDO library.

This is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1549418 and mozilla-mobile/android-components#3036 and mozilla-mobile#1340 where the FIDO dependency was added to add the feature to Mozilla Firefox.

I'll ask the android-components devs if they have a build variant or something that doesn't include this transitive dependency.

[CharmCityCrab]

Is using Fennec's version of android-components as the upstream to Iceraven's android-components rather than the Mozilla Firefox version of android-components an option?

The ongoing Fenix-based Fennec project has the narrower goal of eliminating only proprietary telemetry instead of all telemetry from their builds, but if editing code within android-components is out of scope for Iceraven, and if it is determined that what people are complaining about meets whatever Fennec's definition of proprietary telemetry is, then switching upstream providers for android-components might be a pragmatic way to get Iceraven back a little closer to what it describes as the ideal in the readme.md without expanding scope (Pragmatic because in theory they might leave non-proprietary code in that module if there is any, but the alternative may be to leave all telemetry in that module, if there is any, in, which would be worse.). It'd just be subbing out one source for another.

Iceraven could continue to use Mozilla Firefox as direct upstream for the other module that's out of scope, and continue with it's own special sauce for the one that's in scope, if desired, assuming they all work nicely with each other.

Just throwing that out there as an idea. There is at least one Fenix-based Android browser that uses Fennec as upstream for everything.

[CharmCityCrab]

@relan Does your project's version of android-components consider this proprietary telemetry and remove it, or do you consider it open-source telemetry and leave it in?

[relan]

Does your project's version of android-components consider this proprietary telemetry and remove it, or do you consider it open-source telemetry and leave it in?

All proprietary code is removed from Fennec F-Droid. If you find any, let me know, I'll fix that.

As to com.google.android.gms:play-services-fido, this is not exactly telemetry, but as it's non-free, it's also removed from GeckoView (patch, sed).

Note that we at F-Droid build Android Components, App Services, Glean and GeckoView libraries from source. There's no Maven repo that could be used as a drop-in replacement of the Mozilla repo.

[CharmCityCrab]

As to com.google.android.gms:play-services-fido, this is not exactly telemetry, but as it's non-free, it's also removed from GeckoView (patch, sed).

Note that we at F-Droid build Android Components, App Services, Glean and GeckoView libraries from source. There's no Maven repo that could be used as a drop-in replacement of the Mozilla repo.

Thanks! It's Interfect's ballgame in terms of what he wants to do with Iceraven, but this should give him enough information to base a decision on (and potentially a ready made patch if he wants to get into modifying that area of the Fenix code).

It sounds like the lack of a Fennec repo would prevent it from being upstream to Iceraven for android-components unless Interfect were to drastically modify his workflow. Whether that's an option for him is something only he knows.

[interfect]

Note that we at F-Droid build Android Components, App Services, Glean and GeckoView libraries from source. There's no Maven repo that could be used as a drop-in replacement of the Mozilla repo.

That would make swapping over challenging; I don't know enough about the build system at the moment to say how I could accomplish this. I had very little luck getting the F-Droid build tooling to build Iceraven, because it involves a VM that it wanted to run in ways that didn't quite work on my computer. But I've reinstalled since then so maybe I could get it working if I tried again?

[interfect]

The Github-based build process is probably not going to be able to use the F-Droid build system, though. That would need something else to orchestrate the builds of all these pieces.

[relan]

I had very little luck getting the F-Droid build tooling to build Iceraven, because it involves a VM that it wanted to run in ways that didn't quite work on my computer.

F-Droid's fdroidserver tools can run build commands in a Vagrant VM, but also can run them directy on the local host. Just omit the --server argument.

Also note that full Fennec F-Droid compilation for a single architecture takes about 3 hours on my (pretty old) quad-core machine. Setting up ccache for LLVM (we build WASI toolchain, which is needed for libraries sandboxing in Gecko) reduces this time by more than a hour.

[giostark]

Desolation... uninstalling on fly.
So much effort to stay away from google ... but he restored about:config !!!! Bloody hell...

[SkewedZeppelin]

@giostark safebrowsing is unrelated to these proprietary libraries, is an open source client implmenetion, can be configured to only perform local checks, and is an extremely powerful feature that can stop phishing/malware campaings within minutes.

[giostark]

@SkewedZeppelin
Yep is not related , I know.
And everything is useful , to whom?
The route the powerful tool come to be useful , matter a lot.

[CharmCityCrab]

This issue (or something similar enough that it looks the same to me as a lay person) has also surfaced in regard to Tor browser on F-Droid:

https://gitlab.com/guardianproject/fdroid-metadata/-/issues/3

[SkewedZeppelin]

It hasn't surfaced, it has been there for years.

[CharmCityCrab]

It hasn't surfaced, it has been there for years.

I probably should have said "resurfaced" as in seems to have become a more actively considered issue with a new thread (The one linked to above) having been started noting the specific library in question in the last week and received some attention and replies. I can see a link back from that link to a more general discussion three years ago that's last comment was 10 months ago.

Of course, that doesn't speak to what may have been steady hard work going on behind the scenes, or what may be on various other related issue trackers for different collections of projects that include the browser.

To be honest, this is not the world's biggest issue for me, especially with Iceraven over three months out from it's last update of any kind. I'm just noting this since the issue is open and I stumbled across something that may be at least mildly relevant (Even if I'm off as to timeframe of the issue, at least the links might make it easier for someone looking into it later to gather information).

I'd much rather see @interfect or a new volunteer focus on cutting an update than dealing with this right now.