Can Hologram leak data

Short answer: Hologram won’t “leak” data across users, but anything you send to the browser for the current user is visible to that user (e.g., via DevTools). Think of it like a REST response: only send what the current user is allowed to see.

What gets compiled to JavaScript

• Compiled to the page bundle: functions reachable from page/component template/0 and action/3, plus component init/2 (see also: Hologram Elixir → JS compilation)
• Not compiled to JS: server init/3 (page and component), command/3
• Bundles are generic and public; they don’t contain per-user data.

What data reaches the browser

• Per-user state is serialized into the initial HTML mount payload (for client runtime to start). They are visible to the current user in DevTools.
• Passing a whole struct as a prop is acceptable; it just means all its fields are present client-side for that user. If you want to minimize payload and exposure, pass only the fields you need.

About secrets (same rules as frontend JS frameworks)

• Never hardcode or send global/shared secrets (e.g., service API keys, service account creds, DB creds) in any code compiled to the client: action/3, template/0, helpers they call, or component init/2. As with React/Vue/Svelte, anything hardcoded in client-compiled code ships in the bundle and is visible to anyone.
• Don’t place global/shared secrets into state/props either - mount payloads are visible to the current user.
• Sending sensitive data that the current user is authorized to access is fine if it’s intentional and needed for UX (e.g., account balance, email, or a user‑scoped short‑lived token). Just remember it will be visible to that user in the browser.

OK (user-authorized data in server init/3, visible only to that user in the mount payload):

def init(_params, component, _server) do
  put_state(component, :account_balance_cents, 123_45)
end

OK (user-scoped, least‑privilege token if truly needed client-side):

def init(_params, component, _server) do
  put_state(component, :photo_upload_token, issue_user_scoped_token())
end

Not OK (global/shared secret compiled to the public bundle):

def action(:my_action, _params, component) do
  put_state(component, :api_key, "my_global_service_key")
end

TL;DR

• Bundles are public and generic; per-user data isn’t stored there.
• Per-user data is in the HTML mount payload and visible to the current user.
• Only send data the current user should see (same mindset as a REST response).
• Same as frontend JS frameworks: never hardcode or send global/shared secrets to the client; user-authorized sensitive data can be sent intentionally, knowing it will be visible client-side.

Glad to hear the actions/commands model clicks!

If your bundle contains malicious 3rd party js then your user’s privacy is compromised anyway.

Thank you so much for the detailed response.
I am sorry I used so much of your time for this.

I get what you explain. Thank you so much.

As far as I understand there is quite a big difference compared to liveview.

Let’s say I have a user that has some attribute that should not be visible for the user, let’s say “is_blocked”. In liveview I can safely pass the entire user struct to a component and all I need to do is make sure that I don’t actually put {@user.is_blocked} in the template. Pretty easy.

However, if I understand correctly, in hologram I would be able to get to this info through Dev tools if I pass the entire struct so I would have to be careful to only pass the args that are supposed to be visible to the user.

Did I understand this correctly? If so, that is quite a big difference.

No worries at all! These kinds of questions are really valuable to the community - I’m sure other developers moving from server-side frameworks to Hologram have similar security concerns. Understanding the client-side data flow is crucial, so I’m glad we could clear that up.

You get a very simple action/command programming model with zero latency, but you need to account for actions/templates living client-side. So use:

• Actions & templates for data that’s public to the user (gets zero latency interactions)
• Commands for operations that should be private and when you need security (executed on the server)

For example, if a bank is processing a credit score using trade secrets, internal algorithms, and user data that should only be visible to the bank, you’d use a command that calls your Phoenix context or some service and returns the data for the template (like the final score or approval status). Actions and templates are basically your view layer that lives in the user’s browser.

The action/command model gives you a clean separation that works nicely in practice, with usage patterns emerging for different cases like server-to-client state updates, and patterns will likely emerge around these client/server data decisions as well.

Looking ahead, I have ideas for additional tooling like a DSL for defining data shapes, and eventually a local-first data layer where user data syncs declaratively and automatically between client and server.

The mindset shift is: “What does this user need to see/interact with?” goes client-side (and gets instant responsiveness), everything else stays server-side.