Incident Response

Velnode Browser  ·  a product of Dignity New Zealand Limited

_{Operations  |  Version 1.1  |  Last updated 2026-06-18}

Incident Response

Document type: Operations Owner: Dignity New Zealand Limited Applies to: Velnode Browser v1.10 and later Last updated: 2026-06-18 Document version: 1.1 Status: Approved

Purpose

This document describes how Dignity New Zealand Limited responds when a security or safety incident is reported in Velnode Browser, including vulnerability reports, plugin compromise, brand abuse, and data-protection complaints.

Scope

This procedure covers:

• Security vulnerabilities in Velnode itself or in plugins distributed through the official Plugin Manager.
• Compromise of the build / release pipeline.
• Material misuse of the Velnode brand or the Dignity New Zealand Limited brand.
• Privacy complaints under the New Zealand Privacy Act 2020, the EU GDPR, or any equivalent law.

It does not cover incidents on third-party websites you visit using Velnode, incidents at third-party AI providers you connect under your own credentials, or device-level malware unrelated to Velnode.

1. How to report an incident

Reports should be sent to [email protected] with one of the following subject lines:

A useful report includes: the Velnode version, the operating system, a short description of the issue, and any reproduction steps or evidence available.

2. Acknowledgement window

We aim to acknowledge a valid report within two (2) business days of receipt. The acknowledgement does not imply we have validated the issue; it confirms we have it and have assigned a tracking number.

For privacy complaints, the formal response window is thirty (30) days as required by the New Zealand Privacy Act 2020 and the GDPR.

3. Roles

Inside Dignity New Zealand Limited at the company's current scale, multiple roles may be discharged by the same person; the roles still exist conceptually so each step in this procedure has a clear owner.

4. Triage

The Incident Coordinator triages the report against four severities:

Severity is reviewed once root-cause is understood. We do not downgrade severity to avoid expedited release.

5. Investigation and containment

Steps the Engineering Lead takes:

1. Reproduce the issue locally against a clean checkout at the affected version.
2. Confirm the scope: which Velnode versions are affected, which platforms, which plugins.
3. If a canon architecture_flag is at risk, run the canon hash audit to verify the manifest state.
4. If the issue is in the AI / voice / permissions path, run the security review and AI-prompt review passes over the relevant diff before fixing.
5. Design the smallest fix that resolves the issue without regressing other behaviour.
6. Add a regression test where feasible. Where a test would require fragile mocking, document the manual verification step in the release notes.

If exploitation is suspected to be active, an interim containment action may be taken before the patched release:

• Removing an affected plugin from the official Plugin Manager.
• Publishing an advisory at [email protected] and via the project repository.
• Revoking publisher credentials for a compromised plugin author.

6. Disclosure

For security disclosures, the default disclosure window is ninety (90) days from acknowledgement, or seven (7) days after a Critical fix is released, whichever is sooner. We will extend the window on reasonable request from the reporter where there is good cause.

Disclosure includes:

• A short advisory in the release notes for the patched version.
• A credit to the reporter (with their consent).
• Where appropriate, a longer write-up in the project repository's security advisories.

We do not silently patch security issues. A patched issue is always disclosed at the level of detail necessary for users to assess their exposure.

6a. Cloud account incident scenarios (Phase 21 Stage 1)

The following scenarios are specific to the velora-account Cloudflare Worker and D1 database introduced in Phase 21 Stage 1.

D1 database compromise

What an attacker obtains: email addresses, per-row auth_verifier_salt + auth_verifier (PBKDF2-HMAC-SHA256 of a scrypt-derived auth_hash), KDF salts, and opaque AES-256-GCM blobs they cannot decrypt.

What an attacker does not obtain: passwords, KEKs, plaintext data keys, browsing history, notes, bookmarks, timeline events, or vault contents.

Response steps:

1. Treat as a High incident (severity may be upgraded to Critical if evidence of active exploitation exists).
2. Rotate the ENUM_SALT Worker secret (wrangler secret put ENUM_SALT) to invalidate decoy-salt predictability.
3. Force-expire all active sessions by truncating the sessions D1 table (all users will need to sign in again).
4. Notify affected users by email: explain what was exposed (email + server-hashed verifiers + opaque blobs) and what was not (plaintext data).
5. Advise users to change their Velnode account password as a precaution. Changing the password re-derives the KEK and rewraps the data key, rendering the stolen auth_verifiers worthless for future logins.
6. File a breach notification with the Office of the Privacy Commissioner (New Zealand) if the breach is likely to cause serious harm, and with relevant EU/UK supervisory authorities where Article 33 GDPR applies.

Encrypted blob exfiltration (without D1 breach)

Scenario: An attacker obtains the contents of the wrapped_data_key or wrapped_data_key_recovery blobs without the full D1 row.

Impact: The blob is AES-256-GCM ciphertext. Without the KEK (derived from the account password + kek_salt) or the recovery_KEK (derived from the recovery phrase + recovery_salt), the blob is computationally infeasible to decrypt. No user data is exposed.

Response: Treat as a Medium incident. Investigate the exfiltration vector; no forced password reset is required unless the KDF salts were also obtained.

Auth-hash brute-force attempt

Scenario: An attacker attempts to brute-force valid auth_hash values against the login endpoint.

Response steps:

1. The per-IP + per-email rate limiter (10 attempts/min) is the first line of defence and should be confirmed as operative.
2. If a specific IP is running sustained attacks, coordinate with Cloudflare to block it at the edge (WAF rule or IP block).
3. If a specific email account is targeted, the per-victim-email forgot-reset cap (5/hour, IP-independent) limits reset-link flooding.
4. Investigate whether any sessions were created for affected accounts during the attack window. Force-expire suspect sessions.
5. Notify the affected user if their account appears specifically targeted.

Worker or ENUM_SALT secret exposure

Scenario: The ENUM_SALT secret is exposed (e.g., in a log, a source leak, or a Worker debug session).

Response: Rotate immediately (wrangler secret put ENUM_SALT). This changes the decoy salts returned for unknown emails at /account/prelogin, which is a low-impact, log-only change for legitimate users. No forced user action is required.

7. Notifications

For incidents that involve a personal-data breach reportable under the New Zealand Privacy Act 2020 or the EU GDPR, the Privacy Officer ensures:

• Notification to the Office of the Privacy Commissioner of New Zealand where the breach is likely to cause serious harm.
• Notification to the affected supervisory authority in the EU where Article 33 applies.
• Notification to affected users where the law requires it.

As of Phase 21 Stage 1, the realistic surface for a reportable personal-data breach has expanded beyond the support mailbox to include the Cloudflare D1 database. A D1 breach exposes email addresses and server-hashed authentication verifiers — not plaintext passwords or browsing data — but notification obligations may still apply depending on jurisdiction and likely harm assessment. See §6a above for the specific response procedure.

8. Records

We keep an internal incident log with the following fields per incident: tracking number, severity, date received, date acknowledged, date contained, date fixed, date disclosed, reporter (with consent), summary. The log is retained for at least three (3) years.

9. Post-incident review

For every Critical and High incident, we hold a post-incident review within two (2) weeks of disclosure. The review answers four questions:

1. What happened?
2. Why did it happen?
3. What did we change to prevent recurrence?
4. What did we learn about the response itself?

Outputs feed into the release notes and into the Security Posture document where applicable.

10. Review cadence

This document is reviewed every Velnode major release and after each Critical incident. The "Last updated" date at the top of this document reflects the most recent revision.

11. Contact

Dignity New Zealand Limited Attention: Incident Coordinator Email: [email protected]

Document maintained by Dignity New Zealand Limited. Questions: [email protected].