This Privacy Policy explains how Puff Geeks LLC collects, uses, stores and shares information through our mobile apps, vending kiosks, operator console, website and related services. It applies to consumers and guests, operators, employees and venue partners. This is a pre-launch revision describing implemented features and their current limitations, not a statement that all features are available or that deployment and legal review are complete. Reading this notice or using the Services does not itself grant optional location sharing, network contribution or other separately requested permission.
Account records include your email address, display name, account status and role. Password accounts use salted one-way bcrypt hashes rather than stored plain-text passwords. External sign-in can also create provider-linked account identifiers. Business accounts may include operator/team relationships, machine grants, business/contact details, contractual choices and fleet settings. Those settings can remain linked to an identifiable person or business; a business purpose does not automatically make them nonpersonal. Authentication records can include short-lived recovery or sign-in credentials, session identifiers, IP addresses and user-agent information used to secure and revoke access.
Purchase records identify the machine, items, quantities, prices, tax, discounts, payment and transaction outcomes, and timestamps. A signed-in purchase or a receipt you claim can be linked to your account. A guest purchase is not linked to a signed-in Puff Geeks account, but may retain transaction and processor references; that does not make every guest record anonymous. Battery rentals also record the cabinet, pack, selected plan, pickup/return times and charges. Payment integrations use payment processors rather than storing full card numbers or PINs in our transaction or saved-card records. If you save a card, our records contain an opaque processor token, processor customer identifier, brand, last four digits and expiry month/year. Removing a saved card disables new use but retains stored processor references and display details in a soft-deleted record. Account closure disables saved instruments and clears their chargeable tokens during supported local cleanup. A processor customer identifier can remain on the disabled record while a deletion request awaits a matching provider acknowledgment; it is removed when that acknowledgment is recorded. A confirmed customer-deletion response is not proof that the processor erased every historical or legally retained record. Separate provider obligations and the retention limitations in Sections 13 and 15 apply.
Real age-restricted purchases are currently unavailable while the complete purchaser-assurance, product and premises requirements are being established. A successful barcode read alone does not establish that the person presenting it is the document holder or that a site may sell a restricted product. The barcode-check feature sends a decoded document barcode from the kiosk to Puff Geeks and parses it on our server; it does not send it to a separate identity-verification vendor. The checker reads information needed for age and document-validity checks. Our barcode verification records contain the result, method, required age, attempt number, timestamps and relevant transaction/account and generated session references. These verification records do not contain your birth date, raw barcode, document number, document image or a stable fingerprint of the identity document. Do not send identity documents through support or other upload features. Any future verification method must be separately reviewed and disclosed before use.
If you participate in Puff Points, we maintain your points balance and a ledger of every points transaction (earnings from purchases, redemptions, bonuses, and expirations) with timestamps and the reason for each entry. The program also includes reservation tokens (reserve tokens and Pro tokens); for these we maintain the same kind of auditable ledger — how each token was earned (for example, completing an optional rewarded advertisement, reaching a purchase milestone, a Pro subscription's recurring grant, or an individual purchase) and how each was spent or refunded. To operate purchase milestones we keep a running count of units you have purchased. If you subscribe to Pro, we store your subscription status, start date, and next token-grant date, and our payment provider processes the subscription charge (we never see your card number — Section 3). If a reservation you hold is ever released to accommodate a Pro reservation, that event, your automatic refund, and your make-good credit are recorded on your reservation and shown to you in the app — nothing about that process is silent. These ledgers exist so your balances are always auditable and disputes can be resolved. Points and tokens are promotional program credits, not money, and have no cash value. Use or expiry ends the validity of a code, not necessarily storage of its record or code value. Settled claim/redemption records follow the later configured retention cutoff in Section 13; reservation records currently have no equivalent automatic sweep.
Sharing a location-based demand signal is optional and off by default. Nearby-machine sorting can work on your device without this sharing. After you explicitly choose to share under the current notice, foreground nearby lookups may transmit latitude and longitude to our server. Our apps normally throttle attempts to 15-minute intervals while running; this is not once-a-day collection or a guaranteed server-wide maximum. The server converts each position to a grid cell, currently 0.0025 degrees per side by default, and stores its centre, your account identifier, UTC day and repeat count rather than the incoming exact coordinates. Distances vary by latitude. Several cells in one day can reveal a coarse movement pattern: this is account-linked collection, not anonymous data. Records support demand summaries for authorized operators near their machines and authorized platform administrators. The current default release threshold is five distinct opted-in accounts in a cell over a 30-day lookup window. Thresholds reduce exposure but do not guarantee anonymity; new or overlapping releases, changed counts/groups and other information can allow further inferences over time. Rereading identical cached information is different from receiving new values or changed groups. Once withdrawal is recorded, new demand contributions are refused. A successful withdrawal deletes your cells from the live demand table; if deletion fails, sharing stays off and you can retry or contact support. Withdrawal cannot recall summaries already received or erase separate alert records, all consent evidence or backups. Retention uses the calendar-date schedule in Section 13. OPTIONAL STOCK ALERTS are a separate, initially-off choice. They use a list derived from your recent purchases and can select nearby restocks using a recently contributed demand cell under current demand consent, or the machine you last purchased from. A contributed cell is not necessarily your latest same-day position. Proximity, purchase-history thresholds and cooldowns depend on the configured alert policy. Turning stock alerts off deletes the live product-affinity list and alert history when the request succeeds; purchase records remain and an already-in-progress message may still arrive. Battery-return reminder timing uses aggregate cabinet return patterns, not your individual movements.
ADAPTIVE ALERT SELECTION: this option is off by default. When separately enabled, the system can compare bounded alert-selection settings and use later reservation outcomes to adjust future selection. Alert records can include the selected policy variant, account and machine references, distance, send time and linked outcome. Activation and the permitted learning purpose require their own review; approval of a price experiment does not approve this separate use.
Support records contain the ticket, messages, relevant machine/transaction references, account or guest contact details and resolution history. Machine tickets are scoped to the responsible operator and authorized staff; platform tickets have separate platform access. Messages can contain information you choose to include, so do not send passwords, payment credentials or identity documents. We use support records to respond, resolve disputes and maintain necessary service evidence. Notifications can concern reservations, rentals, purchases, security or availability alerts you enabled. Email, SMS and push delivery providers receive the addressing and message information needed for delivery and may process associated technical information. Push tokens identify app installations and can be removed on sign-out, account cleanup or provider invalidation. Event/channel preferences govern optional notifications; essential security or legal messages may use a separate channel. SMS, where enabled, is optional: saving a number and enabling SMS requests automated messages for the selected events. Frequency varies and message/data rates may apply. You can disable SMS per event or remove your number. Reply STOP to stop texts through the messaging provider; reply HELP or contact support@puffgeeks.com for help. Consent is not a condition of purchase or rental. Provider delivery and suppression operations must be configured correctly; this notice does not represent a completed live messaging-provider audit.
Servers process technical information such as IP addresses, request times and security events to operate the service and prevent abuse. Authenticated sessions can retain IP and user-agent information. Machines send status, software, inventory and error telemetry; those records can be linked to other timed operational events. Consumer QR scanning processes camera frames on the device. Location used for the nearby-machine sort stays on the device for that sort. Separately, the optional demand feature transmits latitude and longitude to the server before coarse-cell storage, as described in Section 5a. Fleet route planning and tracking have the different practices in Section 8. Business users can deliberately upload product photos, ad creatives, directory attachments and machine models. Uploaded content and metadata can contain incidental personal information or surroundings; do not assume an equipment-related upload is nonpersonal. Visibility depends on the feature: published catalog/ad content differs from fleet-restricted scans or private documents. Browser storage supports sign-in, language/interface choices and abuse-prevention features. Clearing browser storage is not deletion of server records. The application does not change its processing in response to a browser Do Not Track signal. Contextual ads are selected by placement such as screen or machine, rather than a customer advertising profile. Third-party sign-in, payment, messaging and mapping services have their own processing described in Section 11.
Fleet-management tools run on the backend. They use machine/product sales, stock and operational records for demand forecasts, restock and placement recommendations, route plans, maintenance priorities and price-related decisions. Forecasts can feed automated operations; calling every output merely advisory would be inaccurate. Sales anomalies offer possible explanations, not established causes. Maintenance risk uses an operational fault-signal proxy, not a confirmed mechanical diagnosis. Model and prediction records can include captured inputs, forecast/target times, source/model/feature versions, sample counts and eventual outcomes. Once the September 2026 provenance update is applied to a database, each new slot inventory journal entry records which operator account and machine assignment the server's observed ownership history held at the moment the entry was accepted, plus the acceptance time and, for offline sales, the kiosk's reported sale time; entries written before that update, and entries whose ownership or timing cannot be established, are marked unbound or excluded. Any owner-scoped learning over these entries is required to exclude unbound or excluded entries rather than attribute them to the current owner; no forecasting or maintenance model currently consumes these ownership bindings. Machine day-context records include weather, public events and holidays from geographic enrichment. Learned evidence and fallback assumptions depend on the particular engine and available history; missing evidence can make a learned mode unavailable. Individual consumer purchase identities are not the target of these machine-level forecasts. Route planning uses machine coordinates and, if the user requests a start from their location, the supplied start position. Visit records identify the driver, machine and check-in/check-out times. A separate route-time calibration summarizes supported visits by operator and time band; those summaries and underlying visits have different retention. Battery redistribution uses cabinet rental/return counts. ROUTE-SESSION LOCATION SHARING requires the driver's separate consent. An active session may be driver-started or assigned by an authorized operator or administrator; assignment does not grant consent for the driver. The server checks current driver consent and account/team authority on session start and incoming pings. Android can publish through its foreground service during an active session even when its screen is not frontmost; the iOS route view uses foreground location updates. The withdrawal control stops local publishing and asks the server to withdraw permission and close active sessions. Once withdrawal is recorded, new pings and sessions without a new grant are refused, including when later cleanup needs retry. A disconnected device may not learn of a change made elsewhere until it reconnects. Earlier locations and route records are not erased by withdrawal, and already-received information cannot be recalled. Authorized fleet and platform personnel can use the permitted location for route operations; mapping, routing and navigation disclosures are in Section 11. Creation of identified GPS-derived speed samples has been stopped; existing samples and separate operational aggregates are addressed in Section 13. Optional cross-fleet uses have separate purposes and limitations in Section 8a. Business scans/models and related uploader, machine and processing records are governed by their upload access controls and retention; do not deliberately capture people or identifying surroundings.
Optional operator network contribution has three separate existing purposes: DEMAND_NETWORK_POOL for sales/inventory-derived product and venue demand statistics; SCOUT_NETWORK_PRIOR for eligible learned Scout weights and placement sample counts; and OPERATIONAL_BENCHMARKS for service durations, travel-speed statistics, restock intervals and cabinet rental counts. Eligible owners grant current-version permission for each purpose; contribution does not grant broader recipient access. Consumer demand choices and worker tracking permission are separate, and an operator cannot grant them for other people. The legacy reciprocal Scout Placement Benchmark is a different opt-in described in Terms Section 11. Existing programs check current eligibility and can invalidate or suppress their affected releases after withdrawal; some daily outputs remain unavailable until a later release period. This is not a complete model/backup deletion system and does not guarantee exact model unlearning or recall of previously received data. Shared panel training is currently unavailable without its required data authority, and shared seasonal calculation is unavailable because the source records lack required assignment-at-observation evidence. This does not disable every local model, Scout statistic or existing optional network program. Sample floors, influence limits, rounding/banding and daily releases where applied reduce exposure but do not provide differential privacy. Repeated releases, overlapping cohorts, changed values and other information may permit additional inference. These permissions do not authorize customer-specific pricing, a new model purpose or a price experiment. Classification of reciprocal exchanges, recipient obligations and external activation requires the separate review described in Terms Section 11; a lack of cash payment does not settle every legal sale/sharing definition.
The normal consumer QR-scanning feature does not upload its camera frames. Nearby sorting alone does not send your location to Puff Geeks; if you separately enable demand sharing, latitude and longitude DO reach the server before coarse-cell storage. Our barcode verification records do not contain raw identity documents or birth dates, as described in Section 4. These statements concern those specific features and records, not a guarantee that user-supplied support messages or business uploads cannot contain sensitive information. We do not request access to your contacts for these features. Contextual advertising does not create a customer advertising profile. Employee route-session collection requires an active, currently permitted session, which may be driver-started or assigned; it is distinct from consumer nearby sorting. Provider and upload practices must not be inferred from these limited exclusions.
Information is used to operate purchases, rentals, rewards and reservations; resolve support and payment disputes; maintain accounting and appropriate legal evidence; secure accounts and machines; and operate fleets through stock, route, maintenance and planning tools. Optional location-derived demand summaries, stock alerts and network contributions have their separate choices and boundaries above. Machine-level predictions can inform or drive automated inventory and ordinary price changes, while price experiments require separate exact-proposal approval under their current controls. An anomaly or maintenance proxy is not proof of wrongdoing by a customer or worker. The backend includes a pre-launch NIC lifecycle control plane designed to govern findings, evidence links, engine governance, cases, message intents, policy evaluations, subject references, rights obligations, receipts and restored-data quarantine. It stores no production lifecycle policy by default and does not make ordinary NIC production writers, destructive actions or restored-data release available merely because those tables and services exist. This notice does not authorize new employee-performance surveillance, unrelated reuse of identification data or a new consumer-data pricing purpose. A data source being public, aggregated or useful to a model does not alone establish permission for every reuse.
Recipients differ by purpose. Payment and payout providers handle the information needed for charges, refunds, saved cards and settlements. The configured barcode checker runs on Puff Geeks' server and is not a separate identity-verification company. Operators and specifically authorized staff can access records for their permitted fleet and support tasks; authorized platform administrators can have broader operational access. Venue partners receive their permitted venue/machine information, not general staff authority. Route-session location is available to the driver and authorized fleet/platform users. Mapping and road-routing services can receive machine coordinates and supplied route/start positions; a user-initiated navigation handoff sends the destination to the chosen navigation app. Direct network requests can also reveal connection/device information to a provider. Email, SMS and push providers process delivery addresses/tokens, messages and associated technical information. Geographic enrichment uses selected search/machine coordinates and dates; bulk public datasets already stored locally are different from live external queries. Sources used by the software include OpenStreetMap, Census/LEHD, public GTFS transit schedules, Overture places, IPEDS, FBI/public traffic data, Open-Meteo, public-holiday feeds, Ticketmaster and public sports/calendar feeds. Public business listings can still identify individuals; commercial use and provider terms need their own review. Demand heatmaps return cell centres and counts rather than individual account IDs; operators receive eligible summaries around their machines and authorized administrators can receive broader summaries. The default threshold/window and inference limits are in Section 5a. Stock-alert/reward reports use aggregate outcomes, not a list of which customer received each alert; underlying personal records remain separate. Optional network recipients and reciprocal exchanges are described in Section 8a and Terms Section 11. Hosting, storage and configured service providers may also process records to operate the platform. We may disclose records where required by law or necessary to protect rights, safety or security. This pre-launch revision does not assert that all proposed provider contracts, subprocessors, retention arrangements or external-sharing approvals have been executed.
The software uses server-side role permissions, fleet and ownership checks, individually revocable authenticated sessions, and restricted database privileges to limit access. Consumer purchase history and account records are scoped to the account; employee access is limited by team and machine grants; operators manage their own fleets. A venue partner is not treated as platform staff. Authorized administrators may have broader access for platform operation and support. Route and visit records follow fleet access rules, and route-session location has additional driver/operator restrictions. Network contribution permission and permission to receive an aggregate are separate controls. These are implemented safeguards, not a claim of perfect enforcement or a substitute for ongoing testing and operational access review.
Different records have different retention needs; a live-table deletion does not establish deletion of archives, backups, models or another organization's records. Account data remains while the account is active, subject to applicable requests and obligations. Certain financial, tax, contract, support, consent and model records do not yet have a complete approved automatic-expiry schedule. That gap is not an assertion that indefinite identifying retention is necessary or legally permitted. Necessary fields, purpose, period, holds and controlled disposal require separate review before the affected real processing begins. AUTOMATED OPERATIONAL RETENTION currently defaults to 400 days for prediction-ledger records, machine day-context, transaction traces and warehouse journals; 365 days for field visits, route-session summaries and security/audit events; 30 days for raw route-session GPS and demand cells; 180 days for anomaly history, resolved faults, stock-alert affinities and alert records; and 90 days for notification logs, settled claim/redemption codes and route-plan audits. The NIC lifecycle catalog currently covers 31 classes: 13 existing intelligence/governance classes, seven lifecycle-control classes, four Stage 4 journals (sales-anomaly detection events, placement-outcome snapshots, Scout consideration sets and Scout selection events), four Stage 5 decision ledgers (action opportunities, action proposals, message opportunities and message exposure events) and three Stage 6 governance records (the human decisions recorded on proposals, the tasks those decisions produced and delivery activations). A decision record names the person who approved or refused one proposed action, the exact bytes they decided on and the reauthentication proof consumed for it; a task record names which proposal and decision authorised an executed action, the external record it produced and how it ended, and carries no consumer personal data; a delivery activation records which class of message the platform has authorised to leave the system, for which purpose, recipient class, channel and provider environment, with the digest of a closed recipient list and the person who authorised it — no message content and no consumer personal data. A decision ledger records what the software could have chosen at the moment it chose; it does not select, send or delete anything on its own. Those control records can themselves contain account, actor, operator, machine, case, engine or other subject references, policy/authority versions, hold facts, work status and evidence digests; calling them metadata does not make them nonpersonal. Its purpose-matched engineering proposals reuse the platform's current default configured periods: 90 days for NIC message-intent work and message exposure events; 180 days for operational findings, evidence links, evidence progress, cases, case revisions, policy evaluations, subject references, sales-anomaly detection events and message opportunities; and 365 days for registries, qualification/governance evidence, lifecycle policies/enrollments/holds/obligations/receipts, restore-generation evidence, placement-outcome snapshots, Scout consideration-set and selection records, action opportunities, action proposals, the human decisions recorded on them, the tasks those decisions produced and delivery activations. These numbers are not active NIC deletion promises. No production lifecycle policy or schedule is seeded, and ordinary producer activation, disposal and restored-data release remain unavailable. Each class still needs an approved purpose and authority, an immutable source-derived trigger, exact boundary, access and hold rules, minimal retained-receipt justification, safe rights handling and successful backup/restore deletion replay. Missing, expired or revoked authority must refuse processing rather than silently choose a default; a future implementation must not substitute updated-at time for an absent lifecycle trigger. Sweeps normally run every six hours for the separate operational classes already enrolled above. Demand cells use a UTC-calendar-date cutoff: dates earlier than the cutoff are eligible, while rows on the cutoff date remain until a later sweep. This is not an exact 720-hour deadline. Operational pauses, configuration and conservative monthly-partition removal can extend deletion intervals. Slot-level inventory journals are currently preserved: stock archival and retirement are unavailable while their custody, restoration and approved-lifecycle gates remain incomplete. The configured 400-day inventory age is therefore not a current promise that these records are deleted at that age. Creation of identified GPS-speed derivatives has stopped, but existing samples can retain driver and session links and do not expire automatically with raw GPS. Those samples, archives, model registries, placement summaries and completed experiments lack equivalent automatic expiry. The proposed ID-outcome disposal schedule is inactive: code requires matching signed approval before eligible deletion/minimization, separately from financial records. It is not a current 30/365-day deletion promise. Operator network consent evidence records owner/actor identifiers, purpose, grant/withdrawal, version and server time in append-only history with no automatic expiry currently configured. Consumer demand stores its current consent state, version and revision; it is not that same event-history system. Consent withdrawal does not itself dispose of retained evidence. A removed saved card remains a soft-deleted record with processor references until further cleanup. Account closure records a minimal recovery job linked to the account, request/completion times, attempt count and fixed status/error codes. Supported local cleanup clears saved-card chargeable tokens; a disabled card can retain its processor customer identifier for retry until confirmed customer deletion is recorded. Display details, the confirmation time and separate financial records can remain. These recovery and pending-reference records do not yet have an approved automatic-expiry schedule; that is an unresolved lifecycle requirement, not permission to retain identifying records indefinitely. Successful demand/stock-alert withdrawal deletes the corresponding live records described in Section 5a. Other account cleanup, uploaded files, derivatives, legal holds and provider records need their own handling. A platform-wide restored-backup release/deletion process has not yet been established. Contact support about records not covered by a self-service control; do not assume every historical copy expires with its source.
Implemented software safeguards include salted password hashes, signed expiring tokens tied to revocable sessions, server-side input validation and fleet/role checks, rate limiting, production configuration checks and hashed, rotatable machine credentials. New prediction-ingestion and operator-consent records have integrity protections. These are not claims of perfect enforcement, independent certification or a tamper-proof system. Actual transport/storage/backups, deployed database privileges, key custody, logging and incident operations require deployment verification; local source and tests do not prove those operational facts. Before handling real personal information, the deployment and responsible parties must establish appropriate safeguards. If an incident affects personal information, notification duties must be assessed for the actual records, people and applicable law. No completed penetration test, production restoration exercise or security certification is asserted by this revision.
Subject to applicable law, you may request access, correction, deletion or a portable copy of your information. For eligible accounts, signed-in export creates a private, expiring download from a consistent snapshot of supported account and activity records. Its manifest identifies delivered categories and categories withheld or requiring assistance; it is not a copy of every retained dataset or another organization's records. Included categories are paged without silently treating a truncated list as complete. A build that exceeds its resource limits or cannot finish is not offered as a completed export; contact support for assistance or additional records. Operator and administrator exports use a managed request because their records can include fleet and third-party information. Download requires the requesting account and its separate download token. Cancellation revokes further authorized download and queues cleanup of stored export files; it cannot recall a copy already downloaded or shared outside the app. Password-based self-service closure is available for eligible accounts; accounts without a usable password, including some external-sign-in accounts, need assistance. OPERATOR and ADMIN accounts require support-assisted closure because fleet ownership and obligations need review. An accepted password-authenticated closure records its recovery job and disables access together. It clears external-sign-in identity links and obsolete sign-in credentials. Supported cleanup and provider acknowledgment are tracked separately; an authorized internal recovery process can resume recorded work after interruption without restoring the account. When the backend workers are running, incomplete recorded account closures and export builds are retried automatically; export cancellation and expiry also have recoverable cleanup. These workers do not constitute a complete all-dataset rights or external-provider erasure workflow. The pre-launch NIC control plane can represent exact-class subject references, holds, work obligations and completion receipts, but it is not yet integrated as a complete source for account export, correction, suppression, transfer or closure. Existing NIC records have not been comprehensively back-indexed, and subject identity inside nested evidence cannot be inferred merely from fleet ownership. Until that integration and its restoration replay are accepted, requests involving those classes require managed review and must not be reported as complete solely because the ordinary account worker finished. Closure removes or replaces specified identifiers and optional-service records; it does not make every linked record anonymous or prove that every cleanup step, external-provider request or backup deletion completed. If a request fails, account access may already be disabled: contact support for review. Managed requests have recorded status and authorized review actions, but not every dataset, provider or legal determination is automatically resolved. Operators can withdraw contribution purposes separately; demand sharing and stock alerts have separate consumer choices. Employee tracking withdrawal closes active sessions and prevents new pings/sessions after server withdrawal; previous records follow retention and applicable rights. Requests need appropriate identity/authority checks without unnecessary sensitive material. Applicable deadlines, exceptions and appeal rights depend on the relevant law. Accessibility assistance can be requested through Section 19; this does not waive necessary identity, payment or safety controls.
The Services are not directed to children under 13. If you believe a child under 13 has provided personal information, contact support so we can investigate and take the action required by applicable law, including deletion where required. Do not send additional identity documents with an initial report. Under-13 privacy handling is different from the separate 21+ restricted-purchase requirement; real restricted sales are currently unavailable as described in Section 4. This notice does not establish that every youth-safety or actual-knowledge handling procedure is complete.
Privacy rights, exceptions, appeals and notices depend on the person's location, the data and whether the relevant law applies to the business and processing. We provide the contact path in Section 19 regardless of state, without asserting identical rights or thresholds everywhere. The intended initial scope is Pennsylvania with possible later U.S. expansion; software availability is not permission to activate every feature in every jurisdiction. Reciprocal network exchanges require assessment of recipients, benefit/consideration, identifiability and permitted use. No cash charge alone does not establish that an exchange is outside every legal sale or sharing definition. External contribution, release, new providers and jurisdiction expansion remain subject to their separate reviews.
The version and dates identify this notice. Material changes require appropriate communication and review; publishing new text or continued use does not itself grant optional demand sharing, stock alerts, worker tracking or operator-network contribution. Where the feature requires a new notice version, the user must make the choice explicitly. Earlier records and choices are not retroactively rewritten by this revision. The required notice, consent and activation steps depend on the actual changed practice.
Questions, requests, or complaints about privacy can be directed to: Puff Geeks LLC — Privacy, email: support@puffgeeks.com. Please include enough detail for us to locate your account and understand your request. If you are unsatisfied with our response, you may have the right to lodge a complaint with your state attorney general or applicable supervisory authority. Accessibility questions or accommodation requests (for example, this Policy in another format) can be sent to the same address with the subject line “Accessibility”; our Accessibility Statement explains what to expect.