Are you sure?

>_ jssh

jssh Privacy Policy

Last updated: July 27, 2026

The short version

  • We collect the data needed to run your account and your fleet: your email address, organization and billing records, device metadata (names, tags, platform, connection times), audit logs of actions taken in your organization, support correspondence, and standard technical logs. Section 3 lists every category.
  • Session traffic is end-to-end encrypted between the jssh CLI and the agent on your device, on every path and for every protocol — not only SSH. The keys are derived between those two endpoints and never exist on our servers, so we cannot read session content or credentials on any path, and could not produce them if compelled. Peer-to-peer sessions never touch our servers at all; TURN-relayed ones pass through Cloudflare's TURN service as encrypted traffic it cannot read either.
  • We do not record or store session content on any path, and we cannot inspect it — the keys are not ours to hold. Earlier versions of this policy reserved the right to run automated abuse detection over traffic that was not end-to-end encrypted; that reservation no longer has an object and we have removed it. Abuse detection runs on connection and Session Metadata only.
  • Our audit logs are metadata only: they contain no byte counts and we do not track per-session data volume.
  • No third-party analytics, no advertising trackers, no tracking cookies. Our product metrics are first-party event counts.
  • We never sell your personal data, and we never give it to anyone for their own marketing or advertising. We disclose it only to the service providers that run the Service, and as described in Section 6 (legal process; corporate transactions).
  • Questions or requests: privacy@jssh.io.

1. Scope of This Privacy Policy

This Privacy Policy describes how Tanor LLC ("jssh", "we", "us") collects, uses, and discloses personal data when you use our device-isolated SSH relay service, including the dashboard and relay at app.jssh.io, binary downloads at get.jssh.io, the jssh CLI and jssh-agent software, and our websites (together, the "Service").

A few terms we use throughout:

  • "Customer" — the person or company that holds an account with us.
  • "Organization" — the tenant unit in the Service; a Customer's devices, users, and settings belong to an Organization. Managed service providers may administer multiple Organizations.
  • "Device" — a machine running the jssh-agent, enrolled in an Organization.
  • "Session Metadata" — records about connections (who connected to which Device, when, for how long, to which service) — never the content of those connections.

This policy is incorporated by reference into our Terms of Service. Where we process data on behalf of a Customer, our Data Processing Agreement also applies (see Section 2).

2. Account Data vs. Organization Content

This distinction matters for understanding your rights, so we put it up front.

Account Data — jssh is the controller. For the data we collect about our own Customers and their users — account and login details, billing records, audit logs of actions taken in the Service, and operational/security data — jssh decides how and why the data is processed. This Privacy Policy is the primary document governing that data.

Organization Content — jssh is the processor. Organizations put their own content into the Service: device names, tags, and other fleet metadata they choose. That content can include personal data belonging to the Organization or its own end clients — for example, an MSP might name a device after a customer site or contact. For this data, the Organization is the controller and jssh processes it only on the Organization's behalf and instructions, under our Data Processing Agreement. In addition, session content in transit over the relay data plane is processed transiently, as transmission only — that transient transmission is covered by the DPA, and the content is never stored or recorded (see Section 4).

If your data reached us through someone else's Organization (for example, your employer or a service provider that manages your equipment), that Organization controls the data and your privacy rights should be exercised with them first. If you contact us directly, we will refer your request to the relevant Organization and assist them in responding, as the law requires of a processor.

3. Information We Collect

The categories below are intended to be complete; if we add a category we will update this policy first. We do not collect data from data brokers, advertising networks, or any third-party tracking source.

