Privacy Policy

Data controller

SHTERA is a product of TeraServer Network Solutions, operated by CABRAL, ALBERTO SANTIAGO (Argentine tax ID / CUIT 20-28693326-3, registered as Responsable Inscripto with Argentina's tax authority AFIP/ARCA, gross-receipts tax registration 1090088-08, in business since 11/01/2002), with registered address at Amenabar 2313, Piso 3, Dto. 6, Ciudad Autónoma de Buenos Aires, Argentina. For any question about this policy or your personal data, write to support@shtera.com.

Account data

When you create an account we store your email, your company name, an identifier of our own (the "slug" used for your subdomain), and the plan you signed up for.

Data about the servers you add

The name, IP address or domain, port, and username of every server you add to SHTERA are stored in the clear, along with the fingerprint of that server’s host key. This data is NOT protected by the vault’s encryption — the service operator can see it, unlike passwords (see the next section).

Your servers’ passwords and keys

The passwords and private keys of the servers you add are encrypted in your own browser before they ever leave it, with a key that is also derived there. SHTERA’s server only moves and stores encrypted blocks: it cannot read a client server’s password at any point in the normal process. The one exception is account rescue, explained below.

Your SHTERA account password

The password you use to sign in to the dashboard never travels to the server. Your browser computes a derivative of that password, and the server stores, in turn, a derivative of that derivative. This is the same mechanism that derives the key that encrypts your vault.

Account security data

We also store your two-factor authentication secret (TOTP), and the RSA key pair your browser generates for you: the public key in the clear, and the private key wrapped (encrypted), the same way your servers’ credentials are.

Audit log

Every session opened through SHTERA is logged: who connected, when, to which server, and from what source IP address. This log runs on every plan, including Free, and cannot be turned off.

Session recording and transcription

Starting on the Básico plan, an account owner can turn on activity logging within a session for their own company, on top of the audit log described above. It’s off by default: it has to be turned on deliberately, and the audit log records who turned it on and when.

In a terminal (SSH) session, a text transcript of what appears on screen is stored alongside the video. Because it records what’s shown on the terminal, passwords typed at a sudo prompt or similar, which aren’t echoed to the screen, don’t end up in the log.

In a desktop session (RDP or VNC), the keys the person presses and the clicks they make are recorded. We want to be explicit here: this log can capture passwords or other sensitive information typed inside the remote server, because the system has no way to tell a password apart from any other typed text.

Anyone connecting to a session under recording sees a notice inside the interface itself. Recordings and transcripts are stored in the client’s own S3 bucket, not on SHTERA’s infrastructure — we never access that content. The quota depends on the plan: you’re warned at 80%, and at 100% recording stops, without cutting off sessions already in progress.

The rescue key and assisted recovery

The key that encrypts each vault folder (the DEK) is wrapped four ways: with your master password, with a 24-character recovery code, with a WebAuthn PRF-compatible passkey, and with a backup copy (the escrow). This fourth key exists for one specific case: a customer who loses their password without a recovery code on hand and without a passkey set up, who would otherwise be left with no way back into what they stored.

The escrow private key doesn’t live on SHTERA’s server: it lives encrypted on a separate machine, on another provider, that accepts no inbound connections from anyone — it reaches out itself, authenticated, to check for pending recovery requests. A rescue doesn’t activate on its own: the customer requests it, gets a small charge to the card on file (between US$ 0.01 and US$ 5.00, with a code in the description), and has to report back the exact amount, the code, and their new password. Only once that’s verified does that separate machine open the vault, re-encrypt it with the new password, and hand the customer a one-time link to log in. An email goes out at every step: when the charge is made, when the request is received, and when it’s completed.

Who else your information reaches

To run the service, we share specific data with:

• Cloudflare, which runs the anti-bot check (Turnstile) on registration and login.
• The hosting provider of the server SHTERA runs on.
• SHTERA’s own outbound mail server, for transactional emails (account verification, invitations, notices).
• The storage provider behind the S3 bucket where you keep your own recordings and transcripts — the bucket is yours, but that cloud provider also processes that data on SHTERA’s behalf.
• TeraServer, which bills and collects payment for SHTERA’s plans through its own system — SHTERA doesn’t process payments directly.
• Google, through Google Analytics, only on the public site (shtera.com) — see the next section. It never loads inside the panel or the vault.

Cookies

SHTERA uses four cookies of its own, all of them functional: none is for advertising or third-party tracking.

• Session: keeps you signed in.
• Language: remembers whether you chose Spanish or English.
• Theme: remembers whether you chose light or dark mode.
• Vault key: holds the encryption key for the duration of your session, so you’re not asked for your password on every screen.

Google Analytics

SHTERA’s public site (shtera.com, without a signed-in session) loads Google Analytics from the first visit, without asking for prior consent: SHTERA is an Argentine product, operated under Argentine jurisdiction, and is not subject to the cookie opt-in requirement that other regulations outside the country impose. The Analytics script and its cookies (_ga, _ga_*) load every time you visit the public site.

This applies only to the public site. SHTERA’s panel (where the vault lives) and everything behind a sign-in never load Google Analytics under any circumstance: what a customer does inside their own account is never measured.

Legal bases for processing

In Argentina, this policy is governed by Law 25,326 on the Protection of Personal Data, whose enforcement authority is the Agencia de Acceso a la Información Pública (AAIP). You have the right to access your data, correct it, and request its deletion.

SHTERA is also sold in US dollars and has an English-language site, so it may have customers or users in the European Union and the United Kingdom. For them, the GDPR applies: the legal basis for processing is performance of the service contract and, for security auditing, the legitimate interest in protecting the platform and its users. Your rights include access, rectification, erasure, portability, objection, and restriction of processing.

SHTERA’s servers are hosted on OVH Cloud infrastructure, outside the European Union, so using the service involves an international transfer of data. Argentina has an adequacy decision from the European Commission (Decision 2003/490/EC, still in effect under Article 45 of the GDPR), so transfers of personal data from the European Union to Argentina do not require additional standard contractual clauses. [[PENDING: a lawyer must confirm this basis is still current and that it covers the sub-processors — OVH Cloud and, if the owner confirms it, Cloudflare (which sits in front of the service) — that may sit outside Argentina]].

Audit logs are kept for 24 months after an account is closed, and deleted after that.

How to exercise your rights

To access, correct, or request deletion of your data, write to support@shtera.com. If you’re not satisfied with the response, in Argentina you can turn to the AAIP.

How we protect your information

The vault’s full security design — the four keys, per-folder encryption, and account rescue — is described in detail on the Security page.

Changes to this policy

If this policy changes in a meaningful way, we’ll email you before the change takes effect, and the "last updated" date on this page will reflect it.