Raghd Hamzeh (ded8af61) at 12 Jul 05:54

Raghd Hamzeh (20fde514) at 12 Jul 00:54

2. Have a proxy web service (probably the safest solution but costly in terms of maintenance time and money).

This is actually very unsafe, as it would grant the person who controls the proxy access to the user's data. Versus locally, where MellowPlayer the local app has access to the user's data, but the developers it behind do not. It also wouldn't prevent abuse, as a third party can connect to it and use it to access the data instead of calling Last.fm itself.

3. Have a binary distribution of a proxy console application (not that costly but still a lots of hassle for something that is barely safer than first solution)

I'm with you on this one, this is barely safer than 1. Extracting the keys from the binary would be very trivial, and adds a lot of hassle to you, to the maintainers and to the user

====

If I may suggest a further option to consider (a combination of 1 and 2):

Store API key and secret in MellowPlayer default config file/source code, making it the easiest for people to use Have instructions for maintainers on how to replace this (That means if they replace it, that's good. If they don't it will still use what you provided) Allow the user to override the default config with a custom config file

My guess is that storing the key in a default configuration instead of the source code would make it easier for the maintainers because then they can change all the stuff that need changing in one documented place.

Also if you want to take the extra step, make the different releases that you control use different API keys. This is slightly unnecessary as people can still extract them from every build.

As an example this is what Rhythmbox does and here

Hi sorry to jump in.

Including the Last.fm API Key should be pretty safe, but instead of including it in the source code, inject it during build time.

That means that people downloading the app will be able to use it, while people needing to clone from source need to provide their own in the config.

API Keys for desktop/cli apps aren't meant to be private, they can easily be extracted anyway. (You can do so now with Rhythmbox or any of the other local apps that interact with Last.fm or Libre.fm or other online services from Mobile, desktop or html)

API keys mostly meant as indicator for the user where they see the details of the App they are granting access to, and so later on they can access the settings in the Last.fm and deny app 'X'.

It generally falls on the user to at least ensure that the application they're granting access to on Last.fm has the same name, or at least the name of the developer as the app they launched.

that someone could set up a service pretending to be MellowPlayer and convince users to auth with Last.fm, and they could then access, modify, and delete all of the user’s data.

This is true, however they could do the same with any other API key of a popular, not just MellowPlayer or even open source software.

It's a risk, but it's an inherent risk in most offline software that does not have a Backend to verify the user's credentials. And so far, I haven't heard of a case where it is being grossly misused.

if MellowPlayer’s API account was misused, the blame would fall on the project/developers? I don't think there will be much fallout beyond the service revoking the key being abused, in which case MellowPlayer needs to create a new key. I doubt Last.fm will punish MellowPlayer itself because they probably know the risk

(Side note: Maybe want to have a default API key, but allow users to override the API Key at runtime through a conf file or through the GUI, so end users can change it easily?)

Is this all ideal? Probably not, as users are rarely vigilant. But this is common practice, and I don't know of any solution that isn't as inherently flawed.