Kizzey staff privacy policy

Last updated: 7 October 2026

This policy is for people who hold a Kizzey staff account. It covers the staff dashboard and what it keeps about you as a staff member. What Kizzey keeps about you as a member is in the Kizzey privacy policy, which still applies to you.

Who is responsible

UnpackedX, the founder of Kizzey, is the controller for everything described here, reachable at cryptdex@protonmail.com. Processing happens on Cloudflare Workers and Cloudflare D1, the same server Kizzey itself runs on.

The short version

• A staff account is always linked to your Kizzey member. If you erase your Kizzey data, the staff account is switched off at once.
• Your password is never stored, only a salted hash of it.
• Your network address is kept in full in one place only: the connection records described under "Your connection", for 90 days. Everywhere else only a salted hash of it is kept.
• Each time you sign in, and about once an hour while you work, the server writes down where your connection comes from: your network address, the place and network Cloudflare reports for it, and your browser. A sign-in to your account that is refused is written down the same way, whoever tried it. The founder sees these records and you see your own. Other staff do not.
• A deeper check that runs in your browser exists and is off unless the founder switches it on. It can show the founder your real network address behind a VPN. It is described under "Your connection".
• A sign-in from a new browser has to be approved, from your own Kizzey app or by the founder. While it waits, the country and region it was asked from are kept with it, and the row is deleted one day after it ran out.
• What you do with staff powers is written to an audit log that the founder reads. It is kept for one year.
• The dashboard has a team board that ranks staff by a score worked out from their ticket figures. The founder decides how much of it staff see of each other. A staff member the founder made a team manager sees more about the people who hold no more than they do. Both are described under "The team board and team managers", and neither shows anything about you to another staff member before you agreed to a revision of this policy that contains it.
• Nothing here is sold, shared with advertisers or used for analytics.

Your account

• Username, display name, role, title and tag. Set by the founder. The title and tag are shown in Kizzey Chat next to your messages, so members can see that you are staff.
• Your permissions. Which staff tools you may use, either from your role or set for you by hand.
• Roles you made. If you hold Manage roles, every role you make keeps which staff account made it, for as long as the role exists. The founder sees it in his list of roles.
• Your Kizzey member. The install ID of the Kizzey account your staff account is linked to. It is how your name and picture are shown, how the approval of a sign-in reaches your phone, and why the account ends when your Kizzey data is erased. If the founder links the account to another Kizzey member, or unlinks it, its sessions, waiting sign-ins and trusted browsers end at once.
• Your personal sign-in address. A handle chosen by the founder, and a random public ID that is part of the addresses your dashboard calls. Neither is a secret and neither signs anybody in.
• Your password. Stored only as a salted PBKDF2 hash with 100,000 rounds. Kept with it: when it was set, whether it is a temporary one, how many wrong tries there were recently and until when the account is locked after too many.
• Notes and choices. A short note the founder may keep on the account, and which kinds of notification you switched off.
• Dates. When the account was made, when it was last changed and when you last signed in.
• Asking for an account. If you asked for an account on the sign-in page: the name and note you typed and a salted hash of your network address, kept until the founder answers and for 90 days after.

Signing in

• Sessions. For each sign-in: a hash of the session token (never the token), when it started, when it was last used, when it ends, a salted hash of your network address, the name your browser sends about itself, which trusted browser it belongs to and a count of calls made with an address that was not its own. A session ends after 12 hours, or after 4 hours without use, and its row is deleted then.
• Trusted browsers. For each browser you approved: a hash of a random secret kept in a cookie, a short label such as "Chrome on Windows", when it was approved, when it was last used, whether you or the founder approved it, and a salted hash of the network address. A browser stays trusted for 60 days. A trusted browser is recognised by its cookie alone and not by your network: from that browser you sign in with your password only, wherever you are. You can forget a browser on your profile page at any time, the founder can too, and a password reset, switching your account off or linking it to another Kizzey member forgets all of them.
• Sign-ins waiting for approval. The six digit code, the browser label, a salted hash of the network the request came from, the country and (when it is known) the region the request came from as Cloudflare reports them, and how it was answered. This row never holds a city, a postcode, coordinates or the address itself. The connection record written for the same sign-in is described under "Your connection". Deleted one day after it ran out, and at once when you sign out everywhere, when your password is changed or reset, when the account is switched off or when it is linked to another member.
• What the approver is shown. The browser's family and its platform, which are the two halves of the label, such as Chrome and Windows, the country and region, and when the sign-in was asked for. You see them in your Kizzey app when you approve a sign-in, next to the box for the code, so you can tell your own sign-in from somebody else's. The founder sees the same in his list of waiting sign-ins, with the code.
• Your phone. When a new browser asks to sign in, your linked Kizzey app gets a notification that says a sign-in is waiting. It never carries the code or your password. The app keeps nothing about a sign-in: it asks the server for the waiting list while the approval screen is open, and the code you type is sent once and then forgotten. When Kizzey Chat's settings are opened, the app asks the server whether the Kizzey account is linked to a staff account, as it does for every member.
• Wrong sign-ins. A wrong password on your account is written to the audit log under your username. Five wrong passwords lock the account for 15 minutes. Where a refused sign-in came from is kept as a connection record, described under "Your connection".
• Cookies. Three, all strictly needed for signing in: the session, the trusted browser and a sign-in that is waiting. No other cookie is set and nothing tracks you across sites.

