1

I've almost completed a Blender Add-on that allows a user to upload a video to Youtube. It has just come to my attention that embedding your app's credentials from the client_secrets.json file into an open source application violates the Google TOS

Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.

The reason behind this according to an inside source is to prevent impersonating a trusted app by using its credentials.

You are, however, allowing them to “impersonate” you in Google’s eyes. [...] Moreover, you’ve been granted whitelisted access to APIs that are not available to the general public (and, in all likelihood required agreeing to a separate Terms of Service) and are sharing access to anyone who wants it. There is no doubt that is a violation of those terms.

I feel that "APIs that are not available to the general public" isn't quite true since I could make a new account just for this in 3 minutes.

There is an existing python program youtube-upload that is included in pip and it ships with a client_secrets.json. This makes me question how seriously this is enforced.

Looking at some larger OSS projects LibreOffice and OpenShot both ask the user for a username and password to authenticate. While that works for them, no one including myself would trust a small-time application with their login info.

The "official" answer seems to be to require the end user to create a client_secrets.json file themselves. While I think the average Blender user would be capable/tolerant of handling that, how would less technically oriented applications do it?

I'm leaning towards initially prompting for a username and password with the option of using OAuth if they want to create and download a client_secrets.json

Edit

I have continued to research this and was looking into logging in a user with a username and password. That functionality was called ClientLogin and was removed from the Youtube API in 2012. OpenShot's Youtube upload does not work for me when I tried it as it used ClientLogin.

So is there a way to ship an open source application that uses the Youtube API without the need for a user to generate an API key? That seems like an unreasonable step for an average user.

Improve this question
6
  • 1
    Closely related: Open Source Projects with Encryption Keys, but I guess that creating an API key (which requires a request to a third party) is a bit different from creating a cryptographic key (which you can do privately).
    – apsillers ♦
    Commented Oct 8, 2017 at 19:54
  • I'm voting to close this question as off-topic because it is not directly about the Free Software or Open Source movements.
    – curiousdannii
    Commented Oct 8, 2017 at 22:27
  • "Looking at some larger OSS projects LibreOffice and OpenShot both ask the user for a username and password to authenticate. While that works for them, no one including myself would trust a small-time application with their login info." That's why you hand it over to Google directly, through a popup window or the like which shows them they are logging into the official secure Google login system.
    – curiousdannii
    Commented Oct 8, 2017 at 22:28
  • The question is about how to use the Google Login system(OAuth2.0) in an open source application. They specifically say that you cannot include your API credentials in an open source project. So how are you supposed to develop an open source application without forcing the user to generate their own API key?
    – AkBKukU
    Commented Oct 8, 2017 at 23:08
  • 1
    I find the "not about FLOSS" argument fairly flimsy here. This is something that any source-available, modifications-allowed project will encounter when using a credentialed API. Admittedly there are projects that fit that description that fall outside FLOSS, but if we start rejecting questions based on the possibility that they could be applied in a non-FLOSS context, we're going to be aggressively axing a lot of high-value questions to the detriment of the FLOSS community. This is question that has high value for FLOSS projects and happens to have applicability to nearly-FLOSS projects.
    – apsillers ♦
    Commented Oct 9, 2017 at 0:20

2 Answers 2

Reset to default
0

If you don't want to violate Google's terms of service, your options are either to include the key in binary-form only, or not include the key at all.

If you offered your source code without the API, you could possibly offer a built binary version of your application that does include the key. This would not violate Google's terms, but I find it questionable whether you could consider the no-key source code the "corresponding source" for the binary that does include the key. This is significant if you're using anyone else's copyleft code, since recipients will not be able to rebuild the binary application given your no-key source.1 If you use permissive licensed code, there is no issue, since it allows you to keep modified source private anyway.

If you choose not to offer the key in binary format, there are two avenues that do not require you to share key at all:

  • Make each user get their own key.

  • Stand up a private network service that holds your API key and acts as a gateway to the API itself. You could also offer the source code for this network service, and if people want to run their own copy of the service (e..g, to make modifications, or to protect their privacy), I think it's very reasonable to have them get their own API key as part of the setup steps.

    This has the drawback of needing to pay for network infrastructure to run the network service, though there are plenty of VPS providers that will give you a low-power server with high quantity of network traffic for $5 per month or less, and you can use the server for multiple projects at the same time.

