How to protect Gemini API key?

[dselman]

Description of the bug:

Gemini API key is compiled into the frontend code. What is the best practice for secure management of Gemini API keys?

Actual vs expected behavior:

Some mechanism to prevent disclosure of Gemini API keys to web browser.

Any other information you'd like to share?

Same question, here: pipecat-ai/gemini-multimodal-live-demo#9

[hapticdata]

You can easily proxy a websocket connection from your own web server. We will have more examples of this soon.
How you accomplish this is based on your own server, if it is a node.js a package such as http-proxy should make it simple. If it is python you can should take a look at the google docs as there is an official SDK implementation.

[dselman]

Yes, a node example of this would be a great addition.

[saliksik]

Any updates on this?

[hapticdata]

We now have an example of using a python server for the websocket communication and protected the API key

https://github.com/GoogleCloudPlatform/generative-ai/tree/main/gemini/sample-apps/e2e-gen-ai-app-starter-pack/app/patterns/multimodal_live_agent

this example integrates in this boilerplate as a frontend.

[vishnukool]

above link is broken

[AspireOne]

The primary solution is a web proxy, as has been mentioned above. Another - simpler - potential solution, if bring-your-own-key is sufficient (e.g. Open WebUI type app), is to skip saving the api key to .env completely, and instead prompt the user to input their own API key before proceeding to the page, and save it in localStorage. Example here (App.tsx), since in that case it's a pet project for a few people, the requirements are still met.

[vishnukool]

The first option you recommend is NOT a good long term solution. You don't wanna be proxying and adding latency for ALL frontend use cases where it matters.

The second option is just dumb, I'm surprised you're even mentioning it as an option. For most actual projects normal users don't just have API keys lying around to paste.
I hope Google can catch up with open AI on this and just do webRtc with ephemeral tokens

[AspireOne]

@vishnukool you misunderstood both.

Firstly, the first option is just the sdk running on the backend and streaming the api's response to the client. That is the standard configuration. Just like the existing Python SDK, just like openai, just like everything. It ALWAYS goes through the backend and THEN to the frontend.

Secondly, the second solution is not "dumb" or "smart", it either meets your requirements or it doesn't. There are MANY bring-your-own-key apps, especially in the open source space. I wasn't saying it's a genius level solution, I was merely mentioning it.

I'm just a random guy that stumbled upon this repo and added his two cents to the public discussion, I'm not saying my answer was definitive in any way.

[vishnukool]

I fully understand both options and have the burden of implementing option 1. The fact that it's an option or that that's the only default supported by Google doesn't make it a "good" option for frontend use cases.

If they supported webRTC as they should be, it would no longer be the recommended option.