Your connection

A staff account can act on members and their data, so Kizzey keeps a record of where each staff sign-in and session comes from. It is used to protect your account and Kizzey's members: to notice a sign-in that is not yours, a stolen session or a shared account. It is not used to measure your work, for advertising or for analytics.

• What is recorded. Your network address in full (IPv4 or IPv6), and what Cloudflare, the company that runs Kizzey's server, reports about that address on the request itself: the country, the region, the city, the time zone, the number and name of the network it belongs to (for example your internet provider) and the Cloudflare location that answered. Also the HTTP and TLS version of the connection, and your browser as two plain words, its family and its platform, such as Chrome and Windows. With each record: your account, a short public reference to the session, the time and what kind of moment it was.
• What is not recorded. No coordinates, no postcode and not the full text your browser sends about itself. Nothing is looked up at any other company: every value comes with the request, from Cloudflare.
• When. Each time your password is accepted on the sign-in page, whether the browser is trusted or has to be approved. When a browser that was approved comes back and its session starts. Then at most once an hour while a session is in use, and at once when its network address or its network changes.
• Refused sign-ins. A sign-in to your account that is not let in is recorded in the same way, with the reason: the password was wrong, the account was locked, the sign-in was not approved, or it was approved and the browser that came back for it was at another address or too late. Once your account is switched off nothing more is recorded under it: the audit log only notes that somebody tried it, with a salted hash of the address. This is how the founder, and you, can see who tries your account and from where. It is recorded whoever made the attempt, so it also holds the address of somebody who is not you. One account takes at most 200 of these records a day. An attempt on a name that no staff account has leaves no connection record and the name is stored nowhere: it is only counted for the address it came from, for a quarter of an hour, and the audit log gets one line that an unknown name was tried, with a salted hash of that address.
• Never from your phone. Nothing here is collected from the Kizzey app. Approving a sign-in on your phone leaves no connection record of the phone, and nothing like this is recorded about members.
• Marks. The server compares a new record with your earlier ones and marks a country, a network or a browser that is not in the records it still holds about you. It marks a connection that Cloudflare reports as Tor. It also marks a network whose name looks like a hosting or VPN company. That last mark comes from a short list of names and is a guess. A refused sign-in is compared only with the places you were let in from, so somebody else's failed attempt never makes their country look like yours. For refused sign-ins the founder also sees them grouped by address, with how many there were, and whether the same address was refused on other staff accounts.
• The deep network check. The founder can switch on a deeper check. It is off unless the founder turns it on, your profile page shows you whether it is on, and it runs only after you agreed to a revision of this policy that describes it. While it is on, your dashboard runs a short test in your browser, at most once an hour for each session, and sends the result to the server. The result holds: the public network addresses your browser shows to a WebRTC STUN server, the address it reaches the internet with over IPv4 and over IPv6, with the country and Cloudflare location of each, your time zone and its offset, your browser's languages, your screen size and your platform. If WebRTC is switched off in your browser, that part of the result says so and holds no address.
• What the deep check can reveal. WebRTC can go around a VPN or a proxy. If you use one, this test can show the founder your real network address, the one your VPN is meant to hide. That is the reason it is off by default and the reason it is written here in plain words.
• Who the deep check contacts. Your browser contacts Cloudflare, the company that already runs Kizzey's server, and nobody else: its public STUN server at stun.cloudflare.com, and its trace pages at the addresses 1.0.0.1 and 2606:4700:4700::1111. Each of them sees your network address, as every server you contact does. With the deep check off, your dashboard contacts none of them.
• Who sees these records. The founder, for every staff account. You, for your own account: your profile page has a card named "What is recorded about my connection" with your latest records, exactly as they are stored, the refused sign-ins to your account among them. No other staff member sees them, whatever role or permission they hold, and the founder's view of the dashboard as you does not show them either.
• How long. 90 days, then the record is deleted. All of them are deleted at once when the founder deletes your account, when you erase your Kizzey data, or when you ask the founder to remove them.

Counters for the limits