1. I leave open the possibility that a court might rule that the inclusion or exclusion of an arbitrary, non-copyrightable authentication string doesn't actually change the copyright-significant potion of a work, for the purposes of copyright law, so a copyright license might not be able to disallow this. Even if that were true, this could be outside the spirit of the GPL, though it seems a borderline case, especially when when considered in the context of an AGPL network service.

Improve this answer
2
  • If I am distributing a binary version of application with the key, is there any reason to not supply the source code with the API calls but not include my key in it? This would leave only users who want to use the source themselves in charge of getting a key.
    – AkBKukU
    Commented Oct 9, 2017 at 21:43
  • @AkBKukU Google says that users can only receive the key (if they must receive it at all) in a compiled binary, so naturally the result of that policy is that users who want the source cannot get the key in the format (whereas users who want the binary may have the key compiled in, under Google's rules). Your end conclusion that "leave only users who want to use the source themselves in charge of getting a key" is correct and inevitable.
    – apsillers ♦
    Commented Oct 10, 2017 at 12:54
3

On my Android phone, I use a piece of free software called forecastie, which gets weather data from Open Weather Map. It ships with a default API key. This is in keeping with that provider's policies, but it also means the app is nearly-broken as it ships: about eight or nine of each ten times when I went to get weather data, I got a "request limit exceeded" error instead. The app made it easy for me to enter my own API key, once I'd worked out I needed one (though it didn't do much to help me get one).

It's perfectly reasonable for YouTube to require an API key, and reasonable for them not to want you to ship a generic set that can be easily extracted from the app. YouTube doesn't allow anonymous uploads of video; they use the API key as part of a programmed exchange to identify the entity behind a request, rather than the piece of software they're using to do it, so all their policies are designed to assist in enforcing that. If that means that your app ships in a state where it can't function until the user has gone through a series of steps designed to create a personal set of API credentials, and populate the user's copy of your app with those, that is a reasonable thing for YouTube to require your app to support.

So there's precedent that other free software apps that need API keys tend to ship with something that is nearly- or completely-nonfunctional. You will need to inform a new user that they need to generate their own API key, and allow them to enter it for storage in their copy of the app. If you're feeling helpful, you might have code that fires up on first execution, walks the user through getting their own API key from YouTube, and embeds it in their copy of the app. If the user chooses not to generate their own key, then it's reasonable that the software not function.

Improve this answer
6
  • I created an OWM account to see what it takes to get an API key. I agree that is reasonable, it's no more difficult than using a gift card online. If you have an account with OWM then you already have an API key. Getting a Google API key is more involved. developers.google.com/youtube/v3/getting-started There is must be a point where it becomes unreasonable to expect an average person to do so much. I don't know where that boundry is but I believe this has crossed it.
    – AkBKukU
    Commented Oct 9, 2017 at 14:38
  • And you're welcome to do so, but the decisions to require a key, and about how one gets a key, are google's calls not yours. The thrust of my answer is that the usual free software response to a user not having an API key that (s)he needs to make a piece of free software work is for the software not to work. If you really wanted to ask "do you all agree that google are not well set-up to handle free software apps uploading to youtube?" then I, too, think this question would have been off-topic.
    – MadHatter ♦
    Commented Oct 9, 2017 at 14:42
  • I was expecting answers more along the lines of "You can put in API key in pre-complied OSS", "Have a server that provides a user with an API key when they use it.", or "Encrypt/obfuscate the key so it cannot be use in other applications." It hadn't occurred to me the the answer would be to ship an initially non-functional application.
    – AkBKukU
    Commented Oct 9, 2017 at 15:10
  • You can't do a, because it's not OSS if you don't ship source capable of creating the same binary. b doesn't violate their TOS afaict, but now your app doesn't work unless your keyserver is up - and how will your keyserver validate that it's a copy of your app that's asking for the gAPI key, given that it's easy to make a modified copy of your app that dumps out the key. c won't work in open source. I thought it best to give an example, but it really is sometimes the done thing: the client won't work until the user gets the credentials to empower it. All free email clients ship that way!
    – MadHatter ♦
    Commented Oct 9, 2017 at 15:32
  • MadHatter, The point that "anyone can modify your application to get a copy of the key" is a really good point that I think you should include in your answer! / @AkBKukU This is ultimately a kind of arbitrary rule, because it's just an arbitrary safeguard against abuse, not a perfect solution -- anyone with a debugger can get the API key out of your binary application, too. Google doesn't want to completely disallow shipping an API key in all forms, so they went for the low-hanging fruit and disallowed it in source form.
    – apsillers ♦
    Commented Oct 9, 2017 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.