Security

1. Who we are and what this page covers

JustBrowser (the "Service") is operated by Velocity Digital Labs LLC, 131 Continental Dr, Suite 305, Newark, DE 19713, USA ("we", "us"). "You" means the person reading this page, whether you are a customer or a security researcher.

The Service consists of the desktop application for Windows x64 and macOS (Apple Silicon), the web dashboard and API at justbrowser.app, and the cloud sync, team, sharing and proxy marketplace features that run behind them. There is no Linux build.

This page is a statement of practice, not a contract. Your use of the Service is governed by the Terms of Service at /terms and the Acceptable Use Policy at /acceptable-use. How we handle personal data is described in the Privacy Policy at /privacy.

2. Reporting a vulnerability

If you believe you have found a security vulnerability in the Service, we want to hear about it. Please report it to us before disclosing it to anyone else.

2.1 Where to send a report

Send reports by email to [email protected]. Do not use any address on a justbrowser.com domain; that domain does not belong to us and mail sent there does not reach us.

We do not publish a PGP key, so we cannot accept encrypted email. If your report contains material you are not comfortable sending in plain text, send a short message first describing the class of issue and we will agree a secure channel with you.

2.2 What to include

A useful report lets us reproduce the issue without guessing. Please include as much of the following as you can:

• Which part of the Service is affected: the website or dashboard at justbrowser.app, the API under justbrowser.app/api, or the desktop application (and on which platform and version).
• A description of the vulnerability and the impact you believe it has.
• Step-by-step instructions to reproduce it, including any request or response captures, screenshots, or a minimal proof-of-concept.
• Any account identifiers or test data you used, so we can find the activity in our logs.
• How you would like to be credited, if at all, and whether we may contact you with follow-up questions.

2.3 What we commit to

• We will acknowledge receipt of your report.
• We will investigate it and tell you whether we have confirmed the issue.
• We will keep you informed of our progress until the issue is resolved or we have decided not to act on it, and we will explain why in the latter case.
• We will not take legal action against you, or refer you to law enforcement, for research carried out in good faith under section 2.4.
• We will credit you on request once the issue is fixed, if you want to be credited.

2.4 Safe harbour

We consider security research conducted in line with this page to be authorised. We will not pursue civil claims or support criminal prosecution against you for such research. The Terms of Service at /terms and the Acceptable Use Policy at /acceptable-use each contain an express exception for good-faith security research that complies with this page, to the extent the research stays within the scope this page describes, so such research is not a breach of the Terms (including the reverse-engineering restriction) or of the Acceptable Use Policy. If a third party starts legal action against you for research that complied with this page, we will make it known that your activity was authorised.

To stay within this safe harbour, you must:

• Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of the Service.
• Only test against accounts, profiles and data that you own or have explicit permission to test. Do not access, modify or download data belonging to other users. If you encounter another user's data by accident, stop, do not retain it, and tell us in your report.
• Not use a vulnerability beyond what is needed to demonstrate it. Do not pivot, persist, or escalate once you have proof.
• Not disclose the issue publicly, or to any third party, until we have confirmed it is fixed or we have agreed a disclosure date with you.
• Not demand payment or any other benefit as a condition of disclosing the issue.
• Comply with all applicable laws.

2.5 In scope

• The website and web dashboard at justbrowser.app, including authentication, team workspaces, profile sharing, cloud sync and the proxy marketplace.
• The API under justbrowser.app/api.
• The JustBrowser desktop application for Windows x64 and macOS (Apple Silicon), including its local REST API, its handling of proxy credentials and saved logins, and its sync and update mechanisms.
• The installers we distribute from justbrowser.app.

2.6 Out of scope

The following are not in scope. Reports limited to these areas will not be acted on and are not covered by the safe harbour in section 2.4.

• Third-party proxy providers, including DataImpulse and Oxylabs, and any infrastructure they operate. Report issues in their services to them directly.
• Our other sub-processors (Railway, Amazon Web Services, Stripe, JustEmails, Cloudflare), except where the issue is caused by our own configuration of their service.
• Google Analytics, which we use to measure how our website is used, except where the issue is caused by our own configuration of it.
• Denial-of-service or resource-exhaustion testing of any kind, including rate-limit exhaustion.
• Social engineering, phishing or physical attacks against our staff, contractors or users.
• Reports that depend on a user having an already-compromised device, browser or account.
• Automated scanner output without a demonstrated, reproducible impact.
• Findings about the anti-detection behaviour of profiles (for example, that a particular detection site scores a profile a certain way). These are product issues, not security vulnerabilities; send them to [email protected].

2.7 No bug bounty

