Privacy Policy

RowShield is a product of Veristria, a Norwegian aksjeselskap (AS) under incorporation (24 August 2026), based in Norway. Veristria is the controller of the personal data described here, and its organization number goes on this page the day registration completes.

One address handles everything on this page — access, correction, deletion, or an argument about a sentence you do not believe: info@useveristria.com.

You give us an app URL or a Supabase project URL, and optionally the anon (publishable) key your app already ships to browsers. If you give an app URL, we fetch that page and the JavaScript it references — the same way a visitor’s browser would — looking for your Supabase project URL and anon key, and for a service role key or personal access token that should never have shipped to a client. Only GET, HEAD and OPTIONS requests are ever issued, and private, loopback and cloud-metadata addresses are refused before we connect and again on every redirect hop.

Once we have a project URL and an anon key, we list the tables Supabase’s API exposes and ask each one for a single row with an exact row count. A table that answers is recorded as reachable, together with the column names it returned and the count — the row values themselves are never kept, never shown back to you beyond what your own request already returned, and never leave that one request. A discovered service-role key or access token is reduced to a short fingerprint before it is used for anything; the live value is never written down.

Nothing about an Instant Check is stored. It runs for the length of your request and the result is returned straight to your browser. There is no database row, no report page, and no link to share afterward, because there is nothing saved to link to.

Connecting a project means giving us a Postgres connection string. It is envelope-encrypted before it is ever written down — a fresh AES-256-GCM data key per write, itself wrapped by a key held in a key-management service, bound to your organization and project so a copy of the ciphertext moved to another tenant simply fails to decrypt. It is decrypted only inside the scan worker, for the length of a scan.

What the scanner reads with that credential is six fixed statements against pg_catalog and storage.buckets metadata, plus the server version string — tables, columns, policies, indexes, storage bucket settings. None of the six takes a parameter, and there is no statement anywhere in the scanner that reads a row of your own data. What we keep from a scan is that structural snapshot and the findings derived from comparing it to the one before it, never row contents.

Your account. Sign-in runs through Supabase Auth, so we hold your email address, an account identifier, and which organization you belong to. We do not store passwords ourselves.

Alert destinations. If you set up alerts we store where to send them — an email address, or a Slack or Discord webhook URL. A webhook URL is a bearer credential in its own right, so it is masked before it is ever shown back to you on the settings page; the full value is never redisplayed.

Billing. Subscriptions run through Stripe, and a Revolut payment link is available for manual invoicing where that option is enabled. Either way the payment provider collects and holds the card or account details; what reaches us is a customer identifier, the plan, and whether the invoice was paid.

The launch list. If you give us your email for product updates we store three things: the lowercased address, the site that captured it, and the timestamp. No IP, no name, no referrer. The address is never written to a log.

Rate limiting. The public Instant Check is limited per caller to stop a page looping on it. These are in-memory counters, not logs, and they are gone within minutes.

Contract — your account, your connected projects and your billing records exist because you asked for the service.

Consent — the launch list, which you can withdraw from at any time.

Legitimate interests — keeping the service available and abuse under control, which is what the rate-limit counters and server logs are for.

Legal obligation — invoices and the accounting records behind them, which Norwegian law requires us to keep.

These companies process data on our behalf. We sell nothing, and we have no advertising partners.

• Vercel — hosting and delivery for this site.
• Supabase — RowShield’s own application database and sign-in service. This is separate from the Supabase project you connect for monitoring, which remains yours; we only reach it through the connection string you provide.
• Stripe, and Revolut where enabled — payments and billing. The card or account data stays with them; we never see or store it.
• A key-management provider — holds the key that wraps each project’s data key. It never sees a connection string in the clear.

Strictly necessary only: the session cookie that keeps you signed in, and the cookies Stripe sets during checkout. No advertising cookies, no analytics cookies, no cross-site tracking.

That is why there is no consent banner in front of this page. Strictly necessary cookies do not require consent and we have nothing else to ask about. If we ever ship anything that is not strictly necessary, a banner appears first and it defaults to off.

Account data and the projects connected to it: for as long as the account exists. Disconnecting a project clears the stored connection string immediately.

Instant Check runs: nothing to keep. The result is computed and returned to your browser without being written to a database.

Launch-list addresses: until you unsubscribe or ask us to delete them. Invoices: for the period Norwegian bookkeeping law requires, which we cannot shorten on request. Rate-limit counters: minutes.

Under the GDPR you can ask for a copy of what we hold about you, ask us to correct it, ask us to delete it, ask for it in a portable form, object to processing based on legitimate interests, and ask us to restrict processing while something is disputed. Where we rely on consent you can withdraw it at any time.

Email info@useveristria.com and we answer within a month. No form, no fee. We will ask you to confirm you control the address in question, because handing an account’s data to whoever asks first would be its own privacy failure.

We are based in Norway and operate for the EEA. Some of the processors above are established in the United States and may process data there, covered by the transfer mechanisms those providers publish — standard contractual clauses and, where applicable, the EU–US Data Privacy Framework.

Tell us first if you can. If we do not resolve it, you can complain to the Norwegian Data Protection Authority, Datatilsynet, at datatilsynet.no, or to the supervisory authority where you live.

When the code changes, this page changes, and the date at the top moves with it. If a change materially affects what we do with data you have already given us, we tell you by email rather than quietly editing the page.