Palladin Privacy Policy
Polish version: Polityka Prywatności. The Polish version is binding, without limiting mandatory consumer rights.
Pre-launch draft. Requires qualified-counsel review before publication; it has not entered into force.
1. Controller and roles
The controller is Patryk Roguszewski IT Solutions, Patryk Roguszewski’s sole trade registered in Poland’s CEIDG, NIP 8241804773, REGON 366380826, ul. Szkolna 11G/1, 05-091 Ząbki, Poland. Privacy contact: patryk.roguszewski@palladin.io, tel. +48 517 777 441.
For data entrusted by B2B Customers, we act as processor under a DPA; the Customer determines purposes and permissions in its Organization. We remain controller for our own account administration, security, billing and legal duties. The role depends on the purpose, not the Plan name.
This document describes pre-production code and expressly identified plans. Payments, Family, legal-representative approval, complete account deletion and account export are not implemented. The retention periods and supplier arrangements identified below must be finalized before launch; this draft is not a completed privacy notice for an unverified deployment.
2. Data we process
| Category | Scope and visibility |
|---|---|
| Account and sign-in | e-mail, display name, language, identifiers, memberships and permissions; authentication salt and verifier, public keys and wrapped key packages; sessions, devices and security status. Google sign-in also supplies the identifier and profile information authorized for sign-in |
| Vault contents | on-device encryption covers names, descriptions, types, domains, URLs, passwords, API keys, Entry TOTP secrets, notes and other fields. The backend stores ciphertext, not keys capable of decrypting it |
| Structure and audit | Organization, Vault, Entry, Agent and Access identifiers, states, permissions, versions and times; actor and outcome events. Access delivery policy can reveal the Entry category despite encryption of the type |
| Security | IP, client and connection data, pseudonymous e-mail digest, failed-attempt factor and identifier, counters and lockouts; Agent device data. The Palladin account 2FA secret is known to the server, separately from encrypted Entry TOTP secrets |
| Member directory | identifier and last display name of a current or former member, Organization and update time; no e-mail or role in this directory. It attributes historical actions and is available to members of that Organization |
| Waitlist and Benefit | e-mail, language, verification-token hash, entry/verification status and times, and after activation the account identifier and personal Developer Benefit dates |
| Communication | correspondence, address, language, e-mail content and delivery/bounce/complaint status; push token, platform and notification identifiers. Push contains a generic message and opaque identifiers, without Vault or Entry names or secrets |
| Consent | purpose, scope, status, notice version and text, language, interface source, time, revision and request identifier. The consent register exists in code |
Encryption does not exclude GDPR: encrypted information linked to a person remains personal data. Zero-knowledge is a safeguard, not anonymity of the whole account.
The pre-production card Entry includes holder, PAN, expiry and optional billing address. It has no dedicated CVV/CVC or PIN field. Do not place these codes in notes or custom fields. Storing a card in a Vault is separate from paying for Palladin; we do not send those stored card data to our billing provider.
3. Purposes and legal bases
| Purpose | GDPR basis |
|---|---|
| Account, sign-in, encrypted synchronization, sharing, local export, autofill and requested notifications | Article 6(1)(b), contract; for entrusted B2B data, Customer instructions and Article 28 |
| Waitlist, address verification and free Benefit | (b), requested steps and performance of the promise; (f), eligibility and one-time-use evidence and abuse prevention |
| Account protection, logs, historical attribution and delivery reliability | (f), security and accountability; (b) for a user-requested feature |
| Complaints, individual rights, illegal-content duties and evidence of required consents | (c), legal obligation; (b), contract; (f), establishing and defending claims |
| Client analytics after clearance | (a), prior voluntary consent, and Article 399 of Poland’s Electronic Communications Law for device access |
| Backend event measurement after clearance | proposed (f), measuring service and promotion performance; requires balancing, limited retention and effective objection handling |
| Future payments and billing documents | (b), purchase; (c), applicable tax and accounting duties |
| Future Palladin e-mail marketing | separate (a) and Article 398 of Poland’s Electronic Communications Law; refusal does not affect an account or Benefit |
Providing necessary account data or data required for a particular purchase is voluntary, but the relevant action cannot be completed without it. Do not send secrets in correspondence. Waitlist signup and address verification are not marketing consent.
We receive data from you, authorized Organization members and Agents, your chosen sign-in provider, and operation of devices and the service; after billing implementation, also from the Plan seller. B2B Customers provide information on their own purposes and bases for data they supply; we provide agreed assistance with individual rights.
4. Sharing with Agents and websites
Discovery requires separate active Agent authorization for the particular Vault. Enrolling an Agent in an Organization is insufficient. It may include name, description, type, domain and fields marked Agent-visible; the backend stores this projection encrypted. Discovery does not itself grant secret Access.
GRANULAR shares keys for specified Entries. FULL treats the Agent as a trusted member of the entire Vault able to decrypt its data; online limits do not cryptographically isolate data from a Vault-key holder. FULL implementation remains subject to release clearance. Revocation does not remove data or keys already copied.
get may transmit a secret to the user’s chosen AI model provider, exec to a process and inject to a website. A website and its scripts may read values after filling. The unlocked extension fills exact-match HTTPS hosts automatically, without overwriting or submitting; a related host requires a separate choice. These features are pre-production.
Separate flows are outside Entry-domain confidentiality: a public-icon request sends a normalized hostname; the shared form-map catalogue receives domain, login URL, provider and a value-free field definition, together with submitting Agent identifier and time. These support the requested icon feature and form recognition, based on performance of that feature and the legitimate interest in a safe catalogue. Do not put private values into a map definition.
5. Providers and transfers
The recipient list distinguishes code integrations, selected future suppliers and unverified agreements. It includes AWS/SES, Firebase and APNs, PostHog and Netlify. Google may provide sign-in and downloaded fonts in the app panel. The informational website and legal pages serve fonts from their own hosting, without connecting to Google Fonts. Have I Been Pwned password checking directly sends a five-character SHA-1 prefix and connection data including IP, never the full password or full hash. We do not automatically classify this recipient as a processor.
Apple App Store, Google Play and Paddle are selected for future purchases; the relevant seller and controller will be identified at checkout.
EU hosting does not exclude third-country access. Contracting entities, regions, onward recipients and the applicable transfer mechanism require confirmation before production. Transfers may rely on an adequacy decision within its actual scope, including DPF only for the covered certified organization and data, or SCCs and required safeguards. Request information and copies of applicable safeguards through §1; we do not claim that an unverified agreement or certification already exists.
6. Retention and erasure
Account data and encrypted Vaults are retained while providing the service, and afterwards only as needed for individual rights, legal duties or justified claims. Planned launch limits are 30 days for technical authentication/IP logs and 365 days for audit. Unverified waitlist entries are to be deleted seven days after the latest token and no later than 30 days after creation. These mechanisms require implementation. A verified unused entry is retained as necessary to honor the promised Benefit; failure to create an account does not itself expire it.
Analytics data are retained only as long as needed for the stated measurement, then deleted or irreversibly anonymized. Withdrawal and objection require processing to end under the applicable rules; another purpose needs its own basis. Provider configuration and deletion must be verified before activation, without assuming indefinite retention.
Current Entry history covers up to 100 versions in total, older versions for at most 365 days; the current version is protected from that cleanup. Deleted Entries enter permanent deletion after 30 days through a periodic process, with possible delay on failure. These are not account, audit-export or backup erasure deadlines. Complete account and copy erasure still requires implementation. Minimal historical attribution of a former member remains linked to the Organization’s existence, subject to their rights.
7. Security and device data
Client encryption protects Entry contents and presentation. Access controls, permission versions and records supplement it. Do not send us your Master Password or keys. Local CSV/JSON exports may contain plaintext; protect them yourself.
Clients persist encrypted Entry copies and wrapped keys, together with session data, settings and consent choices, among other data; see the Cookie Policy. The pre-production mobile biometric variant stores the master key in OS-protected storage; its clearance requires resolution before launch. We therefore do not claim that all keys exist only in RAM.
Shared unlock under development links account, sessions and client connections; it processes identifiers, authorization states, security versions, deadlines, public keys and one-time proofs. This does not give the server a plaintext Vault key. The feature remains pre-production; its scope and retention must be established before availability.
8. Analytics, marketing and rights
Web/mobile client analytics is designed to be opt-in: it requires an active notice, account consent and local activation. Analytics is not yet cleared for production. Landing has a separate consent choice and may use analytics before the app launches; test preview sends no events. This transport uses no autocapture, session recording or person profiles; extension telemetry is disabled. After clearance, data consist of selected events, account or random page identifier, session and limited technical properties, without form or Entry contents. Recipient connection data need separate retention controls.
Backend measurement of completed actions is a separate purpose: it includes pseudonymous account/waitlist identifier, event and limited technical data. It must not bypass client analytics refusal. Activation requires a basis assessment, retention and effective objection handling. Marketing requires separate consent and easy unsubscribe; marketing delivery is not currently implemented.
You may request access, rectification, erasure, restriction and portability under GDPR conditions. Consent may be withdrawn as easily as given, without affecting prior lawfulness. You may object to legitimate-interest processing on grounds relating to your situation; direct-marketing objection is unconditional. Contact §1. We normally respond within one month; a justified two-month extension requires notice within the first month. You may complain to Poland’s President of UODO (uodo.gov.pl) or another competent EEA authority. Absence of an account-deletion button does not remove these rights.
The app does not currently read the browser’s “Do Not Track” signal as a separate instruction; analytics choices are controlled as described in the Cookie Policy. We do not conduct cross-site advertising tracking. We do not sell data. Benefit eligibility is checked automatically against the promotion terms; you may challenge the outcome and request human review.
9. Minors
The planned minimum age is 13. Accounts aged 13–17 require documented representative approval; paid access at launch is only through Family purchased on an adult’s account. Purchasing and representation are separate roles and do not automatically provide private-Vault access.
The process requires implementation of minimal age-eligibility and country information, an approval link, representative contact and authority declaration, and acceptance version, scope and date. The bases concern entering a valid contract and demonstrating representation, separately from optional consent. Contract approval is not Article 8 GDPR consent; contractual-capacity and data-consent thresholds are different. Disabling optional analytics and marketing for under-18s, including backend measurement, is an adopted release condition, not a claim of an existing age mechanism. Credible reports of use by a child under 13 require stopping impermissible processing and appropriate erasure.
10. Changes
Before new processing starts, we will update this information and obtain separate consent where required. Material changes will be communicated in the service or by e-mail. Published changes will be recorded in the public changelog.