Privacy

What an app signing in with UNET can and cannot learn about a person, what the person sees and controls, and what UNET records about your app.

UNET is built so that signing in tells an app as little as possible. This page lists what an app can learn, what it cannot, and what the person sees and controls.

Value	When	Notes
`sub`	Always	The person's id for your app. See User ids.
`username`	With `profile`	Public, and can change.
`displayName`	With `profile`	Only if the person set one.
`avatarUrl`	With `profile`	Only if they have a picture. May not load for a private account.
`accountCreatedAt`	With `profile`	When the account was created. A signal of trust, nothing more.

That is everything. The SDK gives you these as UnetUser.

What it can never learn

A password, a key or an authenticator code. The person enters them on unet.social, never in your app.
An email address. UNET accounts have none, so there is nothing to ask for and nothing to verify.
Direct messages. No permission exposes them, and they never travel on the realtime stream.
Security settings. Passwords, keys, sessions and two-factor setup are never part of any setting an app can read or change.
Whether two sites know the same person, when your app has a per-site id.

What a REST API permission adds

If your app asks for more than sign-in, each permission is shown to the person with a plain description, and it applies only to what they could do themselves. For example:

Reads act as the signed-in person. Blocks, private accounts they follow, and their content settings apply, exactly as they would in the UNET apps. An app with content:read can see posts from a private account the person follows, because the person can.
Notifications cover likes, replies, mentions and new followers. Direct messages and account or security notices are never included.
Writes are limited to what the permission says: publishing is not editing, liking is not following.

See Permissions and the list of every scope.

What the person sees

On unet.social, before your app gets anything, the person sees:

the name of your app;
whether the app's domain is verified. An app without a verified domain is marked as not verified by UNET, and for such an app the page also names the host the person will be sent back to;
the permissions your app asks for, grouped as what it will be able to see and what it will be able to do, with a plain description of each;
a note that they can take the access back at any time.

UNET's own apps, such as the web version, skip this screen. Third-party apps never do.

What the person controls

They can remove your app at any time in their settings, under connected apps. It takes effect immediately: the tokens stop working and the next refresh fails with SessionExpired.
They can deny the request. Your app gets AccessDenied and nothing else.
Changing the permissions of your app later makes people sign in again to grant the new ones; use prompt: "consent". See Permissions.

What UNET records about your app

For each app and person, UNET keeps that the person signed in to the app, how many times, and when first and last. This is what fills the person's list of connected apps, and your sign-in and activity counts in the console. As the developer, you see counts only (total sign-ins, and people active in the last 30 days), never a list of who signed in.

What this means for you

Ask only for what your app uses. A smaller request is easier to allow, and new apps cannot ask for more than they registered.
Do not collect more than you need. If you need a profile picture, use avatarUrl; do not store it unless you must.
Treat sub as the person's identity and username as a label, and tell your own users how you use what you receive.