Privacy policy
These pages set no cookies, run no scripts and load nothing from a third party. Nothing here tracks you. The only personal datum you can give us is the email address you type into the waitlist form, and you have to confirm it before we may use it.
Who is responsible
The controller for the processing described here is BJORN GREIFF, UNIPESSOAL LDA, Rua Actor António Sacramento, N.º 8, 4.º A, 2770-183 Paço de Arcos, Portugal — hello@list-walker.com. Further company details are in the legal notice.
Visiting these pages
When you open a page, our web server records the request in its access log: your IP address, the date and time, the page requested, the response status and size, the referring page and your browser's user-agent string. We need this to deliver the page and to keep the server secure and working. The legal basis is our legitimate interest in the secure and reliable operation of the site, Article 6(1)(f) GDPR. The logs are not merged with anything else and are not used to profile you. Access logs are deleted after 14 days.
These pages set no cookies and use no local storage. They contain no analytics, no tracking pixels, no advertising and no third-party scripts or fonts. Because we set no cookies that would need one, there is no cookie banner.
The beta waitlist
What we process. The email address you enter, and the confirmation that you opted in — the time of your request and of your confirmation, and the IP address those came from. The confirmation record is what proves your consent if you ever ask us to show it.
Why. To tell you when the beta opens, to send you your beta access, and to send occasional updates about the launch. Nothing else. We do not sell, rent or share the list.
Legal basis. Your consent, Article 6(1)(a) GDPR, given by submitting the form and confirming it.
Double opt-in. After you submit the form we send you one email with a confirmation link. If you do not click it, we do not add you to the list and we do not send you anything else.
Who handles it. The list is operated for us by Brevo, an email service provider established in the European Union. Brevo processes the data only on our instructions, as a processor under a data-processing agreement pursuant to Article 28 GDPR, and stores it on servers within the European Union.
Where it does not go. The address you type into the form goes straight to Brevo. It never reaches this application's database.
How long. Until the purpose ends or you unsubscribe, whichever comes first. Every email we send carries a one-click unsubscribe link. When you unsubscribe we stop sending immediately and delete your address, keeping only what we must in order to show that you had consented and that you withdrew it.
Withdrawing. You can withdraw your consent at any time, with effect for the future, by using the unsubscribe link or by writing to the address above. Withdrawing does not affect the lawfulness of what we did before you withdrew.
Your rights
Under the GDPR you have the right to:
- ask what personal data we hold about you and get a copy (Article 15);
- have inaccurate data corrected (Article 16);
- have your data erased (Article 17);
- have processing restricted (Article 18);
- receive your data in a portable form (Article 20);
- object to processing based on our legitimate interest (Article 21);
- withdraw a consent you gave us, at any time (Article 7(3)).
Write to hello@list-walker.com and we will answer.
You also have the right to complain to a data-protection supervisory authority, in particular in the EU member state where you live, where you work, or where you think the infringement happened (Article 77 GDPR).
The competent supervisory authority for the controller is the Comissão Nacional de Proteção de Dados (CNPD), Av. D. Carlos I 134, 1.º, 1200-651 Lisboa, Portugal — www.cnpd.pt.
The signed-in application
This policy covers these public pages only. The List Walker application behind the sign-in screen processes account and list data for named account holders; that processing is governed by the agreement made with them and is not described here.
One thing about the application belongs here anyway, because it names two recipients. Some features send list content to a model so that it can propose, judge or translate. Nothing a model returns is ever written by itself: a proposal is accepted or rejected by a person, a judgment only marks a row, and a translation only proposes filter conditions a person confirms. Everything is sent over TLS.
The language-model provider receives: for a prompt (an instruction an account holder writes, which runs when an answer in a named column changes), that one row’s answers, the list’s column definitions, the names of the project’s contacts and the knowledge items the prompt names; for a person’s notes from a workshop, those notes together with every row of that one list and its current answers, the column definitions, the names and kinds of the project’s contacts and any reference texts the person ticked — the notes are kept with the record of that run and are deleted with it; for a list check run on request, every row of that one list with its answers, the column definitions, the contacts, the check’s instruction and the knowledge items it names, and the bodies of comments (never who wrote them) only where the check includes comments; for filter by sentence, the sentence the person typed and the list’s structure — column and option names, descriptions and the contacts’ names — but no answer from any row.
TypeSafe receives, for a list that carries an active row check or an applied AI filter condition, one row at a time: that row’s answers, the list’s name, description and column definitions, the knowledge items the check names, and the bodies of the row’s comments with the names of the contacts they mention (never who wrote them) only where the check or condition includes comments. It answers with a probability, which is all that is kept.
No other customer’s data, no credentials and no sign-in data are ever sent, and neither recipient’s request or answer is stored beyond the proposal, the probability or the finding it produced. Each recipient is a processor acting on our instructions, and what it keeps is governed by its own terms. Each feature has its own switch: an account holder who does not want it does not use it, and an administrator who does not want it at all leaves that recipient’s credential unset, and then it does not run for anybody.