Cookie and Similar-Technologies Policy — DGM One

Version 2026-09-27

This policy describes what DGM One stores on, and reads from, your device — every cookie and every browser-storage key, what each is for, and how to change your analytics choice. The control for changing that choice is at the bottom of this page.

1. What this policy covers

This policy explains what DGM One stores on, and reads from, your device — and why.

It covers more than cookies. German law is explicit on this point, and we follow the German reading throughout:

§ 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, in force since

1 December 2021 as the successor to § 15(3) TMG, implementing Art. 5(3) of the ePrivacy

Directive 2002/58/EC) applies to **"the storage of information in the end user's

terminal equipment, or access to information already stored in the terminal

equipment"**.

That wording is technology-neutral. It captures:

• HTTP cookies
• localStorage and sessionStorage
• IndexedDB (including our offline database and our service worker's queue)
• the Cache Storage API used by our service worker
• any comparable identifier written to or read from your device

Every one of those is inventoried below. Where German terminology helps a German reader, we give it alongside the English.

Two separate legal questions. § 25 TDDDG governs the act of writing to or reading from your device. The GDPR (DSGVO) governs what we then do with any personal data obtained that way — purposes, legal basis, transfers, retention and your rights. This policy answers the first question and cross-references our privacy notice for the second.

Companion documents. This policy sits alongside our privacy notice (https://app.dgmone.com/legal), our sub-processor list (https://app.dgmone.com/legal), our data-processing agreement (AVV — Auftragsverarbeitungsvertrag), our record of processing activities (Verzeichnis von Verarbeitungstätigkeiten), our description of technical and organisational measures (TOM) and our deletion concept (Löschkonzept). Published at https://app.dgmone.com/legal — Terms, DPA, privacy notice, cookie policy.

2. Who is responsible

Emfara, Inc., a corporation organised under the laws of the State of Delaware, USA, operating the DGM One service at app.dgmone.com and the marketing site at www.dgmone.com.

• Registered address: Emfara, Inc. · 251 Little Falls Drive, Wilmington, New Castle, DE 19808, USA
• Delaware file number: 10577634
• Contact for data-protection matters: Eric Muller — privacy@emfara.com
• EU representative under Art. 27 GDPR: none — not required on current facts; see the privacy notice

We have not appointed a Data Protection Officer / Datenschutzbeauftragter. We have assessed Art. 37(1) GDPR and § 38 BDSG and concluded that neither obliges us to designate one at our current scale and processing profile. We have instead named an internal owner for privacy questions (above), who is your point of contact.

Role note. For most personal data in DGM One we act as a processor (Auftragsverarbeiter) on our business customer's instructions. For the optional product analytics described in §7, and for the public marketing and demo pages, we act as a controller (Verantwortlicher) in our own right.

3. How we classify each item

We use two categories. There is no third.

A. Strictly necessary (technisch notwendig) — no consent required. § 25(2) No. 2 TDDDG exempts storage or access that is "strictly necessary so that the provider of a digital service can provide a service expressly requested by the user". This covers keeping you signed in, remembering which organisation you are working in, holding the checklist you are filling in, and making the application work offline — because an offline-capable inspection tool cannot deliver the service you asked for without writing your work to your device.

B. Optional — prior consent required. Anything not in category A. In practice, for DGM One, that means product analytics. Consent must be prior (before the storage happens), informed, specific, freely given and as easy to withdraw as to give (Art. 4(11), Art. 7(3) GDPR).

Transparency is not waived by category A. The strictly-necessary exemption removes the consent requirement. It does not remove the disclosure requirement. Everything in category A is therefore listed below in the same detail as everything in category B.

4. Your choice, and how to change it

When you first open DGM One — including the sign-in page, the pricing page and the public demo page — you are asked one question: whether we may use product analytics.

• Nothing optional runs before you answer. The analytics SDK is not initialised, so no

analytics cookie, localStorage entry or sessionStorage entry is written and no request is sent to the analytics provider.

• Refusing is exactly as easy as accepting. Two buttons of equal size and prominence,

side by side, one click each. "No thanks" is the first control in tab order.

• Nothing is pre-ticked, and ignoring the banner is not consent. There is deliberately

no dismiss control that silently means yes.

• You can change your mind at any time, from the control at the bottom of this page

(app.dgmone.com/legal/cookies). Withdrawing stops analytics collection immediately, clears the identifiers already stored in your browser and returns you to the undecided state, so you can choose again. Withdrawal does not affect the lawfulness of processing carried out before it (Art. 7(3) GDPR).

Your decision is itself stored on your device, in localStorage under the key dgmone.analytics-consent.v1. That storage is strictly necessary: a refusal we could not remember would be meaningless, because the banner would reappear on every page load. The key is versioned — if the set of purposes ever changes, the version increments and every earlier decision is treated as undecided, because a decision about one set of purposes is not consent to a different set.

We do not use a third-party consent-management platform. The gate is implemented in our own code, so no data leaves your browser in order to ask you the question.

5. Strictly necessary — cookies

All of the cookies below are first-party (set by dgmone.com). None of them is used for advertising, profiling or cross-site tracking.

Our position on sidebar_state is that a user-interface preference, written only on your own explicit click, falls within the § 25(2) No. 2 TDDDG exemption as a customisation you asked for. We state the reasoning rather than only the conclusion.

Cookie name detail. The __Secure- prefix and the leading dot on the domain are both deliberate: the prefix means the browser refuses the cookie unless it arrives over HTTPS, and the leading dot allows one sign-in to work across our subdomains. In local development builds the prefix is absent.

6. Strictly necessary — storage on your device

These are not cookies. They are localStorage, IndexedDB and Cache Storage entries, and § 25 TDDDG applies to them in exactly the same way it applies to cookies.

6.1 localStorage

Two honest qualifications on this table.

1. oryx.cmdK.recent.<organisation> is namespaced by organisation, not by user. On a

shared device — a warehouse tablet, for example — the next person signing in from the same organisation will see the previous person's recent search terms. Nothing clears this key at sign-out today. We are changing this so the key is scoped to the individual user and cleared at sign-out. Until then, the paragraph above is the accurate description.

1. dgmone_demo_visitor and oryx.cmdK.recent.<organisation> are **conveniences, not

technical necessities**. Our own reading is that neither comfortably fits the § 25(2) No. 2 exemption, because the service can be delivered without them. Pending that classification we disclose both here in full, rather than treat the question as settled in our own favour.

oryx-checklist-draft is cleared when you submit a checklist and when you sign out — from every sign-out control, including the one in the sidebar and in the mobile navigation drawer.

6.2 IndexedDB — offline inspections

Written only when offline working is enabled for your organisation.

Retention on the device (Löschkonzept — device layer):

• Records that have successfully uploaded are deleted from the device 24 hours

after upload, and are deleted at sign-out.

• Records that have not yet uploaded are deliberately kept, including across

sign-out. They are the only copy of that inspection, and deleting them would destroy a field inspector's work. While parked they are locked to the inspector who created them: the upload engine will not send another person's parked work, and the interface states whose work is waiting.

• Those unsynced records have no automatic expiry. If the inspector never signs in on

that device again, their record — including the shipper and consignee details, the signature image and the photographs — remains in that device's storage indefinitely. There is no bounded device-retention window and no administrator-initiated remote purge today. Clearing the browser's site data on that device is the only way to remove a parked record, and doing so destroys that inspection.

Photograph metadata. Location and device metadata (EXIF, including GPS) are removed in your browser before the photograph is stored or uploaded. The image written to the device and sent to us carries no location data. This is a real control, implemented in the image pipeline, and it applies to every photograph on every route.

Encryption. DGM One does not apply its own encryption to this device database. Confidentiality of the data at rest on the device depends on the device's own encryption (iOS/Android device encryption, BitLocker, FileVault or equivalent) and on your organisation's device management. We state this plainly rather than implying a control we do not have. Your organisation should record device encryption as a measure on its own side when it carries out its data-protection impact assessment; we state the position here so that it can.

6.3 Cache Storage — the offline application cache

Registered only when offline working is enabled for your organisation, at /serwist/sw.js.

Authentication endpoints, photo upload authorisation endpoints and administration endpoints are excluded from caching and always go to the network.

Honest limitation. These caches are scoped to the browser origin, not to the signed-in user, and nothing in the application clears them at sign-out. On a shared device, a page or data response cached during one person's shift can therefore still be served from the cache to the next person on the same device while it is offline, until the 24-hour expiry or eviction removes it. Disabling offline working for an organisation unregisters the service worker but does not delete caches already written.

7. Optional — product analytics (consent required)

Nothing in this section runs unless you have chosen "Allow analytics". If you have not chosen it, or you have withdrawn it, none of the identifiers below is written and no request is made to the provider.

Provider: PostHog Inc., United States (US cloud region). Purpose: understanding which features are used and where people get stuck, so we can improve the product. Nothing here is used for advertising or sold to anyone. Our role: for this processing we are the controller. Legal basis: your consent — § 25(1) TDDDG for the storage on your device, and Art. 6(1)(a) GDPR for the processing that follows.

<project key> is our public PostHog project token, which is visible in the page source.

What is sent to PostHog when you consent:

• Page views — the address of each page you visit inside the application.
• Automatically captured interactions — clicks and form submissions, with the element

clicked.

• A small set of named product events (for example: a checklist was started, a photograph

finished uploading, a PDF was generated).

• Once you are signed in: your organisation (tenant) id, so that usage can be

attributed to an office and we can see which features that office relies on.

• **Whether your own user id and work email address are sent depends on where your

office is**, and it is the only thing that differs:

This is decided by the country recorded for your office, not by where you happen to be when you sign in. An inspector whose office is in Germany is treated as an EU data subject even while travelling, and the reverse is also true. If no country is recorded for an office, the office is treated as if it were in the EU — the more protective option. Ask us and we will tell you which setting applies to your office.

• Your IP address, from which PostHog derives an approximate location. **IP

anonymisation is not currently enabled on our PostHog project.What is deliberately not sent:**

• Session replay (screen recording) is switched off. It records rendered text, which

in this product means shipper and consignee names and declaration contents. It is disabled in the application configuration.

• Exception and error data. Our analytics provider's error capture is deliberately

disabled; error monitoring is a separate system with its own redaction (see §8).

• Credentials in addresses. Query-string values whose parameter name looks like a

credential — anything containing token, secret, password, key, code, auth, session, signature, credential or email — have their value replaced with `redacted` before the address is sent. The parameter name is kept so the shape of the page is still analysable.

How the data reaches PostHog. Analytics requests are sent to a path on our own domain (/ingest/*) which forwards them to PostHog's United States endpoints. We disclose this because it has two consequences you are entitled to know: the analytics cookie is a first-party cookie on .dgmone.com rather than a third-party cookie, and browser-level tracker-blocking lists that target the provider's own domain will not match it. This proxy does not override your choice. If you decline, or withdraw, nothing is initialised and nothing is sent.

Retention at PostHog. Session recordings are configured to expire after 30 days (and recording is now switched off entirely). Event retention is configured at 12 months.

Transfer to the United States. PostHog processes this data in the United States. The transfer is made under the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), incorporated into our data-processing agreement with PostHog, together with a transfer impact assessment we maintain and will produce to a supervisory authority on request. See §9.

8. Things you might expect to find here, and will not

Stated explicitly, because a reviewer will check.

• **No advertising, marketing, retargeting or cross-site tracking technologies of any

kind.** No advertising network, no conversion pixel, no social-media plugin, no A/B testing tool, no chat widget, no heat-mapping tool other than the analytics described above.

• No Google Analytics, no Google Tag Manager, no Meta pixel, no LinkedIn Insight Tag.
• No hosting-provider analytics. Neither Vercel Analytics nor Vercel Speed Insights is

installed.

• Error monitoring is wired into the code but is not switched on in production. No

error-monitoring identifier is written to your device and no error data leaves your browser today. Should it be enabled, this policy will be updated first.

• Bot protection (Cloudflare Turnstile) runs on two public pages only — the sign-up

page and the public verification page. It is loaded from challenges.cloudflare.com and receives your IP address and browser signals in order to distinguish a person from an automated script. In a live check of both pages on 2026-09-02 with a clean browser profile, no Turnstile cookie was set.

• Payments (Stripe). Card details are entered on a payment page hosted by Stripe on

Stripe's own domain, never on ours. No Stripe cookie is set on dgmone.com. Storage set while you are on Stripe's page is governed by Stripe's own cookie policy.

• Web fonts. The application requests a font stylesheet from fonts.googleapis.com

for one organisation's branding. That request is blocked by our Content-Security-Policy and never leaves the browser, so no data reaches Google and the fonts fall back to locally available ones. We disclose it because the markup is present.

9. Transfers outside the EU/EEA

DGM One is operated from the United States. Every item in §7 involves a transfer of personal data to the United States. Items in §5 and §6 are stored on your own device, but the servers they authenticate against, and the data they synchronise with, are in the United States.

• Safeguard: the EU Standard Contractual Clauses of 2021 (Commission Implementing

Decision (EU) 2021/914), incorporated into a written data-processing agreement with each recipient, together with the UK Addendum / IDTA and the Swiss addendum where relevant.

• We do not rely on the EU–US Data Privacy Framework as our primary safeguard. Some of

our providers are certified under it and some are not; our transfer position rests on the Standard Contractual Clauses in every case, so that it does not change if the Framework's status changes.

• Transfer impact assessments (Clause 14(d) SCC) are maintained by us as exporter and

will be produced to a supervisory authority or to a customer's data-protection officer on request.

• The full list of recipients, what each receives, and where each processes it, is in our

sub-processor list. https://app.dgmone.com/legal

10. Your rights

Managing storage on your device is only part of the picture. Under the GDPR you also have the right to access, rectify, erase, restrict and port your personal data, to object to processing based on legitimate interests, and to withdraw consent at any time without affecting the lawfulness of processing before withdrawal (Art. 15–22, Art. 7(3) GDPR). You may also lodge a complaint with a supervisory authority (Art. 77), including the one for your place of residence or work.

• Where your employer is our customer, we normally act as a processor for the data

in the product. Please direct requests to your employer, who is the controller; we support them in answering.

• For the analytics described in §7, and for the public demo and marketing pages, we

are the controller and you can come to us directly: privacy@emfara.com.

• You can always clear device storage yourself. Your browser's "clear site data" or

"delete cookies and site data" control removes everything listed in §5 and §6 for dgmone.com. Doing so signs you out, and — importantly for field users — also deletes any inspection stored on that device that has not yet uploaded.There is no self-service export or delete function in the product. Access, portability and erasure requests are carried out by us, by hand, on request to privacy@emfara.com. We say so rather than point you at a button that does not exist.

11. Changes to this policy

We will update this policy whenever we add, remove or materially change anything that stores information on, or reads information from, your device. Material changes to the optional category reset your choice: the consent version is incremented, and you are asked again, because a decision about one set of purposes is not consent to a different one.

• Version: 2026-09-27
• Date: 27 September 2026
• Change log: first published version. The consent gate, the withdrawal control on this

page, session replay being switched off and the removal of credential-shaped values from addresses are all live as described. Previous versions are retained and are provided on request.

12. What is still open, stated plainly

A policy that lists only what we do well is not worth reading. These are the things a reviewer would find, so we list them ourselves. Each is described in full in the section named.

What is live and behaves as described in this policy: the consent gate in § 4 (nothing optional is initialised before you choose), session replay switched off, credential-shaped query-string values replaced with redacted before an address is sent, and the withdrawal control on this page.

13. Sources and questions

Every statement in this policy was taken from the behaviour of the application itself — the code that sets each cookie and storage key, and a live check of the pages that set them — or from the data-processing agreement in force with each recipient named in § 7 and § 9, verified against the primary transfer registers rather than against vendor marketing material.

If you believe anything here is inaccurate, tell us at privacy@emfara.com and we will check it and correct the policy if it is wrong.