Last release adds proprietary tracking libraries

[IzzySoft]

Checklist

• [X] I am able to reproduce the bug with the latest DEBUG version.
• [X] I've checked that there is no issue about this bug.
• [X] This issue contains only one bug.
• [X] The title of this issue accurately describes the bug.

Steps to reproduce the bug

Just check the libs

Expected behavior

No tracking

Actual behavior

Contains Crashlytics, Firebase analytics

Screenshots/Screen recordings

Logs

No response

InnerTune version

0.5.1

Android version

n/a

Additional information

I've removed that update again from my repo and disabled updates until this issue is solved. Please check, your build on F-Droid might fail as well.

[z-huang]

Many people don't know how to get adb logs, so I can't fix some issues. Firebase Crashlytics records logs automatically, which helps me fix bugs more efficiently. Also, I plan to add some new features, and I need to know the geographic distribution of my users. Therefore, I added Firebase Analytics. Firebase provides many other features which can be utilized in the future. The goal of this app is to provide a free music streaming service as good as YouTube Premium, even better. To be honest, compared with better user experience, privacy isn't my first concern. Even though there's no trackers in the previous versions, requests to music.youtube.com make it possible for YouTube to track you. I know that F-Droid and IzzyOnDroid don't allow apps with trackers, so I'd like to request a removal of this app in these platform. Users can only download this app in GitHub. But no worries, the app will automatically check for updates and notify users. Anyways, @IzzySoft, thank you for discovering and promoting this app when it's in the early stage.

[M00NJ]

Many people don't know how to get adb logs, so I can't fix some issues. Firebase Crashlytics records logs automatically, which helps me fix bugs more efficiently. Also, I plan to add some new features, and I need to know the geographic distribution of my users. Therefore, I added Firebase Analytics. Firebase provides many other features which can be utilized in the future. The goal of this app is to provide a free music streaming service as good as YouTube Premium, even better. To be honest, compared with better user experience, privacy isn't my first concern. Even though there's no trackers in the previous versions, requests to music.youtube.com make it possible for YouTube to track you. I know that F-Droid and IzzyOnDroid don't allow apps with trackers, so I'd like to request a removal of this app in these platform. Users can only download this app in GitHub. But no worries, the app will automatically check for updates and notify users. Anyways, @IzzySoft, thank you for discovering and promoting this app when it's in the early stage.

I have no say here just wanted to give feedback. I'm very unhappy with this development direction. I use InnerTuner FOR privacy reasons. Although I think having the goal to improve the app's user experience to a point where it's as good or better than YT Music is great, I disagree that this has to come at the expense of the user's privacy. I don't see how knowing the users geographical distribution would be necessary to further this goal and I doubt that the data provided by this change would be of much use. The open source community is very passionate about privacy and many use VPNs or something like orbot to hide their location. The argument, that the requests to music.youtube.com already make the user vulnerable to tracking is only true if the user doesn't take steps to prevent this (for example by using a VPN again). I also think removing the app from Izzy and F-droid will greatly decrease it's discoverability and therefore bring down the amount of contributions made to this project. So to me the only argument that holds real weight is the efficiency gain in fixing bugs, because of the automaticly recorded log's. But I'm sure there are alternatives to this and also think the loss of users due to the removal of the app from popular open source repositories and because many current users will stop using and contributing to the app, because they are unhappy with these changes, will cancel out this advantage over time. I'm sure you've thought this through very thoroughly and won't change you mind because of some random comment, but I hope I can convince you to at least wait for the community to have a discussion about this, before going through with the removal of IT from Izzy and F-droid.

[IzzySoft]

Many people don't know how to get adb logs, so I can't fix some issues. Firebase Crashlytics records logs automatically, which helps me fix bugs more efficiently.

And only Firebase can do this? And you don't care whether folks using your app are happy with this? Let me correct both assumptions: At F-Droid we use ACRA for that, configured for mail reports. It pops up a dialog, showing what it will send, and asks the user for consent. There are also other alternatives available to choose from. As @M00NJ correctly points out:

I use InnerTuner FOR privacy reasons.

