Recent tags & APKs missing

[IzzySoft]

According to your tags, the last release was 6/2021 – according to Play Store there was a release just a few days ago. Do you no longer provide the releases/APKs outside Google's walled garden? Not everyone has access to that place (it's blocked in some countries, some devices have no GApps, etc), so it would be nice if you could provide the APKs here again. Thanks in advance!

[IzzySoft]

@nsantacruz any word?

[nsantacruz]

@IzzySoft we still don't have an automated process for uploading APKs to our repo and add them ad hoc currently. We will try to add the latest release when we deploy the next version.

[IzzySoft]

Thanks! Looking forward to that then. I was just picking up the question on my regular check when my scanner reported "dead bones" which are pretty much alive 😉 1.5 years is a long time in the software world.

[nsantacruz]

@IzzySoft see here for the latest APKs. https://github.com/Sefaria/Sefaria-Mobile/releases/tag/v5.14.7

[IzzySoft]

@nsantacruz Thanks! Ah, I see tag naming has changed, no more leading v. Adjusted the config, and the updater pulled the last version. Wonderful!

Any chance to reduce the number of "offenders" (proprietary & tracking libs) further?

Offending libs:
---------------
* Play Install Referrer Library (/com/android/installreferrer): NonFreeDep,NonFreeNet,Tracking
* Crashlytics (/com/crashlytics): NonFreeDep,Tracking
* Google Ads (/com/google/ads): Ads,NonFreeDep
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Android Market (/com/google/android/finsky): NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): NonFreeDep,Tracking
* Firebase Installations (/com/google/firebase/installations): NonFreeNet
* Invertase RNFirebase (/io/invertase/firebase): Tracking,NonFreeNet

10 offenders.

Compared to the previous version I had here, one is already gone (Play Install Referrer wrapper). Just asking, not complaining; my repo usually doesn't allow for that count, so I apply grouping here (Firebase Data Transport, Installations, and Firebase (core) I count as one, as usually the other 2 are dragged in as dependency of the same larger framework – but are really 2 analytics libs needed?)

I hope I don't annoy you with this question. But it always hurts me to see a nice F/LOSS project tainted this way. Hard to do without, maybe – but I still hope and try to reach higher 😉

[IzzySoft]

@nsantacruz any word on those libraries? The number exceeds by far what my repo inclusion criteria permit. I'd really like to keep Sefaria up there, but I hardly can justify it much longer. You could also see here for some alternatives you could use to replace offenders, like appwrite or Supabase instead of Firebase, or one of the acceptable analytics instead of those 2 privacy invaders. A jew should be able to study Torah without all those goyim looking over the shoulder, don't you agree? That list makes many uncomfortable.

[IzzySoft]

@nsantacruz not even a comment? That is sad 😢 Especially with religious apps (or health apps, or apps dealing with other sensitive topic), many of us do not want their every activity tracked to some data collecting company profiling us. For me personally, those trackers are show-stoppers – and so they are for many others as well.

Further I see the last release available here is from 12/2022 – while at Play, there are at least 3 newer releases. So have you again forgotten the recent tags and APKs here – and maybe one of them already has some of the offending libraries removed?

I'll shift the due-date of the issue at my tracker a last time now, then I will have to act. Thanks for understanding!

[HadaraRachel]

Hi @IzzySoft
Thanks for reaching out.
The latest release has the latest apks
https://github.com/Sefaria/Sefaria-Mobile/releases/tag/v6.0.12

[nsantacruz]

@IzzySoft Regarding removing the libraries you mentioned, we don't have any plans at this point. We rely on these libraries to give us insights into how to improve the app and fix live bugs. I understand there are open source libraries which do these tasks but we haven't found these libraries as helpful.

[IzzySoft]

@HadaraRachel thanks for adding them!

@nsantacruz would you consider a foss build flavor at least (i.e. publish the current one aka gplay with the libraries to Play Store for the majority of those using that place, and in addition to that publish a foss flavor's APKs here at Github releases for those find them a show-stopper)? That way you'd still get your insights, as that majority will still ship them, while those who mind can have better privacy protection – which can then count as a win-win, and I could pick the latter for my repo.

[nsantacruz]

This is an interesting suggestion I hadn't considered. If you can find a programmer who is willing to volunteer some time to:

• Determine which libraries are not FOSS
• Determine a process to remove/mock these libraries so we don't need to modify our code (i.e. if we simply uninstall the libraries, our code will fail because we use these libraries in our code. Possibly there is a simple way to mock the libraries at build time)
• Determine how to easily build both flavors of the app simultaneously

then we would likely consider this a feasible possibility.

[IzzySoft]

Determine which libraries are not FOSS

Done above (watch out for those marked NonFreeDep). The scanner used for that is FOSS, and disclosure: I'm its author. I know some projects have included it with their CI (getting a report before doing a release, to make sure nothing sneaked in), so that's doable too. Also, F-Droid.org uses it with its IssueBot (to scan apps requested for inclusion). For an overview, you can find things outlined in an article I wrote: Identify modules in apps. The corresponding IssueBot module (used via GitLab CI) can be found here – or you could simply use the library definitions (you'd just need libinfo.jsonl which holds the licenses and anti-features) and write your own code for that. Anti-features to watch out for would be NonFreeDep, NonFreeComp (a new one coming soon, separated from the former) – and maybe Ads and Tracking (if you wish, also NonFreeNet).

Determine a process to remove/mock these libraries

I'm not an Android dev, so I cannot really help with this part. The rough idea was to set up two build flavors (e.g. gplay and foss), then turn the corresponding implementation calls to gplayImplementation to keep them out of the foss flavor. As for mocking, where it's needed, ways I'm aware used by other projects include:

• write a wrapper class present in both flavors, calling to the "real code" in the gplay flavor and just "do nothing" in the foss one. Using a class name from your own name space then would prevent "false positives" by scanners – but it's a little more effort to set up.
• quick hack: use "stubs" in the foss flavor. You know which procedures your code calls. Write "empty procedures" with that using the same package names as the original code would do (com.google.*) and place that into the foss tree. Faster to implement, but would raise "false positives" with scanners.

Determine how to easily build both flavors of the app simultaneously

With that I must pass, as I'm no Android dev. But I think it should be not too complicated having two calls in the CI script. As for the APK files attached to releases, include the flavor names with them – e.g. app-arm64-v8a-foss-release.apk and app-arm64-v8a-gplay-release.apk, so one can see which is which.

Hope this helps a bit toward the goal – and thanks a lot for considering!

[IzzySoft]

I've just placed a call for help with this. Hopefully some help will arrive 🤞

[HadaraRachel]

Great Izzy, keep up posted!

[IzzySoft]

B"H someone™ will show up here soon™. I've got some replies that people forwarded my toot directly to some devs they hope can and will help. Of course I cannot promise a thing. Still, I should have made that call earlier…