• Sign-in and role counters. How many sign-ins were tried against your account and from one network, how many role changes a holder of Manage roles made (the limit is 20 a minute and 300 a day), how often an app asked about waiting sign-ins, and how often your dashboard sent a deep check result (the limit is 6 an hour). Numbers under a key, never the address itself, deleted after one day.
• Work counters. How many chat messages, edits, time entries and escalations you made in the current minute, hour or day, for limits such as 12 messages a minute, 60 time entries a day and 20 escalations an hour. Numbers only, deleted after 2 days.

The audit log

• Every change you make with a staff tool is written down: the time, your account, the tool and route used, what it was done to (for example a ticket, or the member acted on), a few plain fields such as the new state, and a salted hash of your network address.
• Also written down: signing in and out, refused sign-ins, password changes, the opening of a ticket attachment, agreeing to this policy, role changes, a call made with another session's address, and what the founder changes on your account, including linking it to another member.
• What you read is not logged, except ticket attachments. Messages you send in the staff chat are not logged here either, because the chat keeps them itself.
• The founder reads the audit log. Other staff do not, with one exception: a team manager reads some of the lines of the people they may look at, as described under "The team board and team managers". Lines are deleted after one year.

Notifications

• Notices for you are kept for 30 days, with whether you have read them: a new ticket, a reply on a ticket you claimed, an escalation, news about a ticket you escalated, a mention in the staff chat, a change to your role, an approved or refused sign-in, a change to who sees the team board.
• A notice about a ticket or a mention says who did what to which ticket or in which room: a name, a ticket number, a room name. It never carries the reason of an escalation, a note or the words of a message.
• You can switch off the kinds that are not about the safety of your account or about what other people see of you.

Tickets

• When you claim a ticket, reply to it or write an internal note, your display name, picture address and tags as shown at that moment are kept with that line of the ticket. The person who opened the ticket sees your replies with that name. Internal notes are seen only by staff.
• When you escalate a ticket: the reason you typed, the time, and your name, picture address and tags at that moment. The person who opened the ticket is told only that it was passed to a senior member of the team.
• What you write for other staff about a ticket (internal notes, time entries, the reason of an escalation) and the figures about your work are not part of the copy of their data that the member who opened the ticket can ask for.
• A ticket and everything in it is deleted 180 days after it is closed, or earlier when the member who opened it erases their data.

KPIs and time on tickets

• For each ticket you worked on, worked out from the ticket's own timeline: when you claimed it, when you first answered, when you marked it sorted, how long you held it, and the moments of your replies and notes. Times only, never the words.
• Minutes and a short note that you enter by hand as time spent on a ticket. You can change or delete your own entries.
• You see your own figures. People holding the team KPI permission and the founder see everybody's. A team manager sees the figures of the people they may look at. What all other staff can see of your work is the team board, described in the next section.
• These are kept only as long as the ticket itself. No long term history of figures is kept: a report is worked out on request from tickets that still exist.

The team board and team managers

• The board. The dashboard has a board that ranks staff by a score out of 100 for a period, such as the last 30 days. The score is worked out from the ticket figures above and from nothing else: the tickets you sorted against the person who sorted the most, the share of your first answers and the share of your sorted tickets that were inside the founder's targets, the share of your sorted tickets that were not reopened, and the share of your tickets that you did not escalate. Each share is pulled toward the team's own share, as if you had five more tickets at the team's rate, and somebody with fewer than three tickets in the period is not ranked. Time held, time logged and the number of replies are not part of the score. The board itself shows the exact formula. No score is stored: it is worked out when the board is opened. The founder is not on the board.
• What other staff see of it. You always see your own row with your own figures. The founder chooses one of three settings: every staff member sees the top three and their own row, everybody sees the whole table, or everybody sees only their own row. What a colleague sees of your row is your name, picture and role, your place, your score and the five parts of it as shares. Never your figures themselves, such as how many tickets or how long. Every staff member gets a notice whenever the founder changes this setting.
• Team managers. The founder can give a staff member the permission "Manage the team". It is given by hand to one person at a time, it is in no ready-made role, and a holder of Manage roles cannot pass it on. A team manager sees, of the people they may look at: their figures over time, how much they did on each day, a readable list of what they did made from the audit log (for example "Claimed a ticket", "Replied to a ticket", "Suspended or banned a member", "Signed in"), and those audit lines with the time, the tool used, what it was done to and a few plain fields such as the new state of a ticket.
• What a team manager never sees. Your connection records. The salted hash of your network address and your username in an audit line. Anything typed, such as the reason of an escalation or of a suspension. What the founder did to your account. Anything about the founder. A member that an audit line names is shown to a team manager as the same stand-in ID they see everywhere else.
• Whom a team manager may look at. Only people who hold no permission that the manager does not hold. Somebody with more permissions than the manager is closed to them.
• Not before you agreed. Nothing in this section is shown about you to another staff member before a revision of this policy that contains this section is published and you agreed to it. The founder, and people holding the team KPI permission, see your figures as described above either way.