Your use of proprietary and intransparent tracking libraries (don't tell me you can guarantee what it sends and what not or I'll ask for proof you cannot give; Google's say-so does not count, they also said location was not recorded when you turned that off, and that was proven wrong) contradicts that.

and I need to know the geographic distribution of my users

Do your users have a say on that? Maybe some are not happy sending out their location, and have good reasons for that? I didn't test (as I don't use the app), but I hope you've made that transparent and ask for consent. And as @M00NJ correctly pointed out: Many of them probably use TOR, a VPN or some other proxy, so I doubt this information will be reliable anyway.

Firebase provides many other features which can be utilized in the future.

So your app is no longer FOSS, right? And as for those "other features", again there are alternatives, e.g. appwrite and Supabase. But if Google-tying is where your app will head, I again have to agree with @M00NJ:

the removal of IT from Izzy and F-droid.

F-Droid will disable updates as they will continue to fail (if Firebase or other non-free libraries are found, the build will yield and not succeed). And I will remove the app here as well then, as that violates my inclusion policy.

To be honest, compared with better user experience, privacy isn't my first concern.

Thanks for being open about this – but then, your app indeed no longer fits F-Droid or my repo unfortunately.

I know that F-Droid and IzzyOnDroid don't allow apps with trackers, so I'd like to request a removal of this app in these platform.

I will comply with that, if this is what you want. F-Droid will disable updates and, if you wish so, archive the existing versions (please open an issue for that at fdroiddata).

Users can only download this app in GitHub.

If they find it there. This will significantly reduce your "user base" – but OK, your choice. There are other YT clients at F-Droid and in my repo which people will find before stumbling upon your Github repo then :man_shrugging:

But no worries, the app will automatically check for updates and notify users.

Not if they haven't installed it already :wink:

TL;DR: No bad feelings (apologies if my comments sound harsh, I just stuck to the facts; nothing personal there). I urge you to reconsider, and take a look at the alternatives pointed out. Then please let me know your final decision.

PS: I fully agree with everything @M00NJ wrote, and second that.

[matchboxbananasynergy]

I think I have a perspective on this that's somewhere in the middle. If someone wants to use Firebase or something similar to it, that's their choice. That said, I'm also a proponent of users (of anything) having the same choice.

Analytics and crashalytics help, I'm sure, but some people may not want to take part in the collection of their data, even if it might be for totally benign reasons. It should at least be possible to disable that from within the app.

