Skip to content
SeeTheBug

Legal

Privacy Policy

Last updated: TBD

⚠ Placeholder — not yet legally reviewed

This document is a structural outline only. It is not a binding agreement and must be replaced with text prepared or reviewed by qualified legal counsel before this site goes live. Do not rely on anything below.

Draft pending legal review. The placeholders [TRADER LEGAL NAME] and [US BUSINESS ADDRESS] must be completed, and this document reviewed by qualified counsel, before it is relied upon.

1. Who we are

SeeTheBug is a service operated by [TRADER LEGAL NAME], a sole trader established in Israel, trading as SeeTheBug.

Address for notices: [US BUSINESS ADDRESS] Email: support@seethebug.com

If you are in the EEA or the UK and wish to exercise a data-protection right, please write to the email address above.

2. Scope, and our two different roles

SeeTheBug is a tool that software vendors give to their own customers. That creates two distinct sets of personal data, and our responsibilities differ between them. This distinction runs through the whole policy, so it is worth reading first.

Where we are the controller. We decide how we handle the data of people who deal with us directly: the people who create and use SeeTheBug accounts, and visitors to this website. Sections 5, 8, 9 and 12 describe that data.

Where we are a processor. The contents of a capture package belong to our Customer. The Customer decides what its Deployment Profiles collect, from whom, and why; we store and transmit the result on the Customer’s instructions. We do not decide what goes into a capture package and we do not use its contents for our own purposes. Section 6 describes what a package can contain, and section 14 explains how requests from End Users are handled.

What this policy does not cover. It does not cover our Customers’ own products, the websites or software you were using when an issue occurred, or how a Customer handles a capture package after we deliver it to them. For that, see the privacy notice of the vendor whose support team asked you to record the issue.

3. Definitions

  • Account — a Customer’s tenancy on the platform.
  • Customer — the organization that holds a SeeTheBug Account, normally a software vendor providing support to its own customers.
  • Authorized User — an individual the Customer permits to sign in to the Account.
  • End User — an individual who runs the SeeTheBug Client to reproduce and record an issue, typically a customer or employee of the Customer. End Users do not have SeeTheBug accounts and do not sign in.
  • Client — the SeeTheBug desktop application installed on the End User’s machine for reproducing and recording issues.
  • Deployment Profile — the Customer’s configuration of what the Client collects, and which of those items are shown to the End User before a reproduction begins.
  • Capture Package — the file the Client produces at the end of a reproduction.

4. Whose data is involved

  • Authorized Users of a Customer’s Account.
  • End Users who run the Client.
  • Anyone who submits our contact or demo-request forms.
  • Anyone whose personal data happens to appear in material an End User records or a Customer’s Deployment Profile collects — for example, a colleague’s name visible on screen during a recording.

5. Data we handle as controller

Account data. Name, email address, a hash of your password, locale, timezone, role within the Account, last sign-in time, email-verification and invitation tokens, a counter of failed sign-in attempts and any lockout expiry, and which Authorized User invited you.

The country you declared at sign-up. Where your browser’s timezone or language suggests you may be in the EEA or the UK, the sign-up page asks you to confirm your country, because we cannot offer Accounts there yet (see section 9 of the Terms). We store the country you selected against your Account. We store it only when you actually chose it — we do not record a guess.

Declined sign-ups from the EEA or the UK. If you confirm a country where we cannot yet offer Accounts, the sign-up is declined and no Account is created. We do keep a record of the attempt — your name, email address and the country you selected — in our server logs and in a notification to our own support inbox, so that we can contact you once the Service becomes available in your region. We rely on our legitimate interest in following up someone who tried to open an account.

We may email you once, when that happens. We will not add you to a mailing list, and every message will tell you how to stop. You can object to being contacted, or ask us to delete the record entirely, at any time by writing to support@seethebug.com.

Form submissions. Anything you send us through the contact or demo-request forms, and the message content itself.

Server logs. Our servers record requests, including the originating IP address, HTTP method, URL, user-agent string, timestamps, and diagnostic detail about failures. Email addresses appear in these logs where they form part of a request. Log files rotate daily, roll over at 10 MB, and up to 50 files are retained.

We do not attempt to build profiles, and we do not use this data for advertising.

6. What a Capture Package can contain

