Política de privacidad

1. Who is responsible for what

For the data inside a workspace, meaning launches, objectives, questions, links and everything else members put there, the workspace's organisation is the controller and we are the processor. The Data Processing Addendum covers that relationship.

For account records, billing and the logs we keep to run the service, we are the controller. That is what this policy is about.

Controller: Taktoria LLC, a Delaware limited liability company. Privacy contact: legal@taktoria.com.

2. What we store about people

• •Account: name, email address, and a profile picture if one is uploaded; the language you use Taktoria in, so email reaches you in it; and whether you have unsubscribed from product email. Passwords are stored only as a hash.
• •Two-factor authentication, if enabled: a shared secret and backup codes, so codes can be verified.
• •Sessions: an identifier, the IP address, the browser's user-agent string and how the session was signed in (a password, Google or single sign-on), so a session can be recognised and listed for you to revoke, and so a workspace that requires Google can tell.
• •Google and single sign-on, if you use them: the identifiers Google or your identity provider gives us, and the sign-in tokens it issues.
• •Workspace membership: when you join a workspace, by invitation, through its single sign-on, or automatically because it has verified your email domain and you sign in with a confirmed address there, your name, email address and picture become visible to its members. If an admin removes you, the removal is recorded, with who removed you and when, so that your email domain does not add you back.
• •Billing: the Stripe customer and subscription identifiers, the apps subscribed to, the seats and Dory capacity paid for, monthly or yearly billing, trial dates, and Dory attendance where an event went over its capacity. Invoices are kept by Stripe, not by us, and card numbers are never sent to us. Stripe receives the workspace's name and its owner's email address, and, on the invoice line for a Dory event that went over its capacity, the event's title and attendance.
• •Notifications: the recipient, subject and rendered body of each notification email, and the channel or person and the text of each Slack message, kept so delivery can be traced and a retried message is not sent twice. Sign-in, password reset, verification and invitation emails are sent straight away and not kept.
• •Activity: a log of significant workspace actions, with the person who took them.

3. What we deliberately do not store

• •Card numbers, which stay with Stripe.
• •Who followed a go link. Click counts are totals per link per day, with nobody attached to them.
• •Anything about people who never sign in, beyond what an app is explicitly given and what Google reCAPTCHA is sent when they use a protected form. See event participants below.

4. Event participants

Dory events can be joined without an account. A participant is identified by a random token in a cookie that lasts thirty days, plus a display name if they choose to give one. A question can be asked anonymously, in which case no name is shown with it. The participant record behind it still exists, because upvotes have to be counted once each.

A host can see the questions, the counts, poll answers, when each participant joined and was last seen, and any display names given. For a participant who is signed in, the host can also see their name, email address and picture. An anonymous question is shown without a name. Deleting the event deletes all of it.

A host can limit an event to people at certain email domains. A participant then proves an address at one of them, either by signing in with Google, which tells us that address and the name on the account, or with a six-digit code we email to it. The address is kept against the participant cookie for thirty days, used only to let that browser into events limited this way, and never shown to the host. The name from Google is kept beside it to fill in the name box when that browser joins an event. At an event limited to domains, it is the name the participant joins under, which the host sees beside their questions unless they ask anonymously; anywhere else it is only offered, and they can change or clear it. The code is kept only as a hash, and works for ten minutes.

5. Uploads

Profile pictures, workspace icons and Memegen templates uploaded to a workspace are stored in Cloudflare R2 and served from a public bucket address. Anybody with the URL can fetch the file. The URL contains a random key and changes whenever the picture changes, but it is not a secret. Do not upload anything that should not be publicly readable.

A Memegen template can also come from memegen.link, or from the address of a picture somebody pastes. Those pictures are loaded by members' browsers from where they live, and our server fetches a pasted address to measure the picture. Searching for a template sends the search words to memegen.link.

6. Cookies

All but the Google Analytics and PostHog cookies are necessary for the features they belong to: reCAPTCHA's is what keeps scripts from guessing passwords and event codes. Analytics run for everybody signed in to Taktoria: agreeing to this policy when you create your account, by ticking the box when you sign up or by continuing with Google or single sign-on, includes them. For a visitor who is not signed in they are the one choice, covering both: off until you switch it on in the cookie notice on our public pages, rejecting it is one click, and "Cookie settings" at the foot of those pages changes the answer at any time. Switching it off removes the _ga and ph_ cookies. We do not use advertising cookies.

• •The session cookie, better-auth.session_token, so you stay signed in. It lasts 30 days from when the session was last renewed, which happens once a day while you use Taktoria. Beside it, better-auth.session_data keeps a copy of the session for five minutes so that every page need not look it up. On a secure connection both names start with __Secure-. The workspace you last opened is remembered on the session, not in a cookie of its own.
• •During sign-in only: a cookie holding the state of a Google or single sign-on sign-in until you come back from it, and one marking that a two-step code is still to be entered.
• •A participant cookie for Dory events, dory_participant, lasting thirty days.
• •While proving an email address with Google at a Dory event: a cookie, dory_google, holding the state of that sign-in for ten minutes.
• •A locale cookie, NEXT_LOCALE, remembering the language you picked until the browser is closed.
• •A consent cookie, cc_cookie, remembering what you chose in the cookie notice, lasting six months.
• •Google Analytics cookies, whose names start with _ga and which last up to two years, set while you are signed in, or if you switch analytics on.
• •A PostHog cookie, whose name starts with ph_ and which lasts up to a year, set while you are signed in, or if you switch analytics on.
• •Google reCAPTCHA's cookie, _GRECAPTCHA, which lasts up to six months, set by Google when you open a sign-in page, Dory's join page or a Dory event.
• •In the browser's local storage rather than a cookie: whether you chose the light or dark theme, and PostHog's own record of an analytics visit, under the same conditions as its cookie.
• •When a workspace serves an app on its own hostname, such as events.acme.com, the same cookies are set on that hostname. Signing in there brings your session over from our domain with a one-time token that lasts a minute and is stored only as a hash.