You already have a "privacy" section in the app's settings, so I assume that you care about that to some extent, and you provide an option for people to disable the KuGou lyrics provider in that part of the settings. If connections being made to a lyrics provider warrant a toggle in the privacy section of the app's settings, shouldn't analytics libraries also warrant a toggle? It could be opt-out (as in, enabled by default, but with the option to be disabled), though I'd rather a choice be given upfront, or for them to be opt-in (though I understand that them being opt-in will significantly reduce the amount of people actually providing you with data to improve your app, so it's not a simple choice to make).

I think a great example of things being implemented in a sane way is how Aves Gallery does it (https://github.com/deckerst/aves). Upon install, you're asked if you'd be okay with crashalytics etc. being enabled, and there's a single toggle for you to opt-out. Not having to hunt in settings for it; right there in the startup screen.

Another sane way to do this is the way that Signal (and its forks that I'm aware of) do it, where they have an option to generate debug logs from within the settings, thus making it easier for users to generate useful logs that assist in resolving issues quickly. Perhaps that approach is something to consider as well.

While this wouldn't change something regarding the F-Droid (and potentially also IzzyOnDroid) inclusion, it would still be a great move towards being transparent with your users and giving them a choice. Better user experience is done for the users of your app anyway, right? So should they have a choice as to whether they want to participate in that?

While I don't think telemetry or analytics are inherently evil, choice and reasonable consent when it comes to these things is in my opinion very important, so if you do decide to stick with these libraries (which wouldn't be a dealbreaker for me), I'd like to see you do so in a way that treats your userbase with respect and gives them a choice.

Judging by the fact that you haven't closed this issue, I'll assume that you haven't made a final decision on how to approach this, which is why I'm offering my thoughts, which I hope you'll find useful.

All the best.

Edit: added more details and context

[IzzySoft]

Ack to that, @matchboxbananasynergy:

While I don't think telemetry or analytics are inherently evil

I'm not saying that (as long as a choice is given). My warnings rather go towards the proprietary part: you can never tell what the library is really doing (in addition to what you will see) as you cannot verify. And espcially when that library comes from Google (or any other GAFAM), known to collect and hoard our "behavioral data".

Nice you point to Aves¹, and let me add to that to pick up another idea from there: Aves has multiple build flavors set up, which could be done here as well. One of them is a F/LOSS flavor coming entirely without the proprietary parts (Aves Libre does not even have the option for Google Maps, for example). So providing a F/LOSS build for those concerned about their privacy would solve the issue for both parties.

¹ _{Disclosure: I'm a vivid and excited Aves user, my favorite gallery I love to use – and was involved with the described process ending up with Aves being listed at F-Droid.org}

[siggi1984]

if the app is now being tracked too much, i'll look for another app and i've also donated money, i wouldn't have done that.

[z-huang]

First of all, thanks for your feedback. I’m all ears and trying to find a win-win solution.

When I was creating this app, all I had in mind was: how to make it as powerful as the original YouTube Music application? I was totally unaware of the foss world at that time. After the source code was uploaded to GitHub and got some traffic, people started to share this app, and they often described it as a “FOSS” app. It was a coincidence that this project didn’t use any proprietary library. Now the app has the most basic features, and it’s time to add some advanced/experimental features. Therefore, it’s inevitable that this project will use some proprietary libraries, if needed. For example, I’d like to introduce features with machine learning, and ML Kit is a good choice. You may claim that there’re other alternatives, but as a developer, Firebase that bundles many tools together is much more appealing and efficiency.

Now I know that there is a group of my users who put privacy in the first place; they use this app because of privacy. Though we have different view, I respect your idea and want to find a solution sincerely. After reading the discussion of Aves getting included into F-Droid, I think I can solve the issue in the similar way. InnerTune will have two build flavors in the future: full and foss. Full version contains all features. If some features require proprietary libraries, they won’t be included in the foss version. Therefore, foss version can be uploaded to F-Droid and IzzyOnDroid, while full version can only be downloaded in GitHub. The detailed comparison of the two versions will be placed in GitHub wiki. This way, we can have the cake and eat it.

[M00NJ]

Great news!

[IzzySoft]

ML Kit is a good choice.

There unfortunately two opposite things meet: It's powerful and admittedly useful at one hand – but a total show-stopper FOSS-wise (and tracking). Plus I do not know about any alternative to that (happy to be told one so I can add it to my list should someone know an alternative).

You may claim that there’re other alternatives, but as a developer, Firebase that bundles many tools together is much more appealing and efficiency.

Alternatives to Firebase that bundle many tools etc? Oh yes, there are appwrite and Supabase, both FOSS, coming very close (I've been told; not being an Android dev, I didn't try them myself).

Though we have different view, I respect your idea and want to find a solution sincerely.

Thanks! Same from my end: respect, and trying to find a solution fitting both.

After reading the discussion of Aves getting included into F-Droid, I think I can solve the issue in the similar way. InnerTune will have two build flavors in the future: full and foss.

:star_struck: That's great news! :heart_eyes: May I recommend to make that clear then with the attached APKs, too, so my updater can fetch the right one? For example, by using a suffix like _foss.apk for the FOSS one. I'd then tell my updater to only accept that one. (something like InnerTune_foss_v<version>1.apk vs. InnerTune_full_v<version>1.apk would of course work fine as well)

Therefore, foss version can be uploaded to F-Droid and IzzyOnDroid, while full version can only be downloaded in GitHub. The detailed comparison of the two versions will be placed in GitHub wiki. This way, we can have the cake and eat it.

Wonderful! Thank you a hundred times!

[z-huang]

Naming:

• Full version: InnerTune_v<version>_full.apk
• Foss version: InnerTune_v<version>_foss.apk

[siggi1984]

I think it's good that you have an ear for your community

[IzzySoft]

Thanks @z-huang! So for my repo I've now defined:

    ApkMatch: /foss/i
    ApkIgnore: /(full|\d\.apk)/i

Which means my updater will look for an APK matching the first pattern and, if found, will take that. If that's not found it will check all other APKs which might be there, ignoring the ones matching the second pattern (which covers the current naming, plus the future naming of the non-foss variant), and what is left would serve as "fall-back".

I've just manually triggered an update to check, and the current one was properly ignored. So I re-enable daily update checks now; once APKs with your new naming schema show up, they should be pulled.

Now to F-Droid.org: I assume you will be using build flavors to separate the two builds. What will be the name of the foss flavor, so metadata there could be adjusted accordingly for builds to succeed? Once the first release with those flavors defined will be there, we should update it at F-Droid's build recipe accordingly. I could do that with the current build (which was already added by CheckUpdates, is part of the currently running build cycle, and supposed to fail because of the non-foss dependencies), so when the next release is tagged builds (hopefully) succeed again (it would copy the recipe from the previous build, which then has the flavor specified).

Oh, it's a reproducible build – and the file name to check against will change. Will consult with my co-maintainer on how to update that (I know it's possible defining it at build-level, I just don't remember the correct syntax :see_no_evil:). Edit: Found it by grepping for similar cases, so I can do that for your app as well.

[licaon-kter]

Disabled last version and autoupdates for now: https://gitlab.com/fdroid/fdroiddata/-/commit/f280d90490c49fee30a0c01ff4540ffa6125c49d

@z-huang ping us when the flavour is ready for testing

[z-huang]

@IzzySoft @licaon-kter Okay, I've added the product flavors. The name of the foss flavor is just foss. Please test if it can be built and doesn't contain proprietary libraries, thanks!

[licaon-kter]

This recipe builds fine:

  - versionName: 0.5.1
    versionCode: 17
    commit: f363d13707c2d9794d7d4b9e78e02b6458a07ea5
    subdir: app
    gradle:
      - foss
    prebuild: sed -i -e '/google.services/d' -e '/firebase/d' build.gradle.kts ../build.gradle.kts

...but note that you need to do the same sed when you build your own -foss apk.

Talking about that, can you provide one to test the reproducibility?

[z-huang]

To make the building process easier, I changed build.gradle.kts so that it won't include gms and firebase when building the foss version. If it's working well, the line with prebuild can be removed.

[z-huang]

Foss release build of the latest commit: app-foss-release.apk.zip

[licaon-kter]

Appears to be repro :tada:

  - versionName: 0.5.1
    versionCode: 17
    commit: d530cbf9aca30eba98e72fce4732e78beab75548
    subdir: app
    gradle:
      - foss
    prebuild: sed -i -e '/google.services/d' -e '/firebase/d' build.gradle.kts ../build.gradle.kts

...but still need to sed stuff as the fdroid scanner is not a scalpel but a hammer :smile:

[licaon-kter]

@z-huang ping us when new version is tagged

[shuvashish76]

z-huang: Even though there's no trackers in the previous versions, requests to music.youtube.com make it possible for YouTube to track you.

Not that important but IMO this information should be mentioned in app description for users who don't know about it. Alternatives e.g: Piped, Invidious.

IzzySoft: There are other YT clients at F-Droid and in my repo.

YT music specific apps growing slowly but no piped versions yet. @z-huang To be clear I'm not suggesting to jump piped or anything, just saying that in this case alternatives do exist ;)

[licaon-kter]

Alternatives e.g: Piped, Invidious.

You mean proxy your streaming through some other server hosted by who knows who, who knows where?

[shuvashish76]

who, who knows where?

Official one hosted by piped dev Kavin from India. You've the option to selfhost it & add to your client if supported ;)

[marcossmtp]

very nice to heard that a FOSS version it will be available. And nice to heard that the programmer heard their users and take a middle solution to make happy all the parts.

[DanielProg39]

Glad to see this problem fixed. I would have been one of those who might never get updates if I didn't occasionally check the releases section of this repo and notice a new version. And I would never have known about the semi-proprietary nature of the app and tracking if I hadn't looked up @IzzySoft to tell him I couldn't access his repo from either F-droid (failed to connect) or browser (ERR_CONNECTION_REFUSED), and hadn't seen this issue he opened on his page.

My opinion: I think using the alternatives mentioned by Izzy is the best option for now if analytics is the only thing being implemented using proprietary libraries. I also support @shuvashish76's point, as I would love to have at least my library automatically synced with the Piped account, and using instances instead of connecting directly to YouTube is also a great idea. This is exactly what I'd like to see as one of the future features, and it doesn't require any proprietary dependencies while improving privacy and user experience.

[DanielProg39]

And yes, I also think that removing the app from F-droid and IzzyOnDroid for the sake of adding Google Analytics will do more harm than good, as most of the users of this app (and most new users as well as stargazers for a GitHub repo) are users of these repos, and there aren't many people who would specifically search for this app on GitHub to find out why it was removed and how to use it now. Not to mention that as well as losing most users (at least for new releases), there wouldn't be many new ones as GitHub will promote a repo if it gains a new audience quickly, which would not be the case for InnerTune because, as I mentioned before, most new users as well as stargazers for a GitHub repo are users of F-droid repos, so it would be poorly promoted by GitHub.

[M00NJ]

I also support @shuvashish76's point, as I would love to have at least my library automatically synced with the Piped account, and using instances instead of connecting directly to YouTube is also a great idea. This is exactly what I'd like to see as one of the future features, and it doesn't require any proprietary dependencies while improving privacy and user experience.

I highly doubt features like this will ever be implemented in this app. The dev is not concerned about user privacy. Quite the opposite actually. He's willing to sacrifice privacy for convenience. That's why we're all here in this thread after all. Hoping for these features to be implemented, after what just toke place, is like hoping for you laptop manufacturer, who just started to solder SSDs, to make ram upgradable in the next model. We all know this won't happen. The FOSS flavor is nice, but I'm pretty sure it will only remove features that are not allowed on F-Droid or Izzy and not implement different ones. Don't get me wrong, I agree completely agree that these features are important and want to see them be implemented, but the only way I see this happening is, if someone forked the project and put privacy first. As of now, I think LibreTube in audio mode is the closest thing to what you mentioned.

[DanielProg39]

@M00NJ I have exactly the same thoughts. I started using this app because LibreTube's audio mode was buggy at the time, and this app has a lot of YT Music specific features and general useful music app features, but now I might consider trying out LibreTube's audio mode. Although it would be very painful to move hundreds of tracks from my InnerTune library to Piped.

[z-huang]

I also support @shuvashish76's point, as I would love to have at least my library automatically synced with the Piped account, and using instances instead of connecting directly to YouTube is also a great idea. This is exactly what I'd like to see as one of the future features, and it doesn't require any proprietary dependencies while improving privacy and user experience.

Piped API isn't powerful enough for my use. It's the InnerTube API that makes it possible for various features already exist in the app. That's also the reason why ViMusic doesn't use Piped API. Synchronization will take a lot of effort to implement, so I don't plan to make it in the near future.

I'll restate my motivation for creating this app: it's a music player with many great features, beautiful UI, and NO COST. If you want purely privacy, there'll be a foss version. If you're still not satisfied, there're many alternatives to try out. There's no accounting for taste.

[z-huang]

@licaon-kter @IzzySoft v0.5.2 is released. Full version is split to multiple apks, but it shouldn't affect on your side.

[licaon-kter]

@DanielProg39 @M00NJ https://github.com/z-huang/InnerTune/wiki/App-Versions

[IzzySoft]

@z-huang correct: my updater will stick to the foss APK – and there's only one matching that name-part :smile:

[siggi1984]

If you are looking for a music streaming app with a piped connection, you should take a look at the app here.

https://github.com/anandnet/Harmony-Music

since innertune tracker i switched to the app.

[licaon-kter]

Updated in F-Droid metadata: https://gitlab.com/fdroid/fdroiddata/-/commit/b1735428fcb2f717c86691cabf5063619cd18c95