This statement is for IT, information governance and data protection teams reviewing Oriel, a desktop app for qualitative data analysis. It explains where data goes, why no Data Processing Agreement is needed, and how Oriel is built and maintained. For how I handle the small amount of personal data I do receive, see the privacy policy.
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:
| Action | Endpoint | What is sent |
|---|---|---|
| Check for updates (by hand; startup check off by default) | https://justinaunger.com/oriel-latest.json | App name and version (in the user agent) |
| Download a transcription, AI or search model | https://huggingface.co (fixed, version-pinned files) | Nothing from projects |
| Download the local AI helper program | https://github.com (pinned llama.cpp release) | Nothing from projects |
| Check for or download ontology updates | https://github.com | Nothing from projects |
| Add a reference by DOI | https://doi.org | The DOI only |
| Capture a web page | The address the user types | Nothing from projects |
| Use Oriel Quotes in Word | https://justinaunger.com/oriel-quotes/ and https://appsforoffice.microsoft.com | Nothing from projects |
| Connect to a private coding service | Your organisation’s server | Encrypted coding; encrypted source files only if a user chooses to share them |
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 are checked automatically.
- 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. 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 justinaaunger@gmail.com. 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.
8. 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.
9. 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 justinaaunger@gmail.com.