OISY wallet thread maps custom-domain trust risk

On September 11, 2026, a thread on the Internet Computer Developer Forum raised the question of how DNS control affects OISY and other security-critical frontends. Wallet and dapp developers should review which origin users trust, how that origin is controlled, and what a domain takeover could let an attacker do.

What the thread found

The discussion began with a specific concern: threshold signing can keep private keys out of a central operator’s hands, but users still interact with a browser frontend that builds transactions and holds an authenticated session. If someone can change the JavaScript served from a trusted origin, that code may be able to act with the session’s permissions. Internet Computer security guidance describes this class of risk: a malicious frontend can control a user’s session and assets available through it. Canister control guidance

A later forum reply reports that OISY’s production Internet Identity derivation origin is https://oisy.com, and that its canister URL is configured as an alternative origin. The reply summarizes the consequence as “Same backend accounts, same chain-fusion addresses.” This is the participant’s reading of OISY’s configuration, not an official DFINITY statement about the wallet. Forum thread

That matters because Internet Identity derives a user identity from the frontend origin. Its specification says, “A user has a separate user identity for each client application frontend (i.e., per origin).” The origin is therefore part of the identity users bring to the application. A valid login session proves that calls are authorized by that identity; it does not prove that the JavaScript displaying or constructing those calls is safe. Internet Identity specification

The forum reply also distinguishes canister control from domain control. It states, “There is no consensus, no proposal and no on-chain record saying ‘this domain changed hands’.” A canister may serve certified assets, but that certification checks the response from the canister reached. It does not independently establish that a custom domain’s DNS still points to the intended canister. The IC documentation similarly warns that a developer controlling a registered custom domain can point it at a different application, even one outside ICP. Canister control guidance

Who is affected and why it matters

Wallet teams and any dapp that asks users to authenticate should treat the frontend origin as part of the security design. The concern extends to Chain Fusion applications because a browser session can request actions from canisters, including signature operations, within the permissions granted to that caller. A threshold signer protects key material; it does not by itself protect the interface that asks the signer to act.

Custom domains offer familiar names and a smoother user experience. They also add registrar and DNS accounts to the set of systems that can affect what users load. Native canister URLs reduce that per-app DNS dependency because the hostname includes the canister ID. They still depend on the shared gateway domain and gateway verification, so this is a narrower trust model, not a trust-free one.

Changing the canonical origin has a user impact: because Internet Identity derives identities per origin, users may receive a different principal after a change. Applications that already hold balances or account state under the old principal need a migration plan. The forum discussion raises these risks and asks for DFINITY’s clarification; it does not establish who administers OISY or NNS domains, or set a new official recommendation.

What developers should do now

1. Inventory origins. Record the login origin, any derivationOrigin, alternative origins, and the domain and DNS accounts that control them. Verify that every alternative origin is under your control; the Internet Identity specification warns against allowing third parties to share principals.
2. Choose the canonical origin before launch. For a new security-critical app, assess a native canister URL as the derivation origin. If you choose a custom domain, document who controls its registrar and DNS and include account recovery and access review in your security process.
3. Keep frontend delivery verifiable. Serve browser assets from certified canisters, avoid untrusted external scripts, and set a content security policy. These steps protect asset delivery and reduce third-party code risk, while leaving DNS ownership as a separate consideration.
4. Plan origin changes as identity migrations. Before changing a live app’s derivation origin, identify the principals and assets affected, test account recovery and migration paths, and communicate the change to users. Do not assume that signing in with the same Internet Identity anchor preserves the same app principal.
5. Give users a clear verification path. Publish the expected origin and canister ID, and tell users where to find the native canister URL. For high-value actions, consider a confirmation flow that shows transaction details independently of the page that constructs the transaction.

Treat the domain, frontend code, canister controllers, and transaction confirmation path as separate controls. Reviewing each one makes it easier to see where trust rests and what a compromise could change.