This is the section to read closely if you are an End User, or a Customer deciding what to collect. The list below is what the Client is capable of gathering. What is actually collected in any given reproduction is set by the Customer’s Deployment Profile, so a particular capture may contain far less than this.

Recordings and audio:

  • Video recordings of the displays the End User selected. Screen recording is always the End User’s choice and cannot be forced by the Customer.
  • Microphone audio, only when the End User enables it. This is also always the End User’s choice.
  • An on-screen keystroke panel records the keys pressed while it is active, including keys typed in applications other than the one being reproduced, and those keystrokes become part of the video. The panel is visible throughout and the End User can pause or close it at any time. Please pause it before typing a password.
  • While a screen recording is running, mouse clicks and drags are detected — again including clicks in other applications — so that they can be drawn as indicators over the recording. Only the fact and position of a click are used, to draw the indicator; they are not stored or sent anywhere separately from the video itself.

Information the End User supplies:

  • The title, notes and any files the End User chooses to attach.

Diagnostics gathered from the computer, where the Deployment Profile requests them:

  • Machine identity: hostname, Windows domain, fully-qualified domain name, machine UUID, serial number, whether the machine is virtual, timezone.
  • Operating system: distribution, version, build, service pack, code page, UEFI and hypervisor status, and whether the session is a remote one.
  • Hardware: CPU, memory, disks, GPU and display configuration.
  • Running processes, including the owning username and the full command line of each process.
  • The operating-system username and the groups that account belongs to.
  • Network configuration: adapters with IP and MAC addresses, active connections including the addresses of the remote peers, DNS servers, VPN profiles, and proxy settings.
  • Windows performance-counter samples.
  • Files matching patterns the Customer configured — for example application logs or configuration files.
  • Output from custom collectors the Customer wrote.
  • The Client’s own diagnostic logs for the session.

Several of these are identifying or revealing in ways that may not be obvious: command lines can contain file paths and arguments, group membership can reveal an organization’s structure, and peer addresses can reveal which systems a machine talks to. Customers should collect only what they need, and should consider whether items like process command lines are necessary before enabling them.

7. Encryption, and what remains visible to us

We describe this precisely because it determines what we can and cannot see.

Payload encryption is optional. It applies only when the Customer has configured an encryption key for the Account. When no key is configured, the Client does not encrypt the payload, and the platform accepts the package as it is.

When encryption is enabled, the capture payload is encrypted on the End User’s machine with AES-256-GCM using a key generated for that single package, and that key is itself wrapped with the Customer’s public key using RSA-OAEP-SHA256. We hold no copy of the private key, so we cannot read the payload. Only the Customer can decrypt it.

What is not encrypted, in either case. Every package carries an unencrypted header so the platform can file it against the right Account. That header contains the Account, deployment, product, configuration-profile and capture identifiers, the title the End User typed, the start and packaging timestamps, the size of the payload, and a SHA-256 checksum of the payload before encryption. A separate diagnostic-log archive of the SeeTheBug client’s own logs is also appended to the package unencrypted; we redact credential-shaped values from it before it is written, but it is not covered by payload encryption.

The practical consequence: please do not put confidential information in the title of a capture. Treat it as a subject line that we can see.

Where the UK or EU GDPR applies to our own processing:

  • Performance of a contract — creating and running your Account, authenticating you, and providing the service.
  • Legitimate interests — keeping the service secure and available, preventing abuse, diagnosing faults, responding to your enquiries, and keeping a record of a sign-up we had to decline for regional reasons so that we can tell the person when that changes (section 5). We rely on this only where it does not override your rights, and you may object at any time.
  • Consent — where you have given it, for example by submitting a demo request. You may withdraw it at any time.
  • Legal obligation — where we must retain or disclose something by law.

For capture package contents we act on our Customer’s instructions; the Customer is responsible for establishing its own legal basis (see section 14).

9. What we do, and do not, do with this data

We use the data in section 5 to operate the service, authenticate Authorized Users, send transactional email such as verification, invitation and password-reset messages, respond to enquiries, keep the service secure, and diagnose problems.

We do not:

  • sell personal data, or share it for cross-context behavioral advertising;
  • use capture package contents for our own purposes, including training machine-learning models;
  • run advertising, analytics or session-recording tools on this website or in the Portal;
  • access capture package contents except where a Customer asks us to help with a specific support problem, or where we must in order to keep the service running.

