What ALIAS does

ALIAS is a support desk built into the product that needs it. A user taps Report a problem, writes a line and sends it. Your product adds what it knows. Your support team answers from the admin page, and the answer appears where the user is.

Reports with their context

Emailing a screenshot loses most of what support needs, and hands over an address the user may not want to share. An ALIAS report carries:

• the user's note, and a reply thread on the same ticket;
• a screenshot taken by your product at that moment;
• context fields you declare per product: text, numbers, yes/no, a place on a map, a link built from other fields (such as "open this level here"), or JSON. Anything a product sends that it didn't declare is dropped;
• telemetry: free JSON up to a size you choose, checked against your JSON Schema if you set one. A report that doesn't match is refused with the reason, so a bad build shows up at once;
• the product's version.

The admin page shows the declared fields as a table, the telemetry's named fields next to them and the rest as raw JSON.

Anonymous, for real

• The service makes the identity: an id and a secret, the first time your product asks. The client never makes either, so a weak random number generator on some platform can't produce guessable secrets.
• Only a hash of each secret is kept. Each device holding the identity has its own secret.
• Ids are per product. The same person using two of your products has two unrelated ids.
• No account. ALIAS never asks for a name, an email address or a login.

Live answers

When support answers or changes a ticket's status, the user's client hears of it straight away over a stream, or on its next poll where streams aren't possible. A ticket waiting on the user, or resolved, opens again when they reply.

Contact, only on purpose

Each product chooses whether users may leave a contact at all. If they do, it's an email address or "something else" (a forum handle, say). It's shown to support as unverified, every look at it is logged, and the user can withdraw it at any time.

Their data, under their control

• Moving to another device: the product shows a short code, valid for 10 minutes, to type in on the other device. Wrong guesses are limited per address and per code, and a code dies after a few wrong tries.
• A copy: everything kept about the id, screenshots included, as one file.
• Erasure: the id, its reports, its screenshots and its contact deleted at once, for good.
• Keeping times per product: resolved reports and quiet ids are deleted on their own.

A privacy text for your product describes exactly this.

One desk for many products

• Products are isolated: keys, users, reports, fields, schemas, limits, keeping times and branding are each product's own.
• The admin page (sign in with your organisation's OpenID Connect provider) shows the queue across every product you may work. Answers are pushed to it live.
• Roles: a product's support role works that product's desk. The instance role also creates and edits products and issues keys.
• Keys are issued on the admin page and shown once. Revoking one takes effect at once.
• Products can be defined in the configuration file, read-only on the page, or made on the page itself.
• Everything is logged: answers, status changes, blocks, erasures, key changes and every view of a contact.