Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Crashlytics? #181

Closed
IzzySoft opened this issue Aug 24, 2019 · 29 comments · Fixed by #184

Comments

@IzzySoft
Copy link

commented Aug 24, 2019

Personal finances and tracker libraries don't go well together. Would you consider removing Crashlytics, for enhanced privacy? Thanks in advance!

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Aug 27, 2019

@IzzySoft thanks for getting in touch! We are considering user privacy first, this is why there is no backend storage for user's data (only personal Dropbox if user wants make backups).

In contrary, I don't think that removing Crashlytics will make any difference in terms of privacy because all crash data is anyway reported to Google Play Developer Console, there is no way to disable it.

Crashlytics just allows us to get that data faster and in more consistent way, so we are able to faster fix any issues. Honestly, I don't think that removing it will bring any value to our users. Wdyt?

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

Thanks for answering, @yevhenii-kanivets – but why would all crash reports go to the developer console "anyway" if they are not there?

As for my reasoning: with sensitive data involved, one shouldn't use proprietary tools to send data to any third party. You'd have to trust a company that lives on the data of users not to include things you didn't even tell them. And especially "us tin foils" don't like that (Google) connection (on my Android devices, there aren't even Google Services or any other apps from the "Google Apps" package present for that very reason). F-Droid would plainly reject packaging any apps coming with such libraries, for good reasons.

I'm aware that the majority "out there" is of the opinion they've got "nothing to hide" and thus don't care (but ask them to hand over all their credentials (or just their unlocked device) to prove their "nothing to hide" and you will discover otherwise). Still, there are people who do care. They'd prefer a version without those "known problematic candidates" – especially ones shipping data to "known privacy offenders / big data collectors". We greatly appreciate our apps coming without them, and don't consider apps that include such.

There are several options for that. If you don't want to drop those proprietary components altogether, you could use a special build flavor (or build variant) to create a "free APK" to be shared here (or to be build by F-Droid even – I'd then volunteer to help getting it listed there if you want); ship that to us "tin foils" (via F-Droid or attaching it here to releases/ – in the latter case, I could take that APK into my repo for easy install/update on client devices), while keeping the "standard variant" for Playstore; both sides would be happy that way. Or you could replace proprietary analytics by privacy-friendly open-source ones, like ACRA, which even uses opt-in by default. Or mix both approaches (Crashlytics for Play Store, ACRA for the "tin foils build").

Going that path you could even underline your "privacy first" approach visibly. Putting it thick: "we replaced … for enhanced privacy …" – which would convincingly show that other than just putting "we take your privacy, seriously" statements, you really mean it 😉

Again, thanks for taking your time and considering! After all, it's a suggestion – I cannot expect you have to take it, but surely would very much appreciate if you did, whichever of the variants you chose.

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Aug 27, 2019

@IzzySoft I've got you point, but I'm not ready to spend my time dealing with your request, sorry :)

This is an open source solution, so you can at any moment fork it and assemble the build, which will correspond to your high privacy standards. You are free to publish it anywhere, you think it makes sense.

In the meantime I'll continue to work on the features for simple Google-friendly users. But you still can fork this repo at any time and make it high privacy compatible.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