We do not run a bug bounty programme and we do not pay for vulnerability reports. We may say thank you and credit you publicly, but you should not expect a reward. We say this plainly so that you can decide whether to spend your time here.

3. What we do today

This section describes the controls that exist in the Service as of the date at the top of this page. It is limited to what we actually do.

3.1 Transport

All traffic between the desktop application or your browser and justbrowser.app is carried over TLS, as is traffic from the Service to Stripe, Amazon S3 and JustEmails.

3.2 Proxy credentials and saved logins

Proxy credentials and saved logins stored by the desktop application are encrypted with AES-256-GCM using a per-account key rather than a per-device key. This is what allows a synced profile to be opened on a second machine that is signed in to the same account. Our server derives that key from your account id and a server-side secret and sends it to the app after you sign in, so it is not an end-to-end key: it protects these fields on your device and in sync archives, but we could reconstruct it.

If the application cannot obtain the account key (for example it is started offline before its first sign-in completes), it falls back to a key derived from the install path and machine hostname, and re-encrypts that data with the account key the next time it fetches one.

The local SQLite database that the desktop application keeps on your computer is not encrypted as a whole. It is a local file under your control, protected by your operating system's user account and disk encryption if you have enabled it. Anyone with read access to your user account on that machine can read the unencrypted parts of it.

3.3 Cloud sync archives

When you enable sync, the desktop application uploads an archive of the profile to Amazon Web Services S3 in the us-east-1 region. These archives contain the profile's cookies, sessions and browser storage and are therefore sensitive. They are stored with S3 server-side encryption (AES-256). We do not open or read the contents of sync archives.

Alongside each archive we store a profile summary in our database so that your other devices can list the profile before downloading it. The summary holds the profile name, notes, tags, folder names, fingerprint settings, proxy host, port and username, and the site addresses and usernames of saved logins, with proxy and saved-login passwords in encrypted form.

An archive is deleted when you delete the profile, and the profile's name and summary are cleared in the same database write; a minimal deletion record (ids, deletion time, storage key, size, checksum) remains so the deletion propagates to your other devices. You can delete your account from Settings in the web dashboard; it takes effect immediately, cancels any active subscription, and removes your sync archives and every record that belongs to the account. The trial card fingerprint is retained (see the Privacy Policy).

3.4 Local REST API

The desktop application exposes a local REST API of 109 endpoints for automation. It is enabled by default and can be turned off in Settings. It is bound to 127.0.0.1 only, so it does not accept connections from other machines on your network, and every request except the unauthenticated GET /health check must carry a bearer token. Any process running under your user account on the same machine can reach it if it has the token; treat the token as a secret.

The local API token is separate from the API tokens you can create in the web dashboard. Dashboard-issued tokens authenticate calls to our cloud API and are stored against your account together with the time each was last used; the local token stays on your machine.

3.5 Payments

Payments are processed by Stripe. Card numbers are entered directly into Stripe and never reach our servers. We store only Stripe customer and subscription identifiers and, because we offer one trial per person, the opaque card fingerprint token Stripe issues for the card used to start a trial, so that we can tell whether a card has already been used for one. That token is not the card number and cannot be turned back into one. We may decline a trial, or end one early, where the account or the payment card has already been used for a trial. How long we keep the token is stated in the Privacy Policy at /privacy.

3.6 Sign-in sessions

Only the desktop application registers sign-in sessions. Each desktop installation that signs in to your account registers a device session, recorded with the IP address it connected from, its user agent, the device name and operating system, the JustBrowser version, and when it was last seen. You can see these in the Active Sessions panel of the web dashboard and sign out any device, or all of them. A signed-out device stops within about 60 seconds of its next check-in; a device that is offline stays signed in until it reconnects. A revoked device drops out of the list after 7 days and its record is deleted 30 days after revocation; a device that has not checked in for 90 days is deleted. These purges run when your account next registers a device or a device checks in; there is no scheduled job.

Web-dashboard sign-ins are separate. The dashboard uses a signed session cookie with no server-side session record, so dashboard sign-ins are not listed in the panel and cannot be cancelled remotely. That cookie expires 30 days after last use; signing out deletes it from that browser. When you register an account we also log the IP address, user agent and email address of the registration request.

If you suspect your account has been accessed by someone else, change your password (or the password of the OAuth provider you sign in with), sign out all devices, sign out of the dashboard in every browser you have used, then contact us.

3.7 Authentication and cookies

Authentication is handled with Auth.js. In normal use, Auth.js sets three cookies, all strictly necessary for sign-in and session handling: __Host-authjs.csrf-token and __Secure-authjs.callback-url, which last for the browser session, and __Secure-authjs.session-token, which expires 30 days after your last visit and is extended each time you use the dashboard. A fourth cookie, __Secure-authjs.pkce.code_verifier, is set for up to 15 minutes only while a Google sign-in is in progress. Our own code sets one more, jb_dg_nonce, for up to 10 minutes only while a Google sign-in started from the desktop app is in progress.

