libspotify の利用規約には、鍵を安全な方法で保管する必要があると記載されています。私が見つけた唯一の推奨事項は、アプリケーションをコンパイルしてバイナリを配布することです。キーはデバッガーを使用して簡単に取得できるため、これをあいまいさによるセキュリティ以外のものと見なすのに苦労しています。
これは本当に Spotify が提案するアプローチですか? キーを含むファイルのみをコンパイルし、残りのアプリケーションをオープン ソースとして配布するとどうなりますか?
私の質問の本質はこれだと思います: すべてのユーザーが独自のキーを取得する必要なく、ToS の違反を回避するにはどうすればよいですか?
ロジックは次のとおりです (私は Spotify で働いています): API キーをバイナリに入れるためだけに開発者に一連のフープをジャンプするように要求することは、それだけの価値はありません。開発者はそれによってオフになり、誰もが不幸。
ただし、キーが広まることは望ましくありません。なぜなら、誰もが 1 つのキーを使用している場合、確実に追跡できず、そのキーが悪意のあるものに使用されてしまい、それを殺した場合、多くのアプリケーションが突然壊れる。
ひどい車の例えを強制するために、API キーが何らかの価値のあるアイテムであり、アプリケーションが車であると想像してください。アイテムを車の座席に置いたままにしておく (つまり、API キーを平文のままにしておく) と、事実上、誰かが侵入して盗むように誘っていることになります (つまり、自分のアプリでキーを使用する)。グローブ ボックスに入れたり (バイナリにコンパイルしたり)、アイテムがグローブ ボックスにあることを知って誰かが車に侵入したり (アプリを逆アセンブルしたり) した場合、いずれにせよほとんどゲーム オーバーです。
要するに、キーをコンパイルすることは、あいまいさによる絶対的なセキュリティですが、他のアプリケーションの API キーを私たちから直接取得するのがかなり簡単な場合に、他のアプリケーションの API キーを何気なく再利用することを思いとどまらせるには十分だと感じています。
私の質問の本質はこれだと思います: すべてのユーザーが独自のキーを取得する必要なく、ToS の違反を回避するにはどうすればよいですか?
アプリケーションをバイナリ形式で配布する場合は、コンパイルしても問題ありません。ソース形式で配布する場合、キーを実際に含めることはできません。