10. Sharing, and our sub-processors

We share personal data only with the service providers we need in order to operate, and they act on our instructions. The current list, and what each one does, is published at Sub-processors.

We may also disclose data where we are legally required to, or to establish or defend legal claims. We will not do so more broadly than the request requires.

11. International transfers

The service runs on Microsoft Azure in the United States, and capture packages are uploaded directly there. Account data and capture packages are stored in the United States.

For Customers and End Users in the EEA or the UK, transfers to our US hosting are covered by Microsoft’s certification under the EU–US Data Privacy Framework and by the Standard Contractual Clauses in our agreement with Microsoft.

We administer the service from Israel, which the European Commission recognizes as providing an adequate level of data protection, so no additional transfer mechanism is required for that access.

12. How long we keep things

Account data is kept for as long as the Account is open. If an Authorized User is removed, a limited record is retained so that the Account’s history remains coherent; that record is erased when the Account is closed.

Capture packages are kept until they are deleted. There is no automatic expiry. A Customer can delete a capture at any time, which removes both the payload and its diagnostic-log archive from storage. When an Account is closed at the Customer’s request, we delete the Account and everything belonging to it, including the retained records of removed users and all stored capture packages.

We would rather state this plainly than imply a schedule we do not operate: because deletion is Customer-driven, a capture will remain in storage indefinitely until someone removes it or the Account is closed. Customers with a retention obligation of their own should delete captures once they have finished with them. We intend to add configurable automatic expiry.

Server logs rotate daily and roll over at 10 MB, with up to 50 files retained.

Declined EEA/UK sign-up records persist in two places with different lifetimes: the server log entry ages out with the rotation above, but the notification sent to our support inbox stays there until we delete it. We keep those notifications only until the Service becomes available in your region and we have contacted you, and we will delete yours sooner on request.

To close an Account and have its data erased, write to support@seethebug.com from an Account administrator’s address.

13. Security

  • All traffic between the Client, the Portal and our API runs over TLS.
  • Data at rest is encrypted by our hosting provider.
  • Capture payloads can additionally be encrypted end-to-end so that only the Customer can read them (see section 7).
  • Passwords are hashed with Argon2id using a per-password salt. We never store or log a password in a readable form.
  • Access to the Portal is role-based, and sessions use short-lived access tokens.
  • Authentication endpoints are rate-limited and accounts lock temporarily after repeated failed sign-in attempts.
  • Values that look like credentials are masked before anything is written to our logs or to the diagnostic-log archive in a capture package.

No service can promise perfect security. If we become aware of a breach affecting personal data we will notify affected Customers without undue delay, and regulators where the law requires it.

14. Your rights

Depending on where you live, you may have the right to access the personal data we hold about you, to have it corrected or erased, to restrict or object to how we use it, to receive a copy in a portable form, and to withdraw consent where we relied on it. You may also complain to a data-protection authority.

To exercise any of these, write to support@seethebug.com. We will not charge you, and we will respond within the period the applicable law requires. We may need to verify your identity first.

If you are an End User, please contact the vendor whose support team asked you to record the issue. We hold no direct relationship with you and often cannot identify which capture relates to you without the vendor’s help. The vendor decides what is collected and is the right party to answer. If you contact us instead, we will help where we can and will pass the request to the relevant Customer.

15. Children

The service is a business tool and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child’s data has reached us, write to support@seethebug.com and we will delete it.

16. Browser storage — we do not use cookies

This website and the Portal set no cookies, and there is nothing to consent to. There is no analytics, no advertising and no tracking of any kind.

The Portal does use your browser’s local storage for two things: the sign-in info that keeps you signed in, and a small number of interface preferences such as whether the sidebar is expanded. If you do not select “remember me”, the sign-in info is held in session storage and disappears when you close the tab. Signing out clears it. None of this is shared with anyone.

17. Changes to this policy

If we change this policy we will update the date at the top of this page. For changes that materially affect how we handle personal data, we will notify Account administrators by email before the change takes effect.

18. Contact

Questions, requests and complaints: support@seethebug.com, or [TRADER LEGAL NAME], [US BUSINESS ADDRESS].

If you are in the EEA or the UK and are not satisfied with our response, you may complain to your national data-protection authority.