CategoryWhat it includesOur role
Account dataYour email address (your primary identity), whether it has been verified, and your role within each Organization. If your Organization uses single sign-on: the subject identifier your identity provider asserts for you (issuer + subject).Controller
Organization & billing dataOrganization name, membership and roles, SSO (OIDC) configuration for your Organization (client secrets are stored encrypted), and your Stripe customer and subscription identifiers. Payment card data never touches our systems — checkout and the billing portal are hosted by Stripe.Controller
Device & fleet metadataDevice names and tags (chosen by the Organization), platform/operating system, agent version, device public keys, connect/disconnect timestamps, and the services the Organization has declared on each device (e.g., "ssh", "vnc").Processor (for the Organization)
Audit logs (Session Metadata)Actions taken in an Organization — including sign-ins, enrollments, approvals, token issuance, session opens, service updates, revocations, membership and access-rule changes, device connectivity events, and SSO configuration changes — with the acting user, the device involved, timestamps, session duration, the names of services accessed, the outcome of access decisions (including denied service-level access attempts within a session), and the operator's IP address. Audit logs never contain session content, and we do not record byte counts.Controller
Operational & security dataShort-lived rate-limiting keys that may include an IP address or email address (expire automatically; minimum 60-second lifetime). Device presence snapshots (online/offline indicators), which expire automatically within minutes (currently under 10 minutes). During CLI or device browser-approval login flows: the requesting IP address and hostname, shown to the approving user; the pending request expires after 10 minutes and is deleted shortly after. If the request is approved, the requesting host name and IP address are recorded in your Organization's audit log.Controller
Product metricsFirst-party event counts only (e.g., sign-ups, enrollments, sessions opened, CLI logins, and similar product events, associated with an Organization identifier), recorded in Cloudflare Analytics Engine on our own infrastructure.Controller
Support correspondenceMessages you send to our support, privacy, legal, or security addresses, and our replies.Controller
Technical logsStandard request and observability logs generated on our hosting platform (IP address, user agent, timestamps), retained briefly for security and debugging.Controller

What we do not collect:

  • No stored session content, on any path. We do not record or store what happens inside your sessions, and we do not inspect it today (see Section 4).
  • No byte counts. We do not measure session traffic volume on any path.
  • No third-party analytics or advertising data. No Google Analytics, no pixels, no ad tech, no tracking cookies.
  • We do not sell personal data, and never have. We do not give personal data to anyone for their own marketing or advertising; our disclosures are limited to those described in Section 6.
  • Traffic to *.jssh.dev device aliases resolves to your own machine (127.0.0.1) and never reaches us.

4. What the Relay Can and Cannot See

Most privacy policies stay vague here. We would rather be precise, because the boundaries differ by connection type.

Session traffic is end-to-end encrypted, on every path. The jssh CLI on your machine and the agent on your device negotiate keys directly with each other. Those keys never exist on our servers, so we cannot read session content or credentials — not on the peer-to-peer path, not through TURN, and not through our own relay. This holds regardless of what you tunnel: RDP, VNC, HTTP, a database or plain TCP get the same treatment SSH always had. It is a property of the protocol, not a promise about our behaviour: there is nothing for us to hand over, and nothing to disable.

What "end-to-end" does not mean here. The encrypted span is CLI ↔ agent. On your machine the application connects to a local port in the clear, and on the device the agent connects to the local service in the clear — the same shape as an SSH port-forward. Anyone with access to either machine is inside that span.

What we can still see. Metadata: which operator reached which device, when, for how long, which service, and how much data moved. Traffic timing and size can also reveal which protocol a session carries — encryption does not hide that.

What encryption does not do: keep us out. Encryption stops us from reading your sessions. It does not stop us from being part of deciding who may open one. We publish the device keys your CLI trusts, and we sign the authorizations that say which operator may reach which device. So the honest risk is not that someone at jssh decrypts your VNC session — they cannot, the keys are not ours. It is that a compromise of our systems could authorize a key that attacker controls and open a new session to your device. Reading your traffic would require breaking the encryption; opening a session of their own would not.

Two things limit that today, and we would rather describe them than claim they are enough. Every authorization we issue is signed with a key your device verifies on its own and keeps, so a session opened that way leaves a record on your device that we can neither alter nor later deny. And your CLI pins each device's identity key on first use and refuses the session if it ever changes, so substituting a device's identity is visible rather than silent. What would remove us from that decision entirely is a signing key held by you, which your devices trust instead of us; we have designed it and have not built it. If that matters for your deployment, tell us.

