How IndoImage handles browser security
This page explains the controls running today and separates them from the planned sharing security model.
Security
Last updated .
This page describes the security model that is live today, and the model that is planned. Nothing here claims an audit, a signed release, or a reproducible build, because none of those exist yet.
What the browser is allowed to do
Every page carries a Content-Security-Policy. It allows scripts and styles from this origin only, plus the Google Tag Manager loader at www.googletagmanager.com, which starts Google Analytics, and the Cloudflare Web Analytics beacon at static.cloudflareinsights.com, which sends page-view counts to cloudflareinsights.com and never sees your image. Images may come from this origin, from a blob or data URL, or from the Google Analytics hosts. Network connections are limited to this origin and the Google Tag Manager and Google Analytics hosts. Forms may only submit to this origin or to a mailto link, and the base URI and plugins are switched off.
There is no image upload path. The tools read your file locally, draw it on a canvas, and re-encode it in the same tab; the CSP has no host that would accept an image even if a script tried to send one. The only outbound request a tool makes is the anonymous count at /x/export on download, which carries the operation and the referring site and nothing from the image.
How you can check it
Open your browser's developer tools, switch to the Network panel, and run any tool. You will see requests to this origin for the page, the assets, and any preset file, requests to googletagmanager.com for the analytics loader, and, on download, a single request to /x/export. You will not see your image, its file name, or its metadata leaving the page. You can also read the Content-Security-Policy in the page source and confirm the hosts listed above.
The planned sharing model
When sharing launches, the plan is that a random, short-lived share identifier coordinates the connection, and a separate key, generated on your device, proves who may receive the file. The key is designed never to reach our service. After two peers connect, they are planned to authenticate with a challenge derived from the key, and the transport is encrypted. Where a direct connection is impossible, encrypted traffic would pass through a relay that carries bytes without storing the file. These are plans, not features: they are not running today, and this page will describe them as live only when they are.