Got your point, too – though while I personally can fork I would get no further (I'm no Android dev).

I take it you would not be opposed if someone provided a PR including the build variant? It might need minimal changes only (not being a dev, I cannot say that with confidence but just by guessing), say some lines in the build.gradle and one or two conditionals elsewhere. If that's correct: Mind keeping this issue open with a "help wanted" label to attract potential collaborators?

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Aug 27, 2019

@IzzySoft yes, we can do that 😉

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

Thanks a lot! I'll try to reach out on Mastodon if there's an Android dev who would like to help out, pointing to this issue. Even if no one turns up straight away, that'd be at least drawing a little attention to your project – and some "boosts" might bring someone in finally. 🤞

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

See: not an hour went by, and we already have almost 20 boosts. And one friendly dev who shares my opinion of "This would probably be an easy thing to do", and considers taking a look 👍

@Yky Yky referenced this issue Aug 27, 2019
@Yky

This comment has been minimized.

Copy link

commented Aug 27, 2019

@IzzySoft Here you go. I created a PR. Checked with Classyshark, Crashlytics is gone.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

Phantastic, @Yky – thanks a lot!

@yevhenii-kanivets that was fast, wasn't it? Mastodon even surprised me here (and especially Yky did). When you found time to take a look and (hopefully) merge it, please let me know if you're fine with pushing that to F-Droid (and let F-Droid build the "tracker-free APK") – or if you'd prefer to build the APK yourself and have it in my repo. Pros/Cons: Faster updates via my repo – more prestige and reputation in the official one (mine is what Debian would consider a mix of non-free and testing).

@Yky

This comment has been minimized.

Copy link

commented Aug 28, 2019

I'm not sure @yevhenii-kanivets will want to marge this as it would remove Crashlytics from his app.

However, @IzzySoft we could build a version from my fork and put that into F-Droid, as @yevhenii-kanivets recommends in his comment above.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

I didn't check your PR – didn't you establish a separat build flavor for that? If you "overwrote" the default flavor, it might well be that Yevhenii doesn't want to merge that.

Sure you could create a fork. But would you keep that up-to-date in a timely manner? The big advantage of a build flavor would be that once it's done, it's done and new versions would automatically profit from it.

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

PR #183 only removes Crashlytics from this application. Of course it would be possible to build an fdroid version from @Yky's fork, but maintaining two different source trees is tiresome and error-prone. A much cleaner way – what @IzzySoft is talking about – is to use build flavors, allowing to build different versions of an app from the same source tree. As a quick research showed, it is also possible to only include a dependency in some build flavors, which should be done here.

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Aug 28, 2019

@Yky @IzzySoft @fynngodau thanks for your commitment, but you are right - removing Crashlytics isn't smth I will to merge, sorry :/ Build flavour would be OK, but will take more time and efforts to do.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

We're working on it, @yevhenii-kanivets (or rather @fynngodau is giving it a try). No promises yet, I don't want to put pressure up on anyone 😉

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

I have opened a pull request which will add different build flavors, see #184. @yevhenii-kanivets actually already made it very easy by moving almost all Crashlytics interactions into a separate java file.

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

@IzzySoft In the build.gradle file, I have noticed that com.dropbox.core:dropbox-core-sdk:3.0.5 is compiled for this application. I'm assuming this is also a proprietary library and disqualifies the app from inclusion in the main fdroid repo?

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Aug 28, 2019

@fynngodau thanks, I'll take a look on your PR tomorrow. FYI, Dropbox is used for one-single feature, which can be disabled by hiding a menu item in Navigation Drawer.

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

@yevhenii-kanivets Even if it is not used, if I'm right, no proprietary library must be included in applications that want to qualify for inclusion in the main F-Droid repository (please confirm @IzzySoft). But a proxy class could be written the same way that Google Analytics is dealt with in the PR. Edit: Looking at the code, rather not exactly the same way, but still very possible. I'll see whether I can expand the PR to cover dropbox as well. Edit: Done, see #184.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

If built from source, Dropbox should be OK AFAIR as it uses a free license – as long as that license is compatible with the one of the main project (by the way: what license does Money-Tracker use?). We have some such projects at F-Droid which use Dropbox, so we can compare with how it's done there. Maybe it's available via a whitelisted Maven repo, or the code is integrated via a git submodule, or as srclib at F-Droid. Hard to look from here with just a browser. Just found Money Manager Ex is one such app according to its description, as is MobilePauker (both using GPL3). The latter is a good match: uses it the same way as Money-Tracker (com.dropbox.core from JCenter).

TL;DR: Seems all fine concerning Dropbox, no changes needed except declaring a license for Money-Tracker itself. As said, GPL3 would be fine.

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

Oops, I'll undo the second commit then.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 28, 2019

Yeah, that caught me more than once as well. With Dropbox included, it would raise the NonFreeNet AntiFeature, though.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 29, 2019

Hey, cool that!

@yevhenii-kanivets Which way do you want to proceed? Shall I create a request for packaging with F-Droid – or do you rather want to keep the ball low and first provide both APKs and I take the "free" one into my repo, and we decide for the official one after that? Which way ever, we first need to wait for the next tag covering the PR.

@fynngodau thanks for your work! Would you like to create another PR establishing Fastlane structures for description and screenshots, if Yevhenii decides to go for the official repo? Details on that can be found here, initial description/screenshots could be taken from Google Play, per-release changelogs are optional and could be skipped. Basically something like this:

└── fastlane
    └── metadata
        └── android
            ├── en-US
            │   ├── short_description.txt
            │   ├── full_description.txt
            │   ├── images
            │   │   └── phoneScreenshots
            │   │      ├── 1.png
            │   │      ├── 2.png
            │   │      ...
            │   └── changelogs
            │       ├── 100000.txt
            │       └── 100100.txt
            └── ru
                ...
                └── changelogs
                    └── 100100.txt

@yevhenii-kanivets if you install fastlane (for F-Droid, the structures suffice), you could use that for Google Play as well – catching two birds with one stone: one place to maintain your app's metadata, distributed to both places. en-US would be mandatory for F-Droid (default language), other locales are optional.

A note on the screenshots: IMHO they ideally come without "framing", considering that people want to see and decipher them on small-screen devices. But the ones you use at Play would be OK, too.

@fynngodau

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

If @yevhenii-kanivets does not want to use fastlane, it seems it is also possible to have fewer layers of directories (only a metadata folder, leaving out fastlane and android layers) as fdroidclient does. I couldn't find any documentation on this structure, but the rest looks unchanged.

Furthermore I agree with @IzzySoft that unframed screenshots are preferable, but I can open a PR with the material currently available on Google Play anyway.

I think Money-Tracker still has no license, preventing it from being included in the main F-Droid repository (not sure what the policy for your repo is, @IzzySoft).

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Aug 29, 2019

Doesn't hurt to keep it in fastlane structure and just not using the binaries. That way it's at least using a widely accepted standard. The other structure is rather F-Droid internal (you find it behind my link above, in the section describing to put it inside F-Droid metadata – which is what we meanwhile discourage, as it was growing to much and makes it hard to handle on our end. Ahem, time for disclosure: when I speak about "our", I'm one of the F-Droid maintainers 😉).

Oh, and yes: the license is a requirement for the official repo – and at least strongly recommended for mine.

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

@IzzySoft @fynngodau sorry, I was busy this weekend (moving between countries). I'll think which option is better for OMT. For now, I think that fastlane is a better longterm solution. But let me think few days...

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Sep 2, 2019

Yes, Fastlane is definitely to be preferred: it's an established structure not only with F-Droid. And sure, whenever you're ready 😃 Just ping us when a release is tagged with the new build flavor, a license and potentially also Fastlane structures covered – and let us know where to go from there. As pointed out: I gladly help you getting your app into the official repo then – or, if you could provide the corresponding APK, take it in mine.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Sep 18, 2019

Any news here, @yevhenii-kanivets? I see you've made a new release yesterday. If you could also attach the app-foss-release.apk, I could add that to my repo¹ meanwhile – and as soon as you've decided on Fastlane¹ (and have it set-up as well as tagged), gladly help you to bring it into the official F-Droid repo.

¹ 1+1=2: with that goal in mind, I could even prepare you the Fastlane data while establishing your app in my repo, and then upload them here for you to use. I've just done it that way for another app.

@yevhenii-kanivets

This comment has been minimized.

Copy link
Owner

commented Sep 19, 2019

@IzzySoft I'm sorry for not keeping you informed. Yes, my plans is too fully released the new version of OMT to GP to the end of the week and then, while our developer is working on another project, configure fastlane. So should be done by the end of the month.

@IzzySoft

This comment has been minimized.

Copy link
Author

commented Sep 19, 2019

No worries then – I was just wondering. My offer stands: As soon as you provide a FOSS APK, I can take that into my repo and prepare fastlane, provide that to you, and then you can "fine-tune" it. Of course if you prefer you can do it yourself 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.