Data you control

Data you control

How Omniris decides who can sign in, what each person can see and change, how your files are encrypted, where your data is kept on each edition, and what happens to it when you delete it.

Summary

Drone data is often sensitive: the inside of a plant, the roof of a home, a crime scene, a power line. The people who own it need to know exactly who can open it, and to be able to prove it. Omniris is built so that access is never assumed. Every request to see, download or change a file is checked against your permissions at the moment it is made, and the files you choose to protect are encrypted so that the key to open them is released only to the people on their access list, and to Omniris itself for the work you ask of it.

Signing in

Omniris offers several ways to sign in. Most of them involve no password at all, so there is no password to steal, reuse or forget.

A passkey can also create a new account: you confirm your email address with a code, then your device makes the passkey. The emailed code is the way back in if you lose every passkey. Codes are sent only to accounts that were created with a code or a passkey, never to an account that signs in with Google, Apple, Microsoft or Facebook.

On-premises sites choose which of these methods to offer, and the change applies within a minute. At least one method that a brand-new person can use must stay switched on.

How long you stay signed in

• In a browser on Omniris cloud and the data center edition, a sign-in lasts 31 days from the moment you sign in. Then you sign in again.
• On premises, a sign-in lasts 31 days and keeps extending while you use it, so people working on a site that loses its internet connection are not signed out. The site can choose a different number of days.
• The desktop and phone apps use short-lived passes that renew in the background. Passes Omniris issues itself last 12 hours, and the pass that renews them lasts 30 days.
• Signing out ends the session in that browser straight away.

Stopping a sign-in

• Guessing is slowed down. On premises, 10 wrong passwords in a row lock that account for 15 minutes. Emailed codes are limited to 5 per address and 20 per network address every 15 minutes, and each code allows 5 tries.
• Nothing gives away who has an account. A wrong email, a wrong password and an unknown account all get the same answer, and "send me a code" says the same thing whether or not a code was sent.
• Deactivated accounts stop at once. A deactivated account can't sign in by any method, and any app or session it still holds is refused on its next request. Nothing it owns is deleted.
• Sign everyone out. On premises, the site can end every browser session, every app pass and every device key with one button, for example after a laptop is lost. The person who presses it stays signed in.
• Unpaid accounts are locked, not erased. On Omniris cloud and the data center edition, an account locked for a failed payment can still reach its billing pages to put things right.

Who can see and do what

Every account except a viewer's has a vault: its own private storage for files and folders. People who work together can also belong to an organization, which has a shared vault of its own. Each member of an organization is a manager, a pilot or a viewer, and one manager is its owner.

On-premises sites show the client role as Manager; what it can do is the same.

These rules are applied on the server, to every request, from the web app, the desktop app, the phone app and the API alike. Hiding a button is never the only thing standing between a person and a file. Removing someone from an organization, revoking their share or deactivating their account takes effect on their next request.

Folders, shares and snapshots

Access in Omniris belongs to folders. A file is reachable by whoever can reach the folder it is in, and a folder is reachable through one of these routes, checked in this order:

Access follows the folder, not its name. When a folder is moved, its access moves with it. A folder moved out of your organization's vault stops being reachable through the organization, and one moved in becomes reachable by its members. Creating a folder somewhere does not give you lasting rights over it: if you leave an organization, the folders you made in its vault stay with the organization.

Sharing with another account

You can share any folder in your vault with a share code: four groups of four letters and digits that the other person redeems in their own account. You choose what the code allows:

• You can only share what you are allowed to share. A share can never grant more than you have yourself, and a delivered snapshot can't be transferred on.
• Each time a code is redeemed, Omniris checks again that the person who made it may still share that folder. A code made by a deactivated account can't be redeemed.
• Revoking a share ends the recipient's access straight away, and then takes them off the key list of every protected file the share gave them, so encrypted copies they downloaded stop opening too. Revoking a snapshot also removes the copy from their vault. A recipient can give up a share themselves at any time.
• Creating a share and each time it is redeemed are recorded in the custody record of every file in the folder.

Public links

A public link opens a folder in any web browser, with no account. You choose whether it allows viewing only or downloading too, and you can add a password and an expiry date; a link made when you send a job's results to a client can also limit the number of views. A link's password allows 10 guesses from one network address every 15 minutes. Revoking the link cuts access at once. Only folders in your own vault can be published, except that organization managers may publish any folder of their organization. Organization pilots and viewers can't publish organization folders. The companion paper on sharing, delivery and integrations covers links in full.