The staff chat

• Messages. What you write in the staff chat: the text, the room, the time, the message you replied to, who you mentioned and when you edited it. Everybody who can see the room reads them, and so does the founder.
• How long. Messages are deleted after 90 days. The founder can set that between 7 and 365 days. Deleting a message removes its words at once and leaves a marker that a message was deleted, by whom and when, until that time is over.
• Read markers. Per room, the last message you have seen. Shown to nobody else.
• Presence. One row with the last moment your dashboard was open and the last moment it was in front. It is overwritten each time, no history of your online times is kept, and it is written only while the dashboard is open. All staff see whether you are active, away or offline.

What other people see about you

• Members of Kizzey. Your staff tag and title on your chat messages. Anybody can open the tag to see your role card: the tag, the title and the plain list of what your role may do, for example "Moderate chat" or "Manage tickets". Your name and picture there are the ones of your own Kizzey profile. Your username, your permissions in detail and the rest of your staff account are not shown to them.
• Other staff. Your name, picture, role, title, tag, the plain list of what you may do, your handle, your presence, your messages in rooms they can see, and your name on tickets. Also your place and score on the team board, as far as the founder's setting shows it. A team manager sees more, as described under "The team board and team managers". Never your connection records.
• The founder. Everything in this policy. The founder can also view the dashboard as you would see it, without being able to act as you.

What staff see about members

• Staff tools show you members' data only as far as your permissions go. Install IDs are replaced by stand-ins that work only inside your own account. Two tools still show the first 8 characters of a real install ID: the moderation log and the list of stories.
• With "See the room" or "See members" you see members' Kizzey names, Discord names and Discord user ids, and with "See members" also their phone's maker and model, language and app version.
• What you learn about members there is for doing the staff work and for nothing else.

How long, in one place

• Sessions: until they end, 12 hours at most.
• Trusted browsers: 60 days, or until forgotten.
• Sign-ins waiting for approval, with their country and region: one day after they ran out.
• Connection records, with your network address and the results of the deep check: 90 days.
• Sign-in and role counters: one day. Work counters: 2 days.
• Notifications: 30 days.
• Staff chat messages: 90 days unless the founder set another time.
• Ticket lines, time entries, figures and escalations: as long as the ticket, which is 180 days after it is closed.
• The audit log: one year.
• Which account made a role: as long as the role exists.
• The account itself, and the record of which revision of this policy you agreed to and when: until the founder deletes the account. A switched-off account has no end date of its own, and its presence row and read markers stay with it.

If you erase your Kizzey data, or leave

• Erasing your Kizzey data, from any phone of your account, switches the staff account off, unlinks it from your member, and removes its sessions, trusted browsers, waiting sign-ins and connection records at once. The founder is told that this happened.
• The account, your lines in tickets, your staff chat messages, your time entries and the audit log are not removed by that. They stay until their own time above is over, because they are the record of work done with staff powers.
• When the founder switches your account off, its sessions, trusted browsers and waiting sign-ins end at once, no tool opens for it any more, and within a few seconds the server stops putting your staff tag on your Kizzey Chat messages. The account and what it did stay.
• When the founder deletes your account, the account goes with its sessions, trusted browsers, waiting sign-ins, notifications, connection records, its record of the policy revisions you agreed to, its presence row and its read markers, all at once. One line stays in the audit log. It names the account and says how many of each were removed. Your staff chat messages and time entries stay until their own time above is over, without a name.
• On request the founder removes your staff chat messages, time entries, read markers, presence and connection records at once, and deletes the account with its notifications and its record of the policy revisions you agreed to. Your name in ticket lines and in the audit log goes when those run out.
• Nothing of your staff role is ever written into your Kizzey Chat profile, so nothing has to be taken out of it. A chat role or a chat tag that the founder gave your member by hand in Kizzey Chat is part of your Kizzey profile and is not changed by any of this.

Your choices

• You can download what the staff chat and KPI side holds about you from your profile page. The export of your Kizzey data, asked for from any phone of your account, also lists your staff account, its trusted browsers, the policy revisions you agreed to and your connection records.
• You can read your latest connection records, and whether the deep network check is on, on your profile page.
• You can forget a trusted browser, sign out everywhere and change your password yourself.
• For access, correction, erasure or any question, write to the founder at the address above.

Agreeing and changes

• You are asked to agree to this policy after you set your own password, and again when it changes. Which revision you agreed to, when, and a salted hash of your network address are kept with your account.
• Every earlier version stays readable.

Back to the sign-in