Hacker News Reader

Comment by jhasse | Hacker News Reader

Android (without Google Services) is FOSS. Check out http://lineageos.org/ (successor of CyanogenMod).

As a replacement for the Play Store, check out https://f-droid.org/

F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do that since my app includes an API key that can't be published (according to the rules of the service in question), and F-Droid would need that[1].

[1] https://f-droid.org/forums/topic/what-to-do-with-private-api...

If the key is published as part of the APK, it is already public. Not committing it on github doesn't really reduce exposure.

I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?

You do it like that and just hope people won't abuse it.

What secret strings?

You distribute user-specific secrets after a user has logged in over a secure channel.

You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.

That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.

That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem.

Don't include API_KEY in the published source, include rot13(API_KEY).

You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part.

It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.

So rot13 should work as fine as that, I'd assume. You wouldn't publish API_KEY this way, would you?

In a sense, perhaps. But I feel that's just technical trickery on a reasonable request, so I don't see myself bothering with such workarounds.

I think the response krt gave was fair enough:

---

I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:

If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.

There are actually only two solutions:

1) Provide a way for the user (!) to enter API key or account information at runtime.

2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.

Should also add the f-droid tries to build software that are truly open, i.e. can function without 3rd part closed services.

I think many times you can limit the FOSS version to not include functions such as leader boards to avoid such issues and no one will complain.

Yes, I think that's a fair stance. Just means I can't publish my app. Maybe that's even desirable, considering the service is providing non-free data.

I think part 1 is fair, but part 2 is not. That's just silly.

Many people don't consider something "open source" if they can't build it themselves.

Other alternative app stores are the Yandex Store (https://store.yandex.com/) or the Amazon App Store, those include non-free software too.

You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.

From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.

There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications."

[1] https://f-droid.org/forums/topic/api-keys-and-free-software-...

Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.

Rootkit-style installing is also possible with F-Droid :)

Yeah, I've seen that option, but I like to keep that as a disabled option :)

What's the "rootkit style"? My searches for "rootkit style installation google play" did not result in anything meaningful.

It uses special privileges to run the installation in the background. Google Play Services is frequently called a "rootkit" because of stuff like that.

Don't forget the Yalp-store, which you can install from F-droid. Yalp can get you all the non-FLOSS software. Like Minecraft PE. ;-)

But you can!

F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.

You can do exactly that already.

LineageOS user here: This is the best Android distribution I've used, by far. I've used Paranoid Android, Slim8, Dirty Unicorns,... But none get to the level of featured and stability of LineageOS.

Extended per-app privacy settings, built-in root manager, lots of customization options... And the best of all: enormous community. There are builds for crazy amounts of devices.

The main problem with FOSS Android seems to be that your device has to be actually supported due to the myriad of cpu, graphics etc. combinations. I looked shortly for a tablet of mine which is completely workable but hangs at Android 4.2 - unfortunately there doesn't seem to be a CyanogenMod variant for it (so, probably no Lineageos either). The update story of Android devices is really sad ..

The same is true for Ubuntu Phone though, as it uses the same drivers.

GPLv3 would help.

If you're looking for a cheap tablet, the LG G Pad 8.3 v500 is only $120ish and is fully supported by LineageOS

https://www.amazon.com/LG-Tablet-Snapdragon-Android-JellyBea...

https://download.lineageos.org/v500

There are over 150 devices supported, but the vast majority are smartphones

Thanks for the hint, will look into it. My current tablet is an old Huawei (Mediapad T1 10/T1-A21L). It was part of a promo action and does what I want (I mainly use it was PDF reader), but Android 4.2 gets old and security doesn't get better, so maybe time for an upgrade and this time something LineageOS supports.

The chinese mobile phones (and tablets) with the MediaTek chips are cheap and nice, but LinegeOS doesn't support them.

My last 3 mobile phones were MediaTek phones, but that's one of my biggest gripes with them.

This doesn't solve the problem, when asking for an alternative to Android. My issue with Android isn't just Google and privacy, but the fact that Android is pretty notoriously insecure at this point.

I've been carrying Windows but Microsoft just effectively announced end of life for the last two phones on my carrier.

> but the fact that Android is pretty notoriously insecure at this point.

Why do you think that?

Experience, incredible numbers of CVEs, arrogant yet meaningless statements from their security team over time which has convinced me they do not care. Lack of commitment to update distribution.

Heck, Fuchsia is built with a reasonable security model, most work on Android goes into making excuses for theirs.

At least if I'm carrying something obscure the likelihood of being targeted is low.

I don't have the time or desire to do what's required to securely operate on the Android platform.

Have you tried CopperheadOS? https://copperhead.co/android/

Has anyone here had success with Lineage or Cyanogen on a CDMA carrier?

Reply on news.ycombinator.com