Peer-to-peer and TURN. When the CLI and the agent negotiate a direct or TURN-relayed connection, our relay carries only signaling; the traffic flows between your machines or through Cloudflare's TURN service, and we do not measure its volume.

On every path, what we retain is Session Metadata only, as described in Section 3.

5. How We Use Information

The table below maps each purpose to the data categories involved (as described in Section 3) and, where the EU or UK GDPR applies, the legal basis we rely on — naming the specific legitimate interest wherever that is the basis.

PurposeData categoriesLegal basis (EU/UK GDPR)
Provide and operate the Service — authenticate you, route your connections to the right device, enforce your Organization's access rules (RBAC and per-service authorization), and show device statusAccount data; Organization & billing data; Device & fleet metadata; Operational & security dataPerformance of a contract
Send transactional email — login magic links and email-verification messages, delivered via Resend, which we treat as transactional service messages (they are required to deliver the Service), not marketingAccount data (email address)Performance of a contract
Keep the Service secure and prevent abuse — rate limiting, anomaly and abuse prevention, and investigating unauthorized accessOperational & security data; Technical logs; Audit logsLegitimate interests: our interest in protecting the security and integrity of the Service and our Customers' fleets
Maintain audit logs for the Organizations that rely on themAudit logs (Session Metadata)Legitimate interests: the security and integrity of the Service, and providing the audit trail Customers rely on
Bill for the Service — via Stripe subscriptionsOrganization & billing dataPerformance of a contract; legal obligation (tax and accounting records)
Provide support — respond when you write to usSupport correspondence; Account dataPerformance of a contract; legitimate interests: resolving the issue you raised with us
Improve the product — first-party usage metrics onlyProduct metricsLegitimate interests: understanding aggregate usage of our own Service
Comply with law — meet legal, tax, and regulatory obligations, and enforce our agreementsThe categories above, as required in each caseLegal obligation; legitimate interests: establishing, exercising, or defending legal claims
Marketing — none today; only if you separately consentAccount data (email address)Consent (withdrawable at any time)

We will not send you marketing email without your separate consent, and if we ever do send marketing, it will include an opt-out. Where we rely on legitimate interests, we balance those interests against your rights and freedoms; Section 9 describes your right to object.

We do not use your personal data to train machine-learning models, to build advertising profiles, or for any purpose unrelated to running the Service.

Where your data comes from; whether you must provide it

Almost all the data we process comes directly from you — when you sign up, configure your Organization, or use the Service. The remaining sources are: your Organization's administrator, when they invite you or assign your role; your Organization's identity provider, which asserts your identity to us when your Organization uses single sign-on; and the jssh CLI or a device, which submits the requesting host name and IP address during browser-approval login flows.

Providing an email address is necessary to create and operate an account — without it we cannot provide the Service. Everything else you provide is optional or follows from how your Organization chooses to use the Service.

We do not make decisions based solely on automated processing that produce legal or similarly significant effects; account-enforcement decisions include human review.

6. How We Disclose Information

We disclose personal data only as follows:

Subprocessors. We use a small set of service providers to run the Service. The current, complete list:

SubprocessorWhat they do for usData involved
Cloudflare, Inc.Our entire hosting platform: Workers (compute), Durable Objects (per-device relay state), D1 (control-plane database), KV (rate limiting, presence), R2 (binary downloads), Realtime/TURN (NAT traversal), Analytics Engine (first-party metrics), and logs/observability. Runs on Cloudflare's global network.All Service data described in Section 3
Resend, Inc.Transactional email (magic links, verification)Recipient email addresses
Stripe, Inc.Billing: hosted checkout, customer portal, webhooksBilling contact and payment data (Stripe handles card data under its own terms)
Telegram FZ-LLC (United Arab Emirates)Operational alerts to our own staffAn organization identifier (e.g. org_a1b2c3), the event type, and a link back to jssh — no organization names, no email addresses, no device or session data

