Hacker News Reader

Comment by distances | Hacker News Reader

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...

View on HN

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.

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.

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.

Reply on news.ycombinator.com