Security and data protection at Diaposi.

Last reviewed: 4 November 2026

Diaposi applies security measures according to the data, feature and risk involved. This page describes controls found in the reviewed application code and the operating commitments that must accompany production. No internet service can promise absolute security.

This is a public overview. It intentionally excludes credentials, internal network details, detection rules and recovery procedures that could weaken the service if disclosed.

1. Security principles

• Collect and retain only data required for the requested feature, legal compliance and proportionate security.
• Use separate credentials and permissions for accounts, session hosts, participants and report readers.
• Keep authentication credentials out of browser-readable JavaScript where the feature permits it.
• Treat uploaded presentations, links, participant text and AI output as untrusted input.
• Limit production access to authorised people with a documented operational need.
• Review incidents, vulnerabilities and material architecture changes according to their risk.

2. Identity and access

Signed-in sessions use random server-side credentials delivered in HttpOnly cookies. Host and participant access use separate session-scoped credentials; completed reports are protected either by a report capability or by signed-in account membership and permission checks. Passwords are stored using a memory-hard password hashing function rather than in readable form. Google or Microsoft sign-in, when enabled, uses state binding and PKCE protections.

The application applies authorisation checks to protected account, session, file and report operations. Session links and recovery codes can still grant access to the person holding them; users must protect them and revoke or rotate access when exposure is suspected.

3. Data in transit and on devices

The production design terminates HTTPS at the service boundary and marks sensitive cookies Secure. Security headers restrict framing, object content, script sources and cross-origin resource use. Browser and API requests are subject to origin controls and request-size limits.

Live-session personal notes remain in that participant's browser. Notes synchronised to a signed-in learning journey are encrypted in the browser with an authenticated encryption algorithm before storage. The readable key remains on the user's device; a recovery method protects a wrapped copy. Diaposi cannot recover readable notes without the required user-held secret.

Measured against the live host: TLS 1.0 and 1.1 are refused, TLS 1.2 is accepted, and HTTP/3 is offered, which requires TLS 1.3. Responses carry HTTP Strict Transport Security for one year including subdomains, a content security policy, nosniff, SAMEORIGIN framing and a no-referrer policy.

4. Application and upload isolation

The reviewed deployment configuration runs the application with reduced operating-system privileges, a read-only application filesystem and resource limits. Presentation conversion is separated from the network-facing application, denied network access, constrained by resource limits and given only the files needed for the conversion. Uploads are checked for permitted type, file signature and size before processing.

The service also uses request validation, rate limiting, same-origin checks, non-verbose production errors and bounded logs. These controls reduce risk but do not replace patching, monitoring, dependency review and independent testing.

5. Artificial intelligence

AI features are separated from core access controls. The application sends only the input needed for the requested generation or evaluation, validates returned structures and does not intentionally include presentation speaker notes. AI output is untrusted and must be reviewed by a person before it is used for educational decisions.

6. Logging, monitoring and retention

The application records limited access, error, security and product-operation events to diagnose failures, prevent abuse and investigate incidents. Reviewed application retention is generally 30 days for access and error logs and up to 12 months for session events. Sensitive route segments are redacted from access logs and URL query strings are excluded.

Operational access to logs should be restricted and audited. Logs must not become a secondary store for presentation content, passwords, full credentials or encryption recovery secrets.

7. Backups and service recovery

Diaposi takes its own backups rather than relying on the database provider, which runs none for this deployment, so these are the only copies that exist. A backup is encrypted with AES-256-GCM inside the process that creates it, so the readable export never exists as a file, and it is kept on a generational rotation and mirrored to storage in the Netherlands. The uploaded documents are mirrored separately from the database, because a database restored without them would describe sessions whose slides are gone. A restore has been carried out end to end and recorded.

8. Service providers and personnel

Five providers carry production: one application host, one managed database, one backup store, one mail provider and one AI provider. Each is named in the privacy policy's subprocessor register with what it does and where; every server that holds Diaposi's data is inside the European Economic Area. The services you can call from inside the application (YouTube, Google Drive, Dropbox, SoundCloud, GIPHY) are named there too and receive nothing until you use them. The application host accepts SSH by key alone, with password and keyboard-interactive authentication disabled, a firewall that allows only HTTP, HTTPS and SSH, and automatic banning of repeated failed attempts. Diaposi is run by its president, who alone holds those keys and accounts; no contractor, agency or other member of staff has production access.

9. Vulnerability management

Dependency and container-image scanning run on every release and block it: the pipeline audits the Node dependencies at high severity, audits the converter's Python dependencies, and scans both built images, failing the release on any fixable high or critical finding. No certification, audit opinion, penetration-test result or bug-bounty programme is claimed on this page.

Security-relevant dependencies and platform updates should be reviewed regularly. Material changes require proportionate code review and testing. High-risk findings should be prioritised according to exploitability, affected data and impact, then verified after remediation.

10. Incident response

Suspected incidents must be contained, investigated, documented and remediated. Where Diaposi acts as controller, it will notify the competent authority within the period and risk conditions required by Articles 33 and 34 GDPR, including notification to affected people where a breach is likely to create a high risk. Where Diaposi acts as processor, it will notify the responsible customer without undue delay and support that customer's assessment.

Diaposi's president is the responder for every incident and is reachable at security@diaposi.com. A report is acknowledged within one working day. Where an incident is a personal data breach, the supervisory authority is notified within 72 hours of Diaposi becoming aware of it, and affected people are told directly where the breach is likely to present a high risk to them. Where Diaposi acts for an institution, that institution is informed without undue delay so it can meet its own duty. Evidence is preserved before any clean-up, and every incident is recorded with what happened, what was done and what changed afterwards.

11. Report a security issue

Report a suspected vulnerability privately to security@diaposi.com. Include the affected page or feature, reproducible steps and impact. Do not access another person's data, use social engineering, interrupt a live class, degrade the service, retain personal data or publish the issue before Diaposi has had a reasonable opportunity to investigate.

Diaposi will acknowledge good-faith reports when operationally possible. This statement does not create a bug bounty, authorise unlawful testing or promise a payment.

12. Customer responsibilities

• Use unique credentials and protect session, report and recovery links.
• Upload only material you are authorised to process and avoid unnecessary sensitive data.
• Configure participant visibility appropriately and tell participants what the institution is doing with their data.
• Review AI output and never use Diaposi as the sole basis for admission, grading, discipline or another significant decision.
• Remove former staff access, export only when necessary and secure exported files outside Diaposi.
• Report suspected compromise promptly.

For the data covered by these controls, read the Privacy Policy.