The authoritative subprocessor list, with change-notification terms, is maintained in the annex to our Data Processing Agreement.

Your Organization's identity provider. If your Organization configures single sign-on, authentication runs through the OIDC identity provider your Organization chose and controls. That provider acts for your Organization, not for us, and is not our subprocessor.

Legal process. We may access, preserve, and disclose Account Data and Session Metadata if we believe in good faith that doing so is required by law or legal process, or is necessary to enforce our agreements, to detect or prevent fraud, security, or technical issues, or to protect the rights, property, or safety of jssh, our Customers, or the public. Where it is lawful and practicable to do so, we will notify the affected Customer before disclosing their data in response to legal process, so they have the opportunity to object — unless we are legally prohibited from giving notice or we believe in good faith the request involves an emergency threatening death or serious injury. If a prohibition on notice later lapses, we will notify the Customer where permitted. We store no session content, so there is no stored session content to disclose (Section 4).

Corporate transactions. If jssh is involved in a merger, acquisition, financing, or sale of all or part of its business, personal data may be transferred as part of that transaction, subject to this Privacy Policy's commitments.

We do not sell personal data, and we do not disclose it to third parties for their own marketing.

7. Cookies

We use only first-party, strictly necessary cookies. All are httpOnly, Secure, and SameSite=Lax. Because these are strictly necessary cookies, we believe no consent banner is required under current EU/UK guidance, and we do not show one.

CookiePurposeLifetime
jssh_sessionKeeps you signed in to the dashboardCurrently 7 days
jssh_nextRemembers where to send you right after login10 minutes
jssh_oidc_txProtects the integrity of an in-progress SSO login10 minutes

We use no analytics, advertising, or cross-site tracking cookies of any kind. If that ever changes, we will update this section and ask for consent where the law requires it.

8. Data Retention

We keep personal data no longer than necessary for the purposes for which it was collected, and then delete it. How long that is depends on the data:

  • Account and Organization data is retained while your account is active.
  • Audit logs are retained while the Organization is active because they serve both the security and integrity of the Service (our legitimate interest) and the audit trail Customers rely on; see Section 9 for how this interacts with deletion requests. After an account is deleted, audit logs and other account data are deleted within 60 days, with copies in backups purged in the ordinary course within 90 days. We are building automatic removal of operator IP addresses from audit entries older than 13 months; this policy will be updated when that ships.
  • Revoked devices are soft-deleted: the device stops working immediately, and its record is retained in the Organization's audit history for integrity of the audit trail, until account deletion.
  • Short-lived data expires automatically: session cookies after 7 days (current setting), magic-link tokens after 15 minutes, email-verification links after 7 days, presence snapshots within minutes (currently under 10 minutes), and rate-limiting keys on the order of a minute. Pending CLI browser-approval requests expire after 10 minutes and are deleted shortly after; if a request is approved, the requesting host name and IP address are recorded in the Organization's audit log.
  • Aggregated product metrics reference only an internal organization identifier and are retained on our analytics platform's fixed rolling window (approximately three months); they cannot be deleted earlier.
  • Stripe, Resend and Telegram retain the data they process for us under their own retention policies.

Organization deletion is self-serve: an Organization owner can permanently delete an Organization — including its devices, tokens, access rules, and audit logs — from the dashboard's settings, after revoking its devices and cancelling any active subscription. A single audit record of the deletion itself is retained. Account deletion is handled manually: email privacy@jssh.io from the email address on the account and we will delete your remaining personal data on the schedule above.

9. Your Rights and Choices

Depending on where you live you may have legal rights over your personal data, including under the EU/UK GDPR the rights to access, rectify, erase, restrict, and port your personal data, to object to certain processing, to withdraw consent where processing is based on consent, and to lodge a complaint with your data-protection supervisory authority.

As a matter of policy we extend these rights to everyone, wherever you live — subject to the same kinds of conditions the GDPR allows: we may retain data we need to comply with law, secure the Service, or preserve the integrity of Customers' audit logs, and we may decline requests we cannot verify or that are manifestly unfounded or excessive.

