Skip to content
DEIV IntelligenceLegal & Privacy

Legal & Privacy

Data & Security

Version 1.1 · Last updated

Draft: some details are still pending These pages describe how DEIV works today, based on a technical review of its code. Items marked PENDING must still be provided by the operator, and the texts have not yet been reviewed by a lawyer.

This page describes the security measures that are actually in place in DEIV, the limits you should know about and how to report a vulnerability. DEIV holds no security certification.

What the access code is, and what it is not

DEIV is protected by one access code shared by all visitors. It keeps casual visitors out, but it is a convenience gate, not strong security: anyone who has the code can sign in, and there are no individual accounts. Because of that, DEIV cannot tell apart two people who use the same browser.

Measures in place

  • Sign-in is checked on the server. Every page and request needs a valid session, except the sign-in screen and its files, these legal pages and a health check used by the host. The operator signs in on the same screen with a separate secret credential, and only the server decides, from the credential alone, whether a sign-in is the operator's or a visitor's. The operator's credential has its own protection: after 3 wrong attempts from one client a growing wait starts, and a global ceiling limits wrong attempts from unknown clients. The operator's own tools can send the same credential as a token; wrong tokens are counted and slowed down too.
  • The session cookie is HttpOnly (scripts cannot read it), Secure (sent only over HTTPS) and SameSite=Strict. It is signed by the server so that it cannot be forged, it expires after 24 hours (after 8 hours when the operator signs in), and signing out ends it on the server too: a copy of a signed-out cookie is refused, even after a restart.
  • Password guessing is slowed down: each wrong attempt is delayed, repeated failures from one client cause a growing wait of up to 15 minutes, and a global ceiling limits failed attempts from unknown clients together. Browsers and connections that recently signed in successfully are not held by that ceiling, so attackers cannot lock them out.
  • The operator's console uses a separate credential and a separate cookie. The visitor access code never grants access to it.
  • Actions that change data shared by all visitors, such as refreshing game data or re-checking the ranking source, are reserved for the operator, and visitors' requests for live game prices are limited.
  • Requests that change anything are protected against cross-site request forgery with same-origin checks (and, for app requests, a required header).
  • Every page is sent with security headers: a Content Security Policy that only allows DEIV's own scripts, a policy that blocks the camera, microphone, location, payment and USB features, HTTP Strict Transport Security in production, no framing by other sites, no content-type sniffing and no referrer sent to other sites.
  • DEIV loads no third-party scripts; all its code is served by DEIV itself.
  • Visitors are kept apart: a workspace on the server can only be used together with the session that opened it, and the data in your workspace is not written to the server's database or disk, and normally not to its logs (see the Privacy Policy).
  • The operator's views show only anonymous totals, pseudonymous tags for security events and error records without request details.
  • Server answers are marked as not to be cached, and the offline copy never stores server answers or the sign-in page.
  • Request sizes are limited: compressed request bodies are refused before anything else, ordinary requests are capped at 1 MB, and the copy of your workspace has its own size cap, a memory budget and per-session limits. Invalid numeric inputs are rejected.
  • DEIV's requests to Sim Companies and SimcoTools are read-only, go only to approved addresses, carry no cookies and are rate-limited.
  • The server runs without administrator (root) privileges, and its software dependencies are installed only in pinned versions with verified checksums.

According to its data processing agreement, the hosting provider (Railway) encrypts data in transit and at rest and applies access controls on its side.

Known limits

  • If you close the browser without signing out, your session stays valid until it expires (at most 24 hours after sign-in) and the server keeps its temporary copy of your workspace until 30 minutes after your last request. Sign out to end both at once.
  • Signing out keeps your workspace in this browser on purpose. On a shared device, the next person who signs in with the access code may see it. Remove your data before you leave a shared device.
  • Most results derived from your data are deleted together with the server's copy of your workspace, but some cached intermediate results can stay in the server's memory until they are replaced or the server restarts.
  • Local Data & Backup › Remove deletes your workspace, but not yet the last inputs of some calculators and tools, which can contain figures from your company. Clear this site's data in your browser to remove them too.
  • Some further improvements found by a security review are still in progress.
  • No system is perfectly secure, and DEIV has not been certified by any third party.

What you can do

  • Keep the access code to yourself.
  • Download backups of your workspace and keep them safe: they contain your company data.
  • On a shared or public device, use session-only mode, sign out and clear this site's data when you finish.

Reporting a vulnerability

If you believe you have found a security problem, please report it privately to the operator with enough detail to reproduce it, and allow reasonable time for a fix before you disclose it. Do not access other people's data, do not disrupt the service and do not test more than you need to show the problem.

Report it through the contact form on the Contact page (type “Security report”), without passwords, tokens or other people's data, or write to billbuffett on Discord.

If something goes wrong

If a security incident affects personal data, the operator will assess it and, where the law requires it, notify the competent authority and the people affected.