U-net privacy policy.
This page describes the privacy posture of the U-net app, web login flows, miniapps, verification checks, and partner integrations.
Identity as scoped access, not a reusable trail
The important boundary is between what helps a single interaction work and what would let unrelated services stitch a person together.
U-net is designed around scoped identities, local device keys, attestations, and proof flows so services do not receive more data than a specific interaction requires.
The system may store public profile data, scoped relationship records, attestation metadata, verification session state, encrypted message envelopes, and operational logs needed to run the service.
Partners receive service-scoped IDs and permission state for their relationship. They do not receive private keys, push tokens, unrelated scoped IDs, or global device identity.
Holders can revoke miniapp permissions, notification categories, attestations, connected services, and scoped relationships from the U-net app.
Revocation is part of the model
U-net's posture depends on making relationships inspectable and reversible from the holder's side, not only on minimizing the initial exchange.
Review the relationship
See connected services, permissions, notification categories, and attestations in the U-net app.
Change the scope
Miniapp permissions, notification categories, and proof requests are managed independently.
Disconnect when needed
Revoke connected services and scoped relationships without exposing a global identifier to the partner.