This is proposed public text for how a future Dohos-operated website or application would use cookies and similar technologies. It does not show that any cookie, tag, preference manager, analytics service, or advertising technology is active on a Dohos property today. The release-specific technical inventory this notice depends on — the actual domains, browser storage, providers, lifetimes, data recipients, and preference behavior — has not been produced. This draft must not be published until that inventory exists and every activation condition below is satisfied.
01Purpose
This Cookie and Tracking Notice explains how an activated Dohos-operated website or application may use cookies and similar technologies, why they are used, how long they persist, which parties receive data, and what choices are available.
The activated notice must be generated from the actual release and must identify each technology accurately. A generic statement that "we use cookies" is not enough, and this draft does not authorize any technology.
02What these technologies are
Cookies are small text records a website asks a browser to store and return. Similar technologies can include:
- browser local storage and session storage
- IndexedDB or other browser databases
- cache entries and service workers
- pixels, tags, beacons, and conversion events
- device, application, or advertising identifiers
- mobile or web software-development kits
- link, email, and message interaction parameters
- session, authentication, fraud, and load-balancing tokens
- embedded video, map, payment, chat, scheduling, or social components
- server-side identifiers or events that recognize a browser, device, session, Account, or interaction over time
Some technologies expire when the browser or session closes. Others persist for a stated period or until they are deleted. A Provider may set a technology directly, or Dohos may set it and disclose data to the Provider.
The activated inventory must describe function, not rely only on a vendor's label.
03Scope
This notice applies only to the Dohos-operated domains, subdomains, applications, and embedded experiences identified in the activated version.
It does not automatically cover:
- a Restaurant's independent website, application, ordering page, loyalty program, or advertising
- a Payment Provider's independent page or wallet
- a Communications Provider's independent service
- a link that leaves the Dohos-operated service
- a browser or device feature controlled by its provider
- a disabled, development, test, demo, preview, or future integration
A Restaurant or Provider may provide its own notice. The activated interface must make the responsible party clear before a person enters an independently controlled surface.
04Target baseline
Dohos's target launch baseline is:
| Category | Target state | Boundary |
|---|---|---|
| Strictly necessary security and service storage | Conditional | Only what the approved release needs to authenticate, secure, balance, remember a transaction session, preserve a privacy choice, or provide a requested function |
| Functional preferences | Off unless requested or essential | Used only for the selected preference and disclosed duration |
| Audience measurement and product analytics | Disabled by default | May activate only after inventory, necessity, minimization, Provider, consent/opt-out, retention, and claims review |
| Advertising, retargeting, cross-context behavioral advertising, and data-broker tags | Disabled | Not part of the target launch model |
| Sale or sharing of Personal Data through tracking | Prohibited in target baseline | Must not occur by label, configuration, pixel, SDK, server event, or Provider reuse |
| Precise-location, fingerprinting, session replay, keystroke capture, or sensitive-data tracking | Disabled | Requires a separate necessity and legal decision; not authorized here |
| Cross-Restaurant tracking | Prohibited in target baseline | One Restaurant's Diner activity must not be used to profile or benefit another Restaurant |
This table states a target design, not current behavior. The activated notice must describe the verified release even if that requires acknowledging and remediating a different historical practice.
05Strictly necessary technologies
An activated service may use narrowly scoped technologies needed to:
- establish and maintain an authenticated session
- protect Accounts, Diners, Restaurants, payments, and systems against fraud or abuse
- balance traffic and deliver the requested page or feature
- preserve the state of an Order Request long enough to complete it
- remember a privacy, cookie, accessibility, or language choice
- route a person between approved steps or Providers
- prevent duplicate submissions
- maintain security and service continuity
- satisfy a legal or evidentiary requirement that cannot reasonably be met another way
Calling a technology "necessary" does not make it necessary. Dohos must document the exact purpose, why a less intrusive alternative is inadequate, data elements, access, recipients, lifetime, and failure consequence.
Strictly necessary technologies must not be reused for advertising, unrelated analytics, model training, enrichment, or cross-Restaurant profiling.
06Functional preferences
With the person's request or another lawful basis, an activated service may remember a limited preference such as:
- selected language
- accessibility display or interaction choice
- Restaurant location
- fulfillment preference during the current interaction
- dismissed nonmarketing notice
- other user-selected interface setting
A functional technology must not silently enable analytics or advertising. A location, dietary, accessibility, or other potentially sensitive preference should be stored only when necessary, with clear consequences and the shortest reasonable duration.
07Analytics and audience measurement
Analytics are disabled by default in the target baseline.
If Dohos later proposes an analytics capability, the activated notice must explain:
- the precise service and Provider
- events and data fields collected
- whether identifiers persist across sessions, domains, devices, Restaurants, or services
- the business purpose and necessity
- whether data is aggregated, pseudonymized, or deidentified and the limits of those terms
- Provider access and independent reuse, if any
- processing and storage locations
- retention and deletion
- consent, opt-out, browser-signal, and account controls
- whether the technology runs before a choice
- how the configuration was verified
Dohos must not describe identifiable or linkable analytics as "anonymous." IP truncation, hashing, pseudonyms, or aggregation can reduce risk but do not automatically make data non-Personal Data or deidentified under every law.
Analytics must exclude full payment credentials, raw audio, raw transcripts, sensitive order notes, allergy/medical details, authentication secrets, and content not needed for the approved measure.
08Advertising and targeted tracking
The target launch model does not use cookies, pixels, SDKs, server-side events, or identifiers to:
- sell Personal Data
- share Personal Data for cross-context behavioral advertising
- retarget a Diner based on Restaurant interactions
- build advertising audiences
- combine Dohos/Restaurant data with third-party browsing profiles
- measure third-party advertising conversions
- enable a Provider to use interaction data for its own advertising
Dohos must not display a "we do not sell or share" statement unless browser, network, server, Provider, and data-flow evidence supports it for the exact release.
Any future proposal to change this baseline requires separate counsel and executive approval, Provider and technical evidence, an updated Privacy Notice, a release-specific notice, all required consent/opt-out mechanisms, browser-signal support, and a non-retroactive activation record.
09Embedded and third-party features
An activated page may include an approved independent or embedded service, such as payment, map, video, chat, scheduling, fraud, accessibility, or support functionality.
Before inclusion, Dohos must determine:
- whether the feature sets or reads browser/device storage
- which party controls it and for what purposes
- whether it runs before user action
- what data is disclosed by merely loading it
- whether it creates cross-site, cross-device, or Provider-level recognition
- the Provider's independent uses, subprocessors, regions, and retention
- the consent or opt-out rule
- whether a privacy-preserving alternative exists
A link or feature must not be described as "necessary" merely because a vendor's default implementation loads it. Where appropriate, an embedded feature should remain blocked until the person requests it or makes the required choice.
10Authentication, payment, and Restaurant transactions
Authentication, fraud, and payment Providers may use necessary technologies in their approved surfaces. The activated notice must distinguish Dohos's technology from the Provider's independent technology and terms.
Payment credentials must remain in the approved Payment Provider path — see how Dohos handles cash and card. Cookie or analytics values must not contain a full card number, security code, PIN, bank credential, wallet secret, authentication value, or another prohibited credential.
Order-state storage must be scoped to the identified Restaurant and transaction. It must not expose one Restaurant's items, instructions, amounts, contact details, or status to another Restaurant or later user of a shared device.
The product should warn or minimize persistence on shared devices where the risk is material.
11Data that may be associated with these technologies
Depending on the verified technology, data may include:
- cookie or local-storage name and value
- session, Account, Restaurant, transaction, or preference identifier
- IP address and approximate network-derived location
- browser, device, operating-system, language, and screen information
- page, referrer, link, route, feature, and timestamp
- authentication, security, fraud, consent, and error events
- source/campaign parameters where an approved capability exists
- Provider identifiers and response status
The activated inventory must list the actual fields or meaningful categories and recipients. It must not use "device information" or "usage information" to conceal a broad collection.
Sensitive data should not be encoded in URLs, referrers, cookie values, analytics event names, page titles, browser storage, or third-party requests.
12Choices and preference controls
The activated service must provide the choices required by the applicable technology, purpose, and jurisdiction. Depending on the verified release, that may include:
- a preference interface before nonessential technologies run
- category-level choices that are off by default where required
- a persistent link to reopen choices
- withdrawal as easy as initial choice
- an Account-level control
- a "Do Not Sell or Share" route if legally required by actual practices
- recognition of Global Privacy Control or another legally recognized universal opt-out signal
- an appeal or privacy-request route
- an accessible alternative when the interface is not usable
Rejecting nonessential technologies must not block a requested service unless the technology is genuinely necessary for that service and the consequence is clearly explained.
A cookie banner must not use misleading colors, hierarchy, defaults, repeated prompts, obstructive clicks, or a false "necessary" category. Closing a banner, scrolling, or continuing to browse is not consent where affirmative consent is required.
13Browser and device controls
Browsers and devices may allow a person to block, delete, limit, or inspect some stored data. Those controls may affect a feature, authentication, saved preference, or transaction session.
Browser deletion alone may not withdraw a server-side consent, erase data already disclosed, or communicate an opt-out to a Provider. Conversely, Dohos must not force a person to rely only on browser settings when law or Dohos's practice requires an in-service choice.
The activated notice should provide accurate instructions for supported browsers and devices without promising that every control affects every technology.
14Global Privacy Control and other signals
Where required by law or adopted as a Dohos commitment, the activated service must detect and honor a recognized browser-based opt-out signal for the covered browser/device and processing.
Signal handling must:
- occur before covered processing where required
- bind to an Account where lawfully requested and authenticated
- not overwrite a more privacy-protective choice
- propagate to relevant tags, server events, Providers, and downstream recipients
- persist for the required scope
- provide understandable confirmation
- be tested after every relevant release or Provider change
This draft does not claim that the current service detects or honors any signal. That capability requires live verification.
15"Do Not Track"
Browser "Do Not Track" settings are distinct from legally recognized universal opt-out mechanisms. The activated notice must accurately state how the verified release responds to each supported signal and must not use ambiguity about one signal to ignore another legally binding signal.
No response behavior is claimed in this draft.
16Retention
The activated inventory must state the lifetime of each technology and the associated server-side data, including whether expiration renews on use.
Target retention principles are:
- session technologies expire when the approved interaction ends unless a shorter or longer period is justified
- security and consent evidence remains only for the approved legal/security period
- preferences persist only for the disclosed useful period
- nonessential identifiers do not renew indefinitely by default
- deleted or withdrawn categories stop future collection and trigger downstream action as required
- backups and legal holds follow the approved retention and deletion schedule
Dohos must distinguish browser lifetime from Provider and server retention. Deleting a cookie does not necessarily delete associated server data.
17Children
The target service is not directed to children. Nonessential tracking on a child-directed or known-child interaction is disabled in the target baseline.
Dohos must not infer that a user is an adult from device type, payment method, phone number, or Restaurant order. If an approved experience could involve children, counsel and product must establish the age, notice/consent, data minimization, advertising, deletion, and parental-control requirements before activation.
18Security
Cookie and storage design should use, as appropriate:
- secure transport
- Secure, HttpOnly, SameSite, domain, path, and lifetime attributes
- unpredictable identifiers rather than sensitive content
- rotation and invalidation
- consent and preference integrity
- cross-site request protections
- tenant and Restaurant separation
- inventory/change monitoring
- incident response for exposed tokens or unauthorized tags
No security measure is absolute. The activated notice must not claim that technologies are "secure," "anonymous," "encrypted," or "essential" without scoped evidence.
19Changes to technologies or this notice
Dohos must scan and review each release for new, removed, renamed, reconfigured, or behaviorally changed technologies. A Provider, tag-manager, consent-manager, payment, auth, embedded content, or server-side routing change can alter the notice even when the interface looks the same.
A material change must not activate until:
- the inventory and data map are updated
- legal basis and choice are approved
- Provider and contract review is complete
- the notice and preference interface are updated
- required consent or notice is obtained
- the exact release and evidence are recorded
A new notice does not retroactively authorize earlier tracking. Superseded versions, once any exist, will be preserved at the version archive.
20Contact and privacy rights
The activated notice will provide the Dohos entity, privacy contact, support route, and any state-specific rights or appeal links — see privacy rights for the fuller request process. It will explain how to report a technology that does not match the inventory or a preference that was not honored.