God’s Eye View: a globe, AI interaction and honest data boundaries
God’s Eye View security: local key brokerage, public tokens and untrusted scene context
Keep provider secrets, microphone choices, data interpretation and remote access inside deliberate operational boundaries.
What you will learn
- The server holds spending authority
- Voice context is data, not authority
- Remote access changes the threat model
Before you start
- Basic JavaScript and JSON
- Understanding of coordinates and source timestamps
Explain how source records, validation, layer presentation and optional AI interaction differ, using synthetic examples.
Key takeaways
- Short-lived browser credentials do not eliminate broker spending risk.
- Public browser tokens need provider restrictions.
- Scene text and model outputs are not task authorization.
The server holds spending authority
The security guide keeps private provider keys on the server and gives the browser a short-lived voice session credential. That reduces exposure of the long-lived key, but anyone who can use the local broker may still consume its enabled capabilities. Localhost binding is part of the intended operating model.
Google browser keys and Cesium public tokens are deliberately visible to the client. Restrict them at the provider according to their actual purpose; obscuring a browser bundle does not make them secrets. Ignoring a plaintext environment file in Git also does not encrypt the file on disk.
Voice context is data, not authority
The README describes optional voice grounded in scene context and, in some cases, a viewport image. Choose microphone and provider access explicitly and avoid sensitive material in the scene. A model instruction not to invent labels is an intended behavior, not a proof that every interpretation is correct.
Feed text may contain arbitrary names or descriptions. The security guide treats model output as untrusted and limits action tools. A scene annotation must not become permission for unrelated uploads or commands. This series uses synthetic environmental records and performs no identity inference or person tracking.
Remote access changes the threat model
The documented dev/preview server is not a hardened public service. Remote access needs separate authentication, proxy and quota review. The supported launcher refuses its own sharing path; do not work around that guard by blindly publishing a tunnel to the key broker.
Keep attribution and provider terms visible when sharing a demonstration. Public availability does not make every aggregation or inference appropriate. Record uncertainty and avoid using the interface for emergency decisions or presenting its visual estimates as authoritative measurements. No remote sharing or credentials were enabled here.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Keep the learning instance on loopback.
- 2
Review which credentials are intentionally browser-visible.
- 3
Use synthetic scene content and deliberate microphone consent.
- 4
Require separate review for any remote access.
Copy-ready example
{
"securityWorksheet": true,
"loopbackOnly": true,
"privateKeyInBrowser": false,
"publicTokenRestrictionsChecked": false,
"microphoneEnabled": false,
"sceneTextIsAuthority": false,
"remoteTunnelCreated": false
}Frequently asked questions
Does hiding a browser token make it secret?
No. Restrict deliberately public tokens at their providers.
May scene text instruct the assistant to perform unrelated work?
No. It is inspected data, not authority to change the user’s task.
Sources
- God’s Eye View / SECURITY.mdSource checked 2026-09-14
- God’s Eye View / README.mdSource checked 2026-09-14