Encryption in storage and in transit

There are two layers. The first, described here, covers everything you keep in Omniris. The second, protected files, adds encryption that travels with the file itself, for the files you choose.

On the way

• HTTPS on hosted sites. Omniris cloud and the data center edition are reached only over HTTPS, the encrypted form of the web. Your browser is told to use nothing but HTTPS for the site for a year, and the sign-in cookie is sent only over an encrypted connection.
• Straight to storage. Ordinary uploads and downloads don't pass through the Omniris application. Omniris checks your permission, then hands your device a signed link: a web address that works for one file, for a short time. Your device and the storage service talk to each other directly over HTTPS.
• Inside the cloud. On Microsoft Azure, the storage account refuses connections older than TLS 1.2 (the current standard for encrypted connections), and the application insists on an encrypted connection to its database. On Google Cloud, the application reaches its database through the built-in database connection Google provides for its cloud services, which Google encrypts.
• On premises, HTTPS is a choice made when the site is installed. Omniris includes a web server that provides it, with the site's own certificate or one it makes itself. Without it, the site answers on its local network over plain HTTP. Passkeys need HTTPS.

In storage

• Private by default. Storage is never open to the public. On Microsoft Azure, public access to stored files is switched off for the whole storage account. On Google Cloud, the storage bucket grants no public access, and access is controlled for the bucket as a whole, never file by file. Every file is fetched through a signed link that Omniris issues only after checking your permission.
• Encrypted by the cloud. The storage and database services Omniris uses on Microsoft Azure and Google Cloud encrypt everything they store, with keys the cloud provider manages. That is how those services work, and Omniris keeps it that way.
• On your own hardware. On premises and in the data center edition, files are kept on the site's own storage server. Omniris does not add disk encryption there. Protected files are encrypted wherever they are kept.
• Secrets Omniris keeps for you. Webhook signing secrets and the connections you make to Procore or Autodesk are stored encrypted, under a key kept apart from the database. Passwords are kept only as hashes. API tokens are kept only as a keyed hash, so the token itself can't be read back from storage, even by Omniris.

Protected files

For files that need more than permissions alone, Omniris can protect them. A protected file is rewritten as an encrypted OpenTDF file. OpenTDF is an open standard for encrypted files that carry their own access rules: the file says who may open it, and a separate key service holds the keys and hands one out only to a person on that list.

• The encryption. The contents are encrypted with AES-256-GCM, a widely used standard, in pieces of 1 MiB. Each piece has its own tag that shows if a single byte has been altered.
• A folder or a file. Protect a whole folder, or one file. Protecting a folder covers everything in it and everything that arrives later: uploads, copies, moved-in files and the results of processing. You need permission to change a folder to protect it.
• Visible to you. Protected files carry an Encrypted label, and large folders are encrypted in the background with progress you can follow.

Who can open a protected file

Each protected file has an access list. People join it in these ways, and each change re-encrypts the affected files for the new list:

• the person who protected it;
• a person who redeems a share of its folder;
• a job's client, while a pilot has the folder linked to that client's job (unlinking the job takes the client off again);
• the owner of the vault it is moved into, when a file moves to another vault. The previous owner is taken off unless they can still reach the file another way.

The Omniris service itself is always on the list as well. That is what lets it re-encrypt a file when its list changes, and serve a protected file on a public link you choose to publish (below).

Opening one: two checks, every time

Downloading a protected file gives you the decrypted original, through the same two checks. Removing protection from a file also needs both: your permission, and the key service's yes for you.

Protected files elsewhere in Omniris

The companion paper Evidence you can prove explains how a protected file's custody record proves that the encrypted copy and the original are the same evidence.

Your own keys

Who holds the keys decides who can, in the end, read the data. Where Omniris runs on your own hardware, the keys are made on your hardware and stay there.

Your own provider accounts. An on-premises site needs a few outside services: maps, address search, weather, email and Orion, the AI assistant. Depending on its plan, the site either lets Omniris make those calls on its behalf, so that no Omniris account key ever sits on the site, or uses its own accounts with those providers. Those account keys are entered on the site and stored there encrypted. On premises, you also register your own Procore and Autodesk applications for the integrations, rather than using Omniris's.