The website sets two other kinds of first-party cookie. One remembers your Google Analytics choice for 6 months. Where Google Analytics runs, it sets _ga and _ga_TVZHQ99TZW, which are not strictly necessary. In the United Kingdom, Switzerland and the EEA (including EU territories with their own country code), and wherever we cannot tell which country you are in, Google Analytics runs only after you accept it. Elsewhere, it runs unless you turn it off in Cookie settings. It never runs if your browser sends a Global Privacy Control or Do Not Track signal. Google Analytics also never runs on /check or /newtab (the pages the desktop application opens inside your profiles), on /reset-password, /invite/… or /fingerprint-checker, on any address containing token= or totp=, or on any address whose next or callbackUrl parameter points to an invitation or password-reset page. Cloudflare Web Analytics, which also runs on the website, sets no cookies. There are no other first-party cookies and no advertising cookies on the website, and as of the date at the top of this page no infrastructure provider sets a cookie on it. Details are at /cookies.

3.8 Team workspaces and sharing

Team seats are free and unlimited. A seat is not a licence: a team member may only open the profiles the workspace owner has shared into the workspace, and every member of the workspace sees the same shared set. A seat cannot see the owner's unshared profiles, cannot sync profiles of its own, cannot create API tokens and cannot re-share. Direct user-to-user sharing is per profile and per recipient, with view-only or launch permission as the owner chooses. Membership and invitations are visible to the workspace owner in the dashboard. We do not keep an audit log of workspace activity.

3.9 What we do not collect

The desktop application sends no usage analytics, telemetry or crash reports to us; none exists in the application. Neither Google Analytics nor Cloudflare Web Analytics runs on /check or /newtab, the pages the application opens inside your profiles. We do not collect browsing history or page content from inside profiles. Rate limiting on the API keys on IP address transiently and is not retained as a log of your activity.

3.10 Where data is processed

The Service is hosted on Railway (application and PostgreSQL) in the United States, with sync storage on Amazon Web Services S3 in us-east-1 and DNS and edge services from Cloudflare. Website analytics come from Cloudflare (Cloudflare Web Analytics) and, where it runs, Google (Google Analytics); section 2.11 of the Privacy Policy describes what each receives. Transactional email is sent by JustEmails, a Velocity Digital Labs product. When you buy a proxy allocation in the marketplace, the relevant provider (DataImpulse or Oxylabs) receives a pseudonymous identifier derived from your account id so it can attach the allocation to you; we do not send your name or email. The full list of sub-processors and what each receives is in the Privacy Policy at /privacy.

4. What we do not yet do

We would rather you learn these from us than discover them yourself.

• Installers are not yet code-signed. Signing for both Windows and macOS is in progress. Until it ships, Windows SmartScreen and macOS Gatekeeper will warn when you open the installer. Download installers only from justbrowser.app.
• We have not had a third-party security audit or penetration test, and we hold no security certification (no SOC 2, ISO 27001 or similar). If you find an older page of ours that says otherwise, this page is correct and that page is out of date; tell us so we can fix it.
• We do not publish a PGP key, so we cannot receive encrypted vulnerability reports by email.
• We do not run a bug bounty programme.
• The local SQLite database on your computer is not encrypted as a whole (see section 3.2). Enable full-disk encryption on your machine if this matters to you.
• We do not keep an audit log of team workspace activity (see section 3.8). The workspace owner can see membership and invitations, but not a history of who opened which profile.
• Because the application sends no telemetry or crash reports, we cannot detect a security problem in the desktop application on your machine on our own. If you see something wrong, you have to tell us.

5. security.txt

We publish a machine-readable security.txt at https://justbrowser.app/.well-known/security.txt (RFC 9116). It repeats the reporting contact in section 2.1 and links back to this page. If the file and this page ever disagree, this page is authoritative until we correct the file.

6. Changes to this page

We will update this page when a control described here changes, when a control listed in section 4 is added, or when the disclosure process changes. We will post the updated version with a new date and, for changes that narrow what you may do or reduce your rights, notify account holders by email before they take effect. The date at the top shows the last revision. Material changes to how we handle your data are also reflected in the Privacy Policy at /privacy.

7. Contact

• Security vulnerabilities: [email protected]
• Privacy questions, data subject requests and account deletion: [email protected]
• Terms, abuse, refunds, legal notices and everything else: [email protected]
• Postal: Velocity Digital Labs LLC, 131 Continental Dr, Suite 305, Newark, DE 19713, USA