To exercise any right, email privacy@jssh.io. We will verify your identity (normally by confirming control of the email address on the account) before acting, and we will respond within one month, extendable by up to two further months for complex requests, in which case we will tell you within the first month.

Where jssh acts as a processor — data that reached us through a Customer's Organization (Section 2) — the Organization is responsible for responding to your request. We will refer your request to them and assist them in fulfilling it.

10. International Data Transfers

jssh is a US company. Personal data is processed in the United States and on Cloudflare's global network, which stores and processes data in multiple countries. The operational alerts described in Section 6 also reach the United Arab Emirates, which carries no European Commission adequacy decision; what travels there is limited to an organization identifier, an event type and a link.

Where personal data is transferred out of the European Economic Area, the United Kingdom, or Switzerland, we rely on the European Commission's Standard Contractual Clauses (incorporated into our Data Processing Agreement), supplemented by the UK Addendum for UK transfers and adapted as required by the Swiss Federal Act on Data Protection for Swiss transfers. The Standard Contractual Clauses are set out in Commission Implementing Decision (EU) 2021/914, available at eur-lex.europa.eu; our completed annexes appear in the Data Processing Agreement, and you can request a copy of the applicable clauses at privacy@jssh.io.

jssh is not currently certified under the EU-US Data Privacy Framework.

11. EU and UK Representatives

[EU representative and UK representative to be appointed prior to launch — the representatives' names, addresses, and contact details will appear here.]

Once appointed, individuals and supervisory authorities in the EU/EEA and the UK may contact our Article 27 representatives on all matters related to our processing of personal data, in addition to contacting us directly.

12. How We Protect Information

We build the Service so that the sensitive part — your session content — is out of our reach by design where cryptography allows (Section 4). Beyond that:

  • All connections to the Service use TLS; device agents connect outbound only (no inbound ports on your devices).
  • Devices are identified by Ed25519 public-key cryptography, enrolled through authenticated flows.
  • Each device's relay connections and session traffic are handled by a dedicated, isolated relay instance — connection state is never shared between devices, and no path exists from one device to another through the Service.
  • Organization SSO client secrets are stored encrypted (AES-256-GCM).
  • Access within Organizations is governed by role-based access control with per-service authorization, and privileged actions are audit-logged.

No security program eliminates all risk, and we do not claim ours does. jssh does not currently hold SOC 2 or other third-party certifications, and we won't imply otherwise. If you believe you have found a security vulnerability in the Service, please report it to security@jssh.io — we read every report.

If we learn of a breach affecting personal data, we will notify affected Customers and regulators as required by applicable law and by the commitments in our Data Processing Agreement.

13. Children's Privacy

The Service is a business infrastructure tool and is not directed to children. You may not use the Service if you are under 13 — or under 16 where local law sets a higher age of digital consent. We do not knowingly collect personal data from children; if you believe a child has provided us personal data, contact privacy@jssh.io and we will delete it.

14. California Notice

We do not believe we currently meet the thresholds that define a "business" under the California Consumer Privacy Act (as amended by the CPRA); we will revisit this as we grow. In any case, California residents can exercise the access and deletion rights described in Section 9 — we honor these rights for everyone regardless of whether the CCPA applies to us. For clarity under California terminology: we do not sell personal information and we do not share personal information for cross-context behavioral advertising, and we have not done either in the preceding 12 months.

15. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. When we do, we will change the "Last updated" date at the top. If a change is material — in particular, any change to what we collect, what the relay can see, or how data is disclosed, or if we begin any inspection of session content — we will give Customers advance notice by email or a prominent notice in the dashboard before the change takes effect. Your continued use of the Service after a change takes effect constitutes acceptance of the updated policy.

16. Contact Us

Tanor LLC
21 SE 1st Avenue, 3rd Floor, Miami, FL 33131, United States

Related documents: Terms of Service · Data Processing Agreement