Make targetUrl configurable via environment variable

[serjs]

Link to code: BrowserManager.js#L44

Description

Currently, the targetUrl value is hardcoded in the application. This approach introduces potential security risks: if the hardcoded AI Studio App URL is ever compromised, user data could be exposed or misused.

Proposal

Allow targetUrl to be set via an environment variable. This would enable developers and operators to:

• Point the application to their own trusted instance.
• Avoid reliance on a single hardcoded URL.
• Reduce the risk of data exposure in case the default target becomes unsafe.
  Example Implementation
  const targetUrl = process.env.TARGET_URL || "https://default-url.example.com";

Benefits

• Increased flexibility for deployments.
• Improved security posture by removing dependency on a hardcoded external URL.
• Easier integration with different environments (development, staging, production).

Would you like me to also add a “Security Considerations” section to emphasize why this change is important for compliance and best practices?

[bbbugg]

Thanks for the suggestion and for raising the security perspective.

Right now, targetUrl points to Google’s official AI Studio domain/page, and our app is configured and built within that official page. In general, the URL itself is not sensitive; the actual access and data protection rely on Google authentication and project/account permission controls. Also, the app behind this URL does not contain/store any user private data, nor does the URL embed sensitive user information—it simply allows Gemini to be called as the currently signed-in Google user when they open it. So the statement “if the hardcoded URL is leaked then user data could be exposed” is not entirely accurate.

The main reason we keep targetUrl hardcoded today is version consistency and user experience. We will continue to update the browser-side AI Studio app behavior/content over time. If we make targetUrl configurable and encourage users to point it to self-hosted/self-deployed instances, every update would require users to manually keep their deployment in sync. If they forget, we can easily end up with server vs. browser-app version mismatches, causing breakages, compatibility issues, and hard-to-debug failures—while also increasing operational and support burden.

Therefore, we currently keep it developer-maintained and pinned to the officially maintained address to stay “works out of the box” and ensure the server and the browser-side app remain aligned.

(If there’s a strong need later, we can consider an optional override as an advanced setting, while keeping the official URL as the default and documenting that custom URLs require users to maintain version parity and compatibility themselves.)