7. Who else processes it

We use the providers listed in the Data Processing Addendum's annex, each for a specific job: hosting, email delivery, file storage, payments, background job delivery, bot protection and page analytics. Slack receives data only from a workspace that has connected it: the notifications it has asked us to post, and, to send somebody a direct message, their email address, which Slack matches to their Slack account.

The analytics are Vercel Web Analytics, and they count page views: the page address, where the request came from, and the country, browser and device type. They set no cookie and keep no identifier that would follow somebody between visits or to another site. The address of a page inside a workspace contains that workspace's name, so the counts can show a workspace is being used and which of its pages are busy, but nothing in them says who opened one. Go links are not counted this way at all: a go link is a redirect and never renders a page.

Vercel Speed Insights sits alongside them and measures how quickly pages load and respond, from the timings the browser already records for itself. It reports the route rather than the address, meaning /app/[workspace]/launchcal rather than the workspace's name, so the performance figures carry no workspace in them at all. It sets no cookie either.

Google Analytics runs for everybody signed in, and for a visitor who switched it on in the cookie notice. It measures visits on every page, the app's included: the page address, which inside a workspace contains the workspace's name, where the visit came from, and the device, browser and approximate location, tied together by the identifier in the _ga cookies so that return visits can be counted. Advertising storage, ad personalisation and advertising use of the data are switched off.

Google reCAPTCHA Enterprise runs, for everybody who uses them, on the sign-in, sign-up, single sign-on, two-step, password reset and invitation pages, and on Dory's join page and event pages, including on a workspace's own hostname. Google's script on the page sees how the page is used, the browser and device, and the IP address. When a form is sent, our servers send Google the token the script made, your IP address and your browser's user-agent, and Google gives back a score for how likely the visitor is to be a person; a form with too low a score is refused. It shows no puzzle. Google provides this to us under the Google Cloud terms, and Google's privacy policy and terms, linked beside each form it protects, also apply.

PostHog runs for the same people and measures the same visits, with the identifier in its ph_ cookie. It also notes what was clicked, such as a button or a link, with the words on it, which inside the app can be a person's name or the title of something in the workspace, but never what is typed into a field, and it records no screens or sessions. It keeps no profile of a person, only of the anonymous visit. When a page breaks, PostHog is also sent the error: from your browser only for those same people, and from our servers for anybody, but then with only the error, the page's route and its address without the query string, and no identifier, cookie or anything else about who was visiting, although an error's message can repeat what caused it, such as an address typed into a form.

8. Where it is processed

Data is processed primarily in the United States. Some providers, such as Vercel's and Cloudflare's networks and Google reCAPTCHA, handle a request wherever they are nearest to it. Where a provider processes data outside the United States, the transfer relies on the Standard Contractual Clauses or another mechanism recognised under applicable law.

9. How long it is kept

Each kind of data is kept for as long as the reason we hold it lasts. Deleting a workspace, which its owner does in Settings → Workspace, removes its data from live systems immediately; deleting your account, on your account page, does the same for your account. Anything deleted from live systems leaves our backups within 30 days.

• •Workspace content, meaning launches, objectives, questions, links, memes, uploads and everything else members put in the apps, with the activity log and sent notifications: for as long as the workspace exists, unless somebody deletes it sooner.
• •Dory events, with their participants, questions, votes and poll answers: until the event or the workspace is deleted.
• •An email address proved at a Dory event: thirty days. A code emailed to prove one: ten minutes.
• •The record that an admin removed somebody: for as long as the workspace exists, since its purpose is to stop their email domain adding them back.
• •Account records: for as long as the account exists. When an account is deleted, what it put in a workspace stays with the workspace, with the author's name taken off.
• •Sessions, with their IP address and user-agent: a session stops working 30 days after it was last renewed, and its record goes when it is next seen after that, when you sign out or revoke it, or when your account is deleted.
• •Links and codes sent to sign in: until used or expired, an hour for a password reset link and a minute for the token that signs you in on a workspace's own hostname.
• •Billing: our copy of a workspace's subscription goes when the workspace does. Stripe keeps the invoices and payments for as long as tax law requires, at least 7 years.
• •The record that a workspace or account was deleted, holding only identifiers and dates, so the clean-up it describes can be shown to have happened: kept.
• •Analytics: for the periods set in Google Analytics and PostHog, which hold that data rather than us.

10. Email from us

Besides the email a feature sends, such as an invitation, a password reset link or a notification, we send people who sign up a short series of tips about the apps they can use, every other day, a welcome email on their first day in a workspace, whether they made it or joined it, and whoever subscribes to an app a confirmation. Tips carry an unsubscribe link, and unsubscribing stops them.

11. Your rights

You can ask for a copy of your personal data, ask us to correct or delete it, or object to our processing of it. Much of it you can change yourself in account settings, where you can also delete your account; for the rest, write to legal@taktoria.com and we will answer within 30 days.

If a workspace holds data about you and you are not its account holder, the workspace's organisation is the controller and the request belongs with them. We will pass it on.

12. Changes

We may change this policy at any time. Changes take effect when they are published here, and the date at the top of this page is when the text last changed.