Data processing statement.

1. Roles under UK GDPR and EU GDPR

• Your organisation is the controller of all research data used in Oriel.
• Oriel’s developer (Justin Aunger) provides software that you install and run yourself. I don’t host, receive, store, access or otherwise process your research data, so I’m not a processor for your organisation.
• No Data Processing Agreement is needed. Article 28 requires a contract only when a processor handles personal data on the controller’s behalf. Using Oriel is like using any other locally installed software: the processing is done by your organisation, on its own computers.

2. Where data is stored and processed

• Each project is a single file on the user’s computer, in a folder the user chooses. Automatic backups and the error log are also kept on that computer.
• Transcription, text recognition, search by meaning and local AI all run on the user’s computer.
• If people collaborate through a shared folder, the project is stored wherever your organisation’s folder provider (such as OneDrive, SharePoint or a network drive) keeps it, under your agreements with that provider.
• If people collaborate through a private coding service, your organisation runs the server. Coding is encrypted on each computer before it’s sent, and source text, code names, memos and coder names aren’t sent. The server’s operator can’t read what is shared.

Subprocessors: none. No research data reaches me or anyone working for me.

3. Telemetry and diagnostics

Oriel has no telemetry, usage analytics, crash reporting or account. The error log stays on the user’s computer, with quoted text, file names, folder locations and email addresses removed. It’s only shared if the user chooses to send it.

4. Network connections

Oriel works fully offline. It connects only when the user takes one of these actions:

To prevent all internet use, you can block Oriel at your firewall. Every core feature keeps working. Models needed for transcription or local AI can be downloaded once on a connected computer.

5. Artificial intelligence

• Oriel never sends research data to a third-party or cloud AI service.
• Local AI (coding suggestions and search by meaning) and automatic transcription use open models that run on the user’s computer. The local AI helper program only accepts requests from Oriel on the same computer, needs a random key, and doesn’t connect to the internet.
• Local AI is off by default in every project. Suggestions are kept for the user to review and only become coding once a person accepts them.

6. How Oriel is built

• The core is written in Rust, a memory-safe language, and unsafe code is forbidden across the codebase.
• The interface runs under a strict Content Security Policy that stops it making network connections. Only the app’s core can connect, and only for the actions listed above.
• Every release must pass static analysis (with warnings treated as errors) and a large automated test suite. Tests also check that newer versions still open files made by older ones.
• Third-party components come only from approved registries, and their licences and known vulnerabilities are checked automatically (see the dependency audit).
• Every downloaded model or helper program is checked against a fixed SHA-256 hash and size before it’s used.
• Projects aren’t encrypted by Oriel. Use full-disk encryption (BitLocker or FileVault) and your usual device controls.

7. Dependency audit

Oriel is built on open-source libraries. I check every one of them against public vulnerability databases, licence rules, and trusted sources. The results below are for Oriel 0.97.1 beta on macOS and Windows, checked on 10 November 2026.

• 0Open vulnerabilities in the Rust libraries Oriel ships
• 0Vulnerabilities in the JavaScript packages Oriel ships
• 1Moderate issue in a developer-only lint tool, which isn’t shipped

Nine notices from the Rust advisory database were reviewed by hand and recorded with a reason. Four concern unpacking zip archives with an older library that Oriel only uses to write spreadsheets. Five say that a library is no longer maintained, with no known vulnerability. They’re listed in full below.

Rust libraries: cargo-deny

Oriel’s core, file handling, storage, and collaboration are written in Rust. I check its 744 third-party libraries, covering every platform and optional feature, with cargo-deny 0.20.2. It compares them with the RustSec advisory database, which it downloads fresh for each run. All four checks pass.

• Advisories: no open vulnerability in any library, after the nine reviewed notices below.
• Licences: every library uses a licence on an approved list of permissive and weak-copyleft licences, such as MIT, Apache 2.0, BSD, and MPL 2.0.
• Sources: every library comes from the official crates.io registry. Code from other registries or Git repositories is refused.
• Bans: no banned library. 71 notes say that two versions of the same library are present, which affects app size rather than security.

Reviewed notices

Each notice below is recorded in Oriel’s deny.toml with its reason, so the check fails if a new advisory appears. I review them again whenever a library is updated.

JavaScript packages: npm audit

Oriel’s interface and its Word add-in are built with JavaScript tools. I check both with npm audit (npm 11.17), which compares installed packages with the GitHub Advisory Database.

• Oriel interface: the 34 packages that ship inside the app have no known vulnerabilities.
• Word add-in: the add-in ships no third-party npm packages. Every package it lists is a build or test tool.

Across the development tools, npm audit reports 10 moderate findings in each project. All 10 come from one issue, GHSA-g3hv-75wg-m249, a way to slow down the minimatch file-pattern library with a crafted pattern. minimatch reaches the project only through ESLint and typescript-eslint, which check code style on developers’ computers. They aren’t part of the app or the add-in, and they don’t see user data. The only fix npm offers is an older major version of ESLint, so I’ll update when ESLint releases a fixed version.

Run the checks yourself

From a copy of the source, these commands give the results above.

cargo deny check
cd ui && npm audit --omit=dev
cd word-addin && npm audit --omit=dev

These results describe Oriel’s dependencies on the date shown. New advisories are published all the time, so I run the checks again before each release and update this section.

8. Updates and vulnerabilities

• Oriel never downloads or installs updates by itself. A new version is a new installer from justinaunger.com, which your IT team can test and deploy as usual. On Windows, Oriel installs for all users of the computer.
• Each release lists its changes, including security fixes.
• To report a vulnerability, email [email protected]. I’ll acknowledge it within 5 working days, fix serious issues as a priority, and publish a corrected version with a note in the changelog.
• If a flaw in Oriel could have exposed users' data, I’ll say so on this website and in the release notes, so that controllers can judge whether it needs to be reported.

9. Limits you should know about

• Oriel is in beta and is provided free of charge, as is, without a service level agreement.
• I hold no formal security certification (such as ISO 27001 or Cyber Essentials), and Oriel, including the private coding service, hasn’t had an independent penetration test.
• Installers aren’t yet code-signed by Apple or Microsoft, so your endpoint controls may need an exception.

10. Help with your assessment

The chapter "Data protection and privacy" in Oriel’s user guide (Help → Oriel User Guide) describes every case in more detail, with advice for users on storage, backups, sharing and anonymisation. It may help with your data protection impact assessment. For questions, email [email protected].