Identity help and privacy

How this browser protects your keys

Private identity material is encrypted in this browser’s local storage. A supported passkey can protect the local encryption key; otherwise setup asks for a strong, unique passphrase. The passphrase is separate from your 24 recovery words. We cannot reset either for you. Signing and decryption happen locally after unlock. Browser storage protection does not mean your signing keys are non-extractable hardware keys: a compromised browser or device can put unlocked material at risk.

What an approval gives an application

A temporary product session shares a signed proof and public identifier for the stated service. A device authorisation grants the displayed permissions to that application’s device key and can deliver encrypted content keys. Encrypted-settings approval lets the requesting application receive the specified settings, without receiving your root or content keys. Read the destination, permissions and expiry each time; these are different kinds of approval.

Your devices lists recorded device authorisations, not all sessions or every copy of your root identity. Removing a product device blocks its future authorised access but cannot erase content or keys it already downloaded.

Pairing another browser

Product device authorisation gives a browser limited access without your recovery words. Portal recovery pairing is different: where the existing browser still offers it, encrypted recovery material is transferred so the receiving browser can control your identity. Only use browsers you control, keep the full invitation private and compare the fingerprints before approving. Some accounts no longer offer this transfer. Use your current recovery words if it is unavailable or fails after a key change.

Recovery words and older accounts

Keep a private offline copy of your current 24 recovery words. Anyone who has them may be able to recover and use your identity. Google or Microsoft sign-in verifies an account during setup; it does not recover your cryptographic keys. Enter recovery words only in a recovery flow you opened yourself, never in a support message.

Restore checks the current identity and signed recovery records before saving a locally encrypted identity. Current words can recover encrypted content and saved settings when the required recovery records and content-key history are available. We cannot recover lost historical keys or recreate content that was never saved. Older accounts may need to enable word-list recovery under Key changes from a browser that still holds their keys. Keep that browser and its storage until setup and recovery checks succeed.

Restoring does not revoke another browser, change your root key or erase anyone’s copies. If a root-key change has taken effect, use its replacement words; retired words are refused. Clearing browser storage also removes local checks against an older server history. A fresh browser cannot by itself prove that a hostile service has shown the latest complete history.

Browser features and the desktop pilot

Root-key rotation controls are currently disabled. The Key changes page can still show recorded changes and offer available stop actions. Enabling word-list recovery for content is a separate action and does not enable root-key rotation. Do not treat restore as a way to invalidate a stolen root key.

The separate maatara One 0.1.2 signed Windows pilot supports configured browser sign-in and tray operation. It requires an operator-provided client registration. Its signed installer does not establish hardware-backed identity signing or general production readiness. Automatic organisation setup, device anchoring and file watching are not available in that pilot. Installing this website as a browser app does not install the Windows client.

What leaves this browser

The service receives public identity evidence, signatures, authorisation records and encrypted data needed for the action you request. Identity and device records can reveal public identifiers, application origins and activity timing. They are not anonymous. Google or Microsoft setup sign-in lets the authentication service process your account address; the Portal receives a keyed lookup value and a redacted display value. Private keys and plaintext recovery words are not sent to that service. Recovery pairing relays encrypted recovery material as described above.

Limited usage analytics go to RME Insights at events.rmesolutions.com.au. The browser sends allowed event names, broad page categories, device-size and referral categories, and a random session identifier stored in sessionStorage. Events include page views, engagement, scroll depth, setup outcomes and generic error events. The analytics payload excludes recovery words, keys, identity identifiers, form contents, full page URLs and error messages. The collector still receives network requests; this is not a promise of anonymity. Analytics respect Global Privacy Control and Do Not Track signals.

See the privacy policy for wider service handling. This page explains the Portal’s current user-facing behaviour.