The data center edition runs on Omniris's own servers, with its key service, signing key and storage on that hardware, and uses Omniris's own provider accounts.

Where your data lives

Omniris comes in four forms. The software is the same; what differs is whose hardware it runs on.

Each Omniris cloud keeps its files and its database together in that one region.

What an on-premises site keeps, and what it reaches out for

An on-premises site is a normal connected installation. Your files, your database, the processing of your maps, 3D models and AI detections, the key service for protected files and the custody record all stay on your servers. The main things it reaches out to the internet for are these, plus any outside system you connect it to yourself, such as Procore:

If the connection drops, the site keeps working. People already signed in stay signed in, a desktop app or browser that has signed in before can sign in again, and features that need an outside service say plainly that they can't reach it.

What is recorded

Every file has a custody record: its complete history, sealed so that any later change to the history shows. It records uploads, views, downloads, shares and each time a share is used, moves and renames, encryption and decryption, changes to who may open a protected file, transfers between accounts, processing results, and deletion and restoration. Each entry says who acted, when and from where.

• Your audit log. Account → Audit Log lists these events across your vault. Filter by type, search, and export the list as a spreadsheet file (CSV).
• Each file's history is shown with the file, and can be issued as a signed certificate that anyone can check.
• Changes made through the API to findings appear in each finding's history under the name of the token that made them.

How the record is sealed, timestamped by independent authorities, checked every day, and turned into certificates is the subject of the companion paper Evidence you can prove.

Deleting data and accounts

The recycle bin

Deleting a file, a folder or a finding moves it to your recycle bin, shown as the same folder tree it came from. From there you can put it back where it was, or delete it forever. Anything left in the bin is erased from storage for good by a daily clean-up once its time is up: 30 days by default. An organization has a recycle bin of its own for its vault, which its managers look after.

Legal holds and retention policies

A legal hold freezes evidence so that it can't be changed or deleted. A retention policy keeps data for a set period, then releases or deletes it. Anything they protect is refused before you confirm a deletion, with the reason. They are described in full in Evidence you can prove.

When an account is deleted

• Protected data comes first. An account can't be deleted while any of its own data is under a legal hold or retention policy; it can be deactivated instead. The owner of an organization hands ownership to another manager first.
• Its own vault goes. The folders and files in the account's own vault are deleted, along with its share codes and public links, and the findings in its vault.
• Shared work stays. Folders the person made inside an organization's vault or a client's job folder belong to that vault and are kept, with their files.
• Deliveries. If a pilot's account is deleted, findings a client made on that pilot's delivered results are kept in the client's vault, in a folder named Revoked deliveries.
• The name is erased from history. Elsewhere, the person's changes to findings show as "Someone", and their checks of AI results as "a person (name erased)". Holds that other customers placed on their own copies are not affected; those records are kept, without the deleted account's details.

Deactivating an account is different: it stops the person signing in at once, and deletes nothing.

API keys and webhooks

Outside systems, such as a work-order system, a mapping (GIS) system or a script, can read and update your findings through the Omniris API, and be told about changes as they happen through webhooks. The companion paper Findings you can act on describes what they can do; this is how they are kept safe.

API tokens

• Who makes them. An organization's managers, or the owner of a personal vault, in Findings → Settings → API tokens.
• Scope. A token reaches the findings of exactly one organization or one vault, with their evidence, and nothing else: it can't browse folders or files, or reach another organization. A finding that moves elsewhere disappears from the token's view at once, and evidence is shown only while its file is still in that organization or vault. Nothing that leaves through the API reveals where files are stored.
• Two levels. Read, or Read and write. A read token can't change anything.
• Shown once. The token is a long random string, shown once when it is made. Omniris keeps only a keyed hash of it, so it can't be shown again or read from storage.
• Turned off by itself. A token stops working when the person who made it leaves the organization, stops being a manager, or has their account deactivated, locked or deleted, or when the organization is deactivated. The managers are emailed. A token can also be revoked at any time, for good.
• Limited. Each token may make up to 600 requests a minute.

Signed webhooks

• Signed. Every webhook message carries a signature made with a secret only you and Omniris know (HMAC-SHA256, a standard way to sign a message with a shared secret) and a timestamp. Your system checks the signature to know the message really came from Omniris and was not changed, and rejects old timestamps so a captured message can't be replayed. The secret is shown once and is stored encrypted.
• Lean. Messages carry the finding's summary only: no web addresses, no storage locations, no secrets. Your system fetches anything more through the API, with its own token.
• Safe destinations. On Omniris cloud and the data center edition, webhooks go only to HTTPS addresses on the public internet, never to a private network, and redirects are not followed. An on-premises site may also deliver to machines on its own network that it has approved.

Limits

Security depends on knowing exactly where the edges are. These are Omniris's.

• New files are encrypted shortly after they arrive, not instantly. A file uploaded into a protected folder is stored as uploaded for a short time first, while Omniris makes its preview and reads its location, and is then encrypted. That wait is never more than 30 minutes. If the encryption step itself fails, a check every 15 minutes finishes the job. A protected file that is replaced by a new upload or a re-run goes through the same short wait.
• Omniris can open protected files. The Omniris service is on every protected file's access list, so that it can re-encrypt files when their access changes and serve public links. Protection controls which people can open a file; it does not keep the file from the service that stores it.
• Revoking cannot recall what was saved opened. Revoking a share ends the person's access through Omniris at once, and then, in the background, takes them off each protected file's key list, so an encrypted copy they downloaded can no longer be opened. Anything they had already saved in opened form, such as a decrypted download or a picture export, cannot be pulled back.
• A public link is a publication. Protected files in a published folder are shown to anyone with the link and its password.
• Working copies. To show you a protected map layer, point cloud or panorama, a decrypted copy is kept for you alone for up to 24 hours. Opening those, or a protected 3D model, in a viewer is recorded as a decryption once per viewing; the record is written when the viewer is given the working copy, so the copy itself is not checked again on each read while it lasts. Exports keep a decrypted copy of a protected source for up to an hour. Processing jobs keep one until the job ends.
• On-premises storage and network. Omniris does not add disk encryption on an on-premises or data center server; on premises, that is the site's own choice, as is HTTPS. Without HTTPS, traffic on the site's local network is not encrypted and passkeys can't be used.
• Sign-in sessions. A browser sign-in on Omniris cloud lasts 31 days and signing out ends it in that browser only. "Sign everyone out" exists on premises only, and passes already handed to the key service or to processing run out on their own within 12 hours.
• Social sign-in needs the internet. An on-premises site that loses its connection can't start a Google, Apple, Microsoft or Facebook sign-in until it is back. Passwords, device sign-in and passkeys (over HTTPS) still work.
• Deactivating is not deleting, and deleting an account is refused while its data is under a legal hold or retention policy.
• The custody record has limits of its own, set out in Evidence you can prove.

Glossary

AES-256-GCM

A widely used encryption standard that also detects any change to the encrypted data.

Custody record

The sealed history of everything that happened to a file: who did what, and when.

Deactivated account

An account that can no longer sign in or use anything, with all its data kept.

Hash

A one-way scrambled form of a password or token. It can be checked against, but not turned back into the original.

HMAC-SHA256

A standard way to sign a message with a shared secret, so the receiver can tell it is genuine and unchanged.

HTTPS / TLS

The encrypted form of web traffic. TLS is the encryption standard underneath it.

Key service

The part of OpenTDF that holds the keys to protected files and decides, person by person, who may have one.

Legal hold

A freeze on evidence, so that it can't be changed or deleted until the hold is released.

OpenTDF

An open standard for encrypted files that carry their own access rules.

Organization

A group of accounts with a shared vault, run by its managers.

Passkey

A sign-in key kept by your phone, computer or password manager, unlocked with your fingerprint, face or device PIN.

Protected file

A file encrypted with OpenTDF, which only the people on its access list can open.

Public link

A web address that opens a folder for anyone who has it, with no account.

Recycle bin

Where deleted items wait, 30 days by default, before they are erased for good.

Retention policy

A rule that keeps data for a set period, then releases or deletes it.

Share code

A code that gives another Omniris account access to one of your folders, at the level you choose.

Signed link

A web address for one file that works only for a short time, issued after your permission is checked.

Snapshot

A frozen, read-only copy of a folder in someone else's vault.

Vault

An account's or organization's private storage for files and folders.

Webhook

A message Omniris sends to another system the moment something changes.