Vulnerability Disclosure Policy

Cyberinfra Limited ("ScreenJournal", "we", "us") builds workforce-monitoring software that handles sensitive personal data, so we take security research seriously. This policy explains how to report a security vulnerability to us, what is in and out of scope, and what you can expect in return. It is the policy referred to in §9 of our Security page.

1. Introduction and good-faith safe harbour

If you believe you have found a security vulnerability in a ScreenJournal service, we want to hear about it. We will work with you to understand and resolve the issue.

Safe harbour. If you make a good-faith effort to comply with this policy during your research, we will:

• treat your research as authorised in respect of the in-scope assets;
• not take or support legal action against you for good-faith research within scope, including accidental, good-faith breaches of this policy; and
• work with you to understand and resolve the issue, and recognise your contribution (with your permission).

This safe harbour covers only legal claims that are ours to bring. It does not bind third parties, including our subprocessors, and it does not cover activity that breaks the law or the rules of engagement in §5. If you are unsure whether an action is authorised, ask us first (see §4) before going further.

2. Scope

This policy covers ScreenJournal's production services:

• the web application at screenjournal.ai/app;
• the marketing website at screenjournal.ai;
• the production APIs that serve the web and desktop apps: dev-auth.screenjournal.ai (authentication and accounts), dev-collector.screenjournal.ai (activity data and media) and dev-report.screenjournal.ai (reports). Despite the dev- prefix, these hostnames serve the live service and are in scope;
• the MCP server for connected AI tools at mcp-beta.screenjournal.ai;
• the ScreenJournal desktop application for macOS and Windows; and
• the desktop app's update feed, the public GitHub releases repository MattPM-ai/screenjournal-releases, including the integrity of the releases it serves.

If you are unsure whether a target is in scope, ask before testing.

3. Out of scope

The following are out of scope. Please do not test for or report them; we will generally close such reports without action:

• Denial of service (DoS or DDoS), volumetric testing, or any resource-exhaustion or stress testing.
• Social engineering (phishing, vishing, smishing, pretexting) of our staff, our customers or their employees.
• Physical attacks against offices, people, data centres or hardware.
• Staging and development environments, local builds, and any host not listed in §2.
• Retired or not-deployed services that are no longer part of the production service.
• Spam or content-injection abuse of the invitation, notification or report-sharing features.
• Findings that need an already-compromised account, a rooted or jailbroken device, a man-in-the-middle position you already control, or physical access to an unlocked device.
• Vulnerabilities in the platforms of our providers: Hetzner, Cloudflare, Amazon Web Services, Google Cloud, Paddle and Vercel (see our Subprocessors page). Issues in those providers' own platforms are out of scope here; please report them to the provider concerned. A misconfiguration of our own use of those platforms is in scope.
• Output of automated scanners without a demonstrated, exploitable impact.
• Missing best-practice hardening with no demonstrated vulnerability, for example missing security headers, SPF/DKIM/DMARC settings, cookie flags, TLS cipher preferences, version disclosure or verbose error messages.
• Self-XSS, login or logout CSRF, clickjacking on pages with no sensitive state-changing action, and tabnabbing without a demonstrated impact.
• Rate-limiting or brute-force concerns without a working exploit.

4. How to report

Email support@screenjournal.ai with the subject line "Security report". A dedicated security mailbox will be added here once it is staffed.

To help us triage quickly, please include:

• a clear description of the vulnerability and its potential impact;
• step-by-step reproduction instructions;
• the affected asset (hostname, endpoint or desktop-app version) and your test environment;
• a proof of concept: screenshots, request and response captures, or a short video;
• whether you accessed, changed or could view any data that was not your own (see §5); and
• how you would like to be credited (name or handle), or that you wish to remain anonymous.

We do not currently publish a PGP key; ask for a secure channel in your first message if you need one.

5. Rules of engagement

To stay within safe harbour you must:

• test only against your own accounts, or test accounts you are explicitly authorised to use;
• not access, change, delete or take data belonging to any other user or organisation beyond the minimum needed to prove the issue. ScreenJournal holds sensitive data about the people our customers monitor; do not violate the privacy of those members in any way;
• stop as soon as you reach personal data that is not yours, do not download or keep it, and report it to us straight away;
• use the minimum interaction needed to demonstrate the issue, and delete anything you retrieved once you have reported it;
• not degrade, disrupt or overload the service (no DoS, no high-volume automated scanning);
• not use social-engineering or physical techniques (see §3); and
• comply with all applicable laws, and give us reasonable time to fix the issue before any public disclosure (see §7).

6. Our commitment

When you report in line with this policy, we will:

• acknowledge every report;
• triage and validate the report and keep you informed of its status at reasonable intervals;
• work to fix confirmed vulnerabilities on a timeline set by their risk; and
• with your permission, credit you once the issue is resolved.

Recognition only. We do not run a paid bug-bounty programme and offer no monetary reward. Nothing in this policy promises one.

7. Coordinated disclosure

We ask that you practise coordinated disclosure:

• do not publish a vulnerability, or share details that could put customers at risk, until we have fixed it and agreed the timing with you;
• as a default, allow ninety (90) days from your report before any public disclosure, or less where a fix has shipped and we have agreed the timing together; and
• coordinate the content and timing of any write-up with us so that affected customers are protected.

If a fix is taking longer than expected, contact us and we will agree a reasonable timeline with you rather than have you disclose on your own.

8. The security.txt file

We publish machine-readable security-contact information at https://screenjournal.ai/.well-known/security.txt, following RFC 9116. It names our security contact and points to this policy. Its expiry date is renewed annually, so the file never goes stale.

---

Cyberinfra Limited, Isle of Man. This policy is versioned; changes are listed on our Legal page. Related documents: Security · Subprocessors · Data Protection Contacts.