Restaurant Operator Privacy Notice

Effective and last updated: August 29, 2026

This Restaurant Operator Privacy Notice explains how Tade handles information about restaurant owners and authorized users, restaurant businesses, and use of the Tade admin website and Tade Restaurant Manager mobile app (the "Operator Services"). Guest-facing reservation and waitlist processing is described separately in the Guest Privacy Notice.

Tade is operated by Taehyung Kim, a sole proprietorship operating as Tade, based in Vancouver, British Columbia, Canada. Tade has designated a Privacy Officer who can be reached at admin@thetade.com.

1. Scope and Roles

Tade is responsible for operator account, authentication, subscription, support, security, and product-use information handled for its own Service purposes. For guest information a restaurant enters, views, changes, or uses through the Operator Services, the restaurant determines the business purpose and is primarily responsible for providing notice, obtaining any required consent, limiting staff access, and responding to guest requests; Tade processes the information to supply and secure the Service.

This Notice covers the admin website on Tade's US and Canadian domains and the iOS and Android manager app. The domains identify a regional market experience but do not promise that information is stored only in that country.

The current iOS and Android manager builds are distributed internally through Expo/EAS and have not been submitted to the Apple App Store or Google Play. Before any public app-store distribution, Tade will complete and verify the applicable store privacy disclosures and policy URLs against the then-current app behavior.

2. Operator Account and Authentication Information

On a configured admin sign-in page, the browser loads both the Google Identity Services library and the Sign in with Apple JavaScript SDK before an operator chooses a provider. Merely opening that page can therefore let both providers process standard network and request data such as IP address, device or browser information, and referrer information under their own policies. The provider the operator selects additionally returns the identity information described below.

Google and Apple may use provider cookies or similar browser storage where permitted by the browser and their policies; Tade does not use that provider state for advertising. See the Google Privacy Policy and Apple Privacy Policy.

Account-deletion reauthentication is narrower: after that flow reaches identity verification, the admin page loads only the JavaScript library for the Google or Apple provider linked to that account. Merely opening the ordinary account page before that verification step does not load both sign-in libraries for deletion reauthentication.

• Account identity: name, email address, optional phone number, role, account status, signup country and authority evidence, created time, and last-login time.
• Social sign-in: the selected provider (Google or Apple), provider-specific account identifier, verified email status, identity token validation result, and the name or email the provider is authorized to share. Apple may supply a private relay email and usually supplies a name only on first authorization.
• Password and recovery records: legacy password-based accounts and recovery routes can retain a one-way password hash, email-verification token, single-use password-reset token and expiry, and records needed to send and validate recovery email. Tade does not store a readable account password.
• Authentication security: hashed or short-lived state, nonce, ticket, challenge, session, reauthentication, and attempt records needed to prevent replay, complete mobile-to-web sign-in, and protect destructive actions. Tade does not receive your Google or Apple password.
• Operator legal acceptance: a server-owned append-only record identifies the internal actor and restaurant while they exist; after deletion, it can preserve detached internal grouping references copied from the former numeric user and restaurant IDs; and it records the restaurant country, Operator Terms version, Operator Privacy version, clickwrap disclosure version and SHA-256 digest, whether the acceptance came from the owner web or manager app, whether it occurred at account signup, manager-app sign-in, or restaurant creation, and the server time. A detached grouping reference has no live user or restaurant foreign key, is not a public identifier, and is not by itself a claim that the retained ledger is legally anonymous. The record does not store the legal document body, operator name or email, IP address, or user-agent string. A current-state marker on the account is used where a current clickwrap is required, including manager-app session issuance and restaurant creation. Ordinary admin-website sign-in does not write a new acceptance record merely because an existing operator continued with Google or Apple.
• Local browser and device storage: the admin website stores the Tade session token in browser local storage and keeps temporary Apple sign-in or deletion-reauthentication state and nonce values in tab-scoped session storage until the flow completes, is cleared, or the tab session ends. The mobile app stores the Tade session token in device SecureStore when “Keep this device signed in” is enabled; otherwise the token is retained only for the active app session. A stored token copy may remain on the browser or device after its server expiry or invalidation until the client clears or overwrites it, but it no longer authorizes API requests after the server rejects it as expired, revoked, tied to a removed account, or tied to stale legal acceptance. A short-lived pending Apple handoff record may also be held in SecureStore so an interrupted sign-in or reauthentication can finish safely. The app stores non-account preferences, currently theme and reservation-list sort order, in AsyncStorage; those preference entries do not contain guest records. Android SecureStore entries are excluded from operating-system backup and are removed when the app is uninstalled, while iOS Keychain entries may survive uninstall and reinstall with the same bundle identifier as a platform behavior that Tade does not guarantee. Sign out or complete account deletion before uninstalling if you want the app to remove or invalidate the saved Tade session rather than relying on uninstall alone. The last audited Android internal binary allowed normal app backup, although its SecureStore entries were excluded; the source configuration for the next native binary disables Android app backup entirely.

Your Google or Apple account is independently governed by that provider's privacy terms. Different provider emails—including an Apple private relay address—can be treated as different Tade accounts unless support lawfully verifies and resolves the relationship.

The current Service does not create separate employee identities, provide granular staff role-based access control, or reliably attribute each action to an individual employee. Authorized staff may use an owner-authorized browser session or an admin-app session on a restaurant-controlled device, so account, session, consent, and operational records may identify the owner account or device session rather than the natural person who performed an action. The restaurant owner is responsible for granting and withdrawing staff access, controlling shared devices and sessions, and keeping any separate employee-level access or audit records the restaurant requires. Tade does not require or authorize disclosure of a Google, Apple, or legacy password to staff.

3. Restaurant and Operational Information

• Business profile: restaurant name, public slug and display code, description, country, operator-confirmed address and IANA time zone for current setup and edits, phone, Google place identifier, automatically derived neighborhood, onboarding status, and public-page settings. A time zone inferred before the current confirmation control may remain explicitly marked legacy_inferred until an operator reviews and confirms it. Tade does not retain Google Places coordinates for the restaurant.
• Operations: hours, holidays, reservation and waitlist settings, table time and party limits, policies, floor-plan and table geometry, slots, reservations, waitlists, walk-ins, arrival and seating events, and operational history.
• Public content: menu names, descriptions, prices, sizes, options and tags; restaurant, menu, popular-dish, promotion, and gallery images; house rules; promotions; and other content the restaurant publishes.
• Guest records managed by the restaurant: names, aliases, phone numbers, email addresses, notes, reservation and waitlist details, visit and no-show counts, block status, communication consent, delivery status, and related audit evidence.
• Plan information: trial dates, plan, billing cycle, subscription status, and database fields reserved for future billing. Paid subscriptions are not currently active and Tade does not currently collect payment card details through the Operator Services.
• Support and deletion information: messages sent to support, account reset or deletion requests, fresh-authentication status, counts and identifiers needed to complete deletion, and limited audit records.

4. Device, Browser, App, and Diagnostic Information

Hosting and security systems may process IP address, request time, host, method, route, response status, browser or device details, and abuse signals. Tade's structured application logs are designed to use route templates and opaque identifiers and to exclude raw URLs and query strings, headers, cookies, bearer tokens, names, email addresses, phone numbers, street addresses, message bodies, IP addresses, user-agent strings, SQL values, and raw error stacks.

The manager app may send Tade's API a privacy-limited sign-in diagnostic event containing a random attempt identifier, provider, stage, outcome or safe error code, elapsed time, operating-system platform, app version, build version, runtime version, update identifier, release channel, and whether the app code was embedded. The endpoint validates those fields but the application diagnostic sink retains only the closed event stage; it does not persist the attempt identifier, provider, versions, elapsed time, release channel, or other correlation metadata. Hosting and network systems may still process the request transiently as described above. The event is designed not to include name, email, provider token, Tade token, phone number, URL, or restaurant content.

The current manager application code does not request device GPS or precise location, camera, photo-library or external-media access, notification permission, or biometric authentication; it does not register a push token, deliver push notifications, or use a system-overlay feature. Native libraries can nevertheless add unused capability declarations at build time. The last audited Android internal binary declared notification, legacy external-storage, system-overlay, and biometric capabilities, and the last audited iOS internal binary contained a Face ID usage-description key. Those declarations do not establish that the app invoked the capability. The source configuration for the next native binary removes the unused notifications package, blocks those unused Android permissions, removes the unused iOS Face ID description, and disables Android app backup. These native changes cannot take effect through an over-the-air update: an older installed binary keeps its original manifest until it is replaced and reverified. The app checks and receives application updates through Expo's update service. For EAS Update, Expo states that it may collect the device operating system and a randomized token used to determine whether an update was downloaded; it may also process standard request, error, performance, and delivery information under its own policy. Tade does not use Expo's push-notification service in the current app and does not register an Expo push token. Browser or platform providers may still process standard network and device information under their own policies.

5. Restaurant Address, Maps, and Images

The admin website offers Google Places address search. As an operator types, the search text and a temporary session token are sent through Tade's API to Google. When an address is selected or manually saved, Tade asks Google to verify the address and derive the most specific available neighborhood. If address components omit a neighborhood, Tade may temporarily process provider coordinates to request nearby neighborhood or sublocality results. Those coordinates are used only inside that server request, are not returned to the operator browser, and are not stored in the restaurant record. Tade retains the operator-confirmed business address and may retain the place identifier, which Google's Places policies permit to be stored indefinitely; it does not geocode the address to infer a time zone. New restaurant setup and current address or time-zone edits require the operator to explicitly select and confirm a valid IANA time zone. A time zone inferred before this control remains marked legacy_inferred until an operator reviews and confirms it and is not represented as operator-confirmed. This concerns the restaurant's business location, not the operator device's live GPS location.

Google handles its Maps and Places processing under the Google Privacy Policy. The applicable Google Maps end-user terms are linked from the Restaurant Operator Terms of Service.

The admin website can upload restaurant, gallery, menu, popular-dish, and promotion images. Tade validates supported image types and size boundaries in memory, creates a resized WebP service copy, and stores the generated service file. The current manager app does not offer camera or photo upload. Do not upload images unless the restaurant has permission to publish and process them.

6. SMS, Email, and Guest Communications

When a restaurant uses transactional messaging, Tade acts on the restaurant's instructions and also performs provider, security, opt-out, and compliance controls.

• Twilio receives the guest's full phone number, message body and management link, sender configuration, and delivery callback data. Tade's SMS delivery log stores a masked number, provider message identifier, event, status, segment count, error and timestamps; nullable internal restaurant, reservation and waitlist references; after account deletion, a detached internal restaurant grouping reference copied from the former numeric restaurant ID, which is not a public identifier and is not by itself a claim of legal anonymization; a deduplication key derived from the destination and rendered message or event cycle; and, for durable-outbox delivery, the outbox reference while it exists and the positive attempt number. The attempt number can remain after its outbox parent is deleted. The delivery log does not store the full rendered message body.
• A global SMS opt-out register retains the full phone number and STOP/START state without a scheduled deletion date so a withdrawal continues to be enforced after guest or restaurant records change. A separate append-only consent ledger stores masked number, consent or withdrawal, method, source, staff actor where applicable, disclosure version, and time.
• Resend receives the guest or operator email address, sender, subject, HTML content, any attachment needed for transactional delivery, a per-operation provider request/idempotency identifier, and submission or delivery metadata. Reservation messages may include guest and restaurant details, management links, and a calendar file.
• An HTML message may load shared Tade-hosted wordmarks, icons, or restaurant images after the recipient's email application or privacy proxy permits remote images. That request can disclose request time and technical network or client information, such as an IP address or proxy address and user-agent information, to Tade's application, hosting, and network providers. The shared asset URLs are functional and are not unique per recipient.
• For a staff-created or staff-managed reservation, staff may enable transactional reservation email only after the guest asks or explicitly authorizes messages to the exact address and staff records the current checkbox shown by Tade. Tade stores append-only, versioned evidence that can include the authorization status, method and disclosure, masked address, keyed matching digest, address contact version, staff actor, and time.
• Reservation-email authorization is reservation-, address-, and disclosure-specific. An address change, withdrawal, guest-record relink, or anonymization invalidates it, and the email outbox checks the current authorization again before dispatch. Historical online reservations may be labelled legacy_guest_booking without claiming acceptance of the current disclosure; historical staff-created reservations remain unauthorized until a current grant is recorded.
• Pending email payloads are encrypted in Tade's outbox, limited to a maximum active lifetime of 24 hours, and scrubbed when sent, cancelled, dead, or expired. The delivery provider separately processes messages under its own terms.

Current staff-assisted SMS workflows require the guest to personally read and check the complete electronic disclosure on the operator's screen. The ledger records the grant as written electronic consent with Twilio opt-in type WEB_FORM, together with the disclosure version, masked number, staff actor or account identifier, source, and time. Restaurant staff must not check the box for the guest or substitute an oral answer for the guest's action. When the guest cannot personally complete the current checkbox, staff must leave SMS off and use a non-SMS service method. More detail is in the Restaurant Operator Terms of Service and Guest Privacy Notice.

7. Why Tade Uses Operator Information

• to create and authenticate accounts and bind them to an authorized restaurant and market;
• to provide, configure, synchronize, and support the admin website, manager app, public restaurant page, reservations, waitlists, guest records, and communications;
• to publish restaurant-authorized content and use the current operator-confirmed address and time zone—or separately identified legacy_inferred time-zone provenance pending operator review—together with restaurant country, restaurant-scoped public, legal, and communication origins, currency, and prepared delivery-profile settings. On the canonical admin website hosts, Vercel derives a two-letter country code from the request IP for that request's host redirect only; Tade does not store that code in the operator application database, and it does not change the restaurant's legal country. Separate regional email delivery is not active: current transactional email uses the shared no-reply@thetade.com sender, and current SMS in both countries uses the same Tade toll-free sender;
• to secure accounts, detect abuse, investigate failures, enforce provider and opt-out rules, and maintain auditability;
• to administer trials, plans, and—only if separately enabled and agreed—future paid subscriptions;
• to respond to support, access, correction, deletion, and regulatory requests; and
• to comply with law and enforce the Restaurant Operator Terms of Service.

Tade does not use operator or guest information for third-party advertising, does not run behavioral advertising or cross-site tracking SDKs in the current Operator Services, and does not sell personal information or share it for cross-context behavioral advertising.

8. Service Providers and Disclosures

The table below describes the current production Operator Services. The separate non-production test environment uses Google Cloud Run and Cloud SQL with Vercel staging websites, may be powered down when not in use, and is reserved for authorized testing with synthetic information; operators must not enter real account, restaurant, staff, or guest information there.

Tade uses technical and organizational measures designed to provide a comparable level of protection, together with available provider configurations, while service providers perform the functions described above. Tade selects, configures, and oversees those providers for the Service. Each provider's handling is subject to any applicable agreement, product terms, privacy commitments, and law; information processed abroad may remain subject to lawful access under local law.

We may also disclose information to professional advisers, courts, regulators, law enforcement, or other parties where law requires or it is reasonably necessary to protect the Service, guests, operators, rights, or safety. Information may be reviewed or transferred during a financing, reorganization, sale, or similar business transaction subject to confidentiality and continued protection.

9. International Processing

Tade is based in Canada, but Google, Apple, Twilio, Resend, Google Workspace, Google Cloud, Vercel, Expo/EAS, and managed infrastructure may process information outside Canada, including in the United States. The tade.ca and thetade.com domains do not determine storage residency. Information processed elsewhere may be subject to local law and lawful access by courts, law enforcement, or authorities in that country.

10. Retention, Reset, and Account Deletion

• Operator account and restaurant data is kept while the account is active and afterward only as reasonably needed for deletion completion, security, disputes, legal obligations, and legitimate operational records.
• Single-use email-verification, password-reset, and deletion tokens become eligible for scheduled cleanup when their configured validity ends, including after use. Reservation and floor-operation idempotency or replay records, including a normalized request hash, status, and limited result needed to return the same operation outcome, become eligible for deletion after 24 hours. Those scheduled cleanup jobs normally run once per day, so physical retention can approach 48 hours; delayed or failed cleanup may retain a row longer until a later successful run.
• A new web identity that does not match an existing account is held as a short-lived account-signup intent containing the selected provider identifier, verified email, provider-supplied name, signup-market authority, a hashed one-time ticket, and timestamps. The intent is valid for 30 minutes, is consumed when account creation completes, and may remain after expiry until it is replaced by a later attempt or removed by cleanup. Short-lived mobile authentication state, nonce, ticket, challenge, and reauthentication records likewise expire for use at their configured deadline. Consumed or stale records are removed during completion or a later authentication cleanup; physical removal need not occur at the exact expiry time, and limited security records may remain where reasonably needed to investigate the flow.
• An email-outbox row whose creation time is more than 90 days old normally becomes eligible for cleanup if it is sent or cancelled, or if it is dead or expired and an operator has acknowledged it. The 90 days runs from row creation, not from acknowledgement, so an old dead or expired row may become eligible immediately when it is later acknowledged. An unacknowledged email-delivery failure may remain longer while it awaits operational review. SMS outbox, delivery, and consent ledgers do not currently have an automated deletion schedule and may remain as operational, compliance, and dispute evidence. Metadata for successfully completed physical file-deletion work normally becomes eligible for cleanup after 30 days; incomplete or failed work may remain while it is retried or investigated.
• The append-only operator legal-acceptance ledger currently has no automated deletion schedule and may remain as contract, compliance, and dispute evidence. Account or restaurant deletion removes the live user and restaurant foreign keys but preserves the detached internal grouping references copied from the former numeric IDs, accepted document and disclosure versions, disclosure digest, market, client kind, method, and server acceptance time described above. Those grouping references are not public identifiers and are not by themselves a claim that the retained ledger is legally anonymous.
• Google Places predictions, details responses, temporary autocomplete session tokens, and any transient coordinates used for neighborhood fallback are used to verify the address and derive its neighborhood and are not retained by Tade as durable provider records. Tade may retain the selected Google place identifier indefinitely and retains the resulting address and neighborhood as business information; it does not retain provider coordinates.
• The current restaurant-reset action is available only to a compatible password-based account; a Google- or Apple-only account must use the separate account-deletion flow or support. Reset removes operational content while preserving the account shell, immutable restaurant country, and retained subscription, promotion-redemption, deletion-audit, messaging, consent, opt-out, email-outbox, and related limited security or legal ledgers. Before clearing the data, the workflow enqueues transactional cancellation notices for affected future reservations only where current reservation-email authorization permits them, and it queues generated image files for durable physical deletion after the database reset commits.
• For an ordinary active account that is not bound to temporary controlled-rollout or upload authorization, account deletion removes the user, restaurant, and operational content from the active database and cancels active communication payloads where designed. Before removal, the workflow enqueues transactional cancellation notices for affected future reservations only where current reservation-email authorization permits them. Any temporary release-control or upload authority must first be revoked or retired through its controlled procedure; deletion fails closed instead of silently discarding that authority. The public production runtime does not currently enroll operators in those dormant controls. Generated image files are queued during the deletion workflow for physical deletion after the database deletion commits; a durable deletion outbox records the work and retries failures, so a transient failure may delay physical file removal. The workflow may preserve subscription and billing ledger rows—including provider customer or subscription identifiers, transaction amount, tax, currency, plan, billing cycle, status and dates, payment-card last four digits, and a receipt URL—without the live restaurant foreign key but with a detached internal restaurant grouping reference copied from the former numeric restaurant ID. Paid subscriptions are currently inactive, so an account may have no such row. It may also preserve promotion-redemption rows containing a promotion code reference, use time, and the same kind of detached internal restaurant grouping reference; deletion audit; the operator legal-acceptance ledger; SMS delivery and consent ledgers; the global opt-out register; the reservation-email authorization ledger; and limited email-outbox or security records. The detached grouping reference is not a public identifier and is not by itself a claim that a retained ledger is legally anonymous. The deleted account and its removed database data cannot be restored; a later Google or Apple sign-in may create a separate new account rather than revive the deleted account.
• The append-only reservation-email authorization ledger may remain after guest anonymization or account deletion as limited compliance and dispute evidence. It may contain internal reservation, restaurant, and customer references; authorization status, version, method, and disclosure; a masked address; a keyed matching digest and key version; address contact version; staff actor; and time. The masked address and keyed digest are not a readable full email address. No automated deletion schedule is currently enforced for this ledger; requests about a specific record may be directed to the Privacy Officer.
• The current sign-in flow validates Apple identity tokens but does not retain the Apple refresh or access token required to revoke Sign in with Apple authorization programmatically. Deleting a Tade account still removes the Tade account and data described here. Apple-linked operators are instructed in the deletion flow to separately stop using Tade in Apple Account settings, following Apple's current instructions. Tade will update this Notice before enabling server-side storage and revocation of Apple authorization tokens.
• Guest profiles inactive for more than three years are normally anonymized as described in the Guest Privacy Notice. A keyed blocked-contact fingerprint is used for block matching for up to five years, ending at its recorded expiry. After expiry, it is ignored for matching and becomes eligible for scheduled cleanup, although physical row deletion may occur later if cleanup is delayed or fails and must run again. Full-number STOP state may remain without a scheduled deletion date.
• Some database objects reserved for future features, including notifications and billing, may have schema records even when the feature is inactive. Tade does not claim a retention period that current code does not enforce; requests about a specific record may be directed to the privacy contact.

11. Security

Tade uses safeguards designed for the sensitivity of the information, including encrypted transport, Google/Apple token validation, provider-specific nonce/state protections, secure device storage for persistent app sessions, fresh authentication for destructive web actions, access controls, image validation and isolation, encrypted pending email payloads, provider webhook validation, request limits, and privacy-restricted structured logs. No system is completely secure. Restaurants must also control staff and device access, protect provider accounts and sessions, and promptly report suspected incidents.

If Tade becomes aware of a suspected privacy or security incident, it will take reasonable steps to contain and assess it, preserve the incident record required by applicable law, and coordinate with affected restaurants and service providers. Tade will notify affected individuals and applicable privacy regulators when and in the manner required by law; not every security event legally requires individual notification. A restaurant remains responsible for incident duties arising from its own staff, devices, systems, or independent handling and must give Tade the information reasonably needed for a coordinated response.

12. Operator and Staff Rights

Depending on applicable law, an operator or staff user may request access to personal information, information about its use and disclosure, correction, withdrawal of consent, objection or restriction, portability where applicable, deletion, or review of compliance. Business records and guest data may be subject to the restaurant's authority, legal duties, and retention needs, so not every requested deletion can remove every record immediately.

Send a request to admin@thetade.com. The Privacy Officer may verify identity and business authority, identify the relevant restaurant or provider, investigate the concern, correct or explain the handling at issue, and provide a written response or available escalation route.

To make an access or correction request under British Columbia's Personal Information Protection Act (BC PIPA) for information under Tade's control, send a written request with enough detail for Tade to identify you and the information or correction sought. When BC PIPA applies, Tade will respond within 30 days unless the statutory period is lawfully suspended; an access-request period may also be extended as BC PIPA permits. If Tade extends an access-request period, it will state the reason, expected response date, and available complaint rights. If Tade refuses access to all or part of requested information, it will give the reasons and BC PIPA provision relied on, contact information for a person who can answer questions, and notice of the right to seek review by the Office of the Information and Privacy Commissioner for British Columbia within 30 days. Where BC PIPA permits an access fee, Tade will provide a written estimate before charging it; no access fee will be charged for employee personal information.

If Tade accepts a BC PIPA correction request, it will correct the information as soon as reasonably possible and send the corrected information to each organization to which Tade disclosed it during the previous year. If Tade does not make the correction, it will annotate the information under its control with the correction that was requested but not made, as BC PIPA requires. For other requests, Tade will respond within the period required by applicable law and explain any permitted refusal. You may complain to the Office of the Privacy Commissioner of Canada at priv.gc.ca, the Office of the Information and Privacy Commissioner for British Columbia at oipc.bc.ca, or the regulator in your jurisdiction.

When Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) applies, make the access or correction request in writing. Tade will assist a person who says they need help preparing it and will respond with due diligence, no later than 30 days after receipt. If Tade uses a permitted extension, it will send notice by the original deadline stating the new deadline, the reason, and the right to complain to the Privacy Commissioner of Canada. A refusal will be provided in writing with the reasons and available recourse. Before charging any permitted response cost, Tade will disclose the approximate cost and confirm that the request is not withdrawn. Information that is the subject of the request will be retained as long as necessary for the individual to exhaust available PIPEDA recourse.

California residents

If the California Consumer Privacy Act applies, California residents may have rights to know, access, delete, and correct personal information, to opt out of sale or sharing, to limit certain uses of sensitive personal information, and not to receive discriminatory treatment for exercising a right. Tade does not sell personal information or share it for cross-context behavioral advertising. Use the contact above to submit a request.

13. Children

Operator accounts and the manager app are intended for adults authorized by a restaurant business, not children. Do not permit a child to create or operate an account. Guest information involving a child should be entered only by an authorized adult and limited to what is reasonably necessary for the visit.

14. Changes and Contact

We may update this Notice when products, providers, or law changes. We will revise the effective date above. Material changes will be announced through the affected account or app before or when they take effect and, where we have a suitable contact address and law requires, by email or another direct channel. For privacy questions, requests, or complaints, contact:

Tade — Privacy Officer
Email: admin@thetade.com
Location: Vancouver, British Columbia, Canada