Privacy Policy

This policy describes the current data flows for eddy.delivery and the Eddy Chrome extension. Restaurant ordering providers, delivery platforms, the Chrome Web Store, analytics providers, and other destinations you open have their own policies.

On supported DoorDash, Uber Eats, and Grubhub restaurant pages, the extension reads the page's restaurant name. It also reads explicit location text shown on the page to resolve a supported metro locally, unless you selected a metro in Eddy's settings. Each lookup sends only the restaurant search term and the selected or resolved metro to Eddy to look for a current verified direct-order destination; the full page location text is not sent. The extension can read cart and checkout details—including item names, quantities, visible prices, and fee totals—locally on the supported page. The current direct-link release does not send final cart contents or payment data to Eddy's server, does not calculate cross-platform totals, and does not rank a price winner.

A lookup is the restaurant-and-metro request described above. When a verified result is shown, the extension sends an exposure event. When you open that result, it sends a click event. If you then select “I placed the order there,” it sends a user-confirmed-order event. These outcome events contain random subject, journey, and event identifiers; a restaurant identifier; ordering channel; event time; and extension version. Eddy transforms the subject, journey, and idempotency identifiers with keyed HMAC pseudonyms before storage. A user-confirmed order is your attestation, not proof of a price difference or completed payment. When you open a direct-order link from Eddy, referral evidence can store the restaurant name and slug, metro, source, platform, and destination origin and path. Query strings and fragments are removed before storage. Clicks and completed orders are kept as different event types.

If you submit a possible direct-order link from the extension, Eddy sends and stores the page restaurant name, selected or resolved metro, and HTTPS URL you entered as a pending-submission event. If you send feedback or a restaurant correction or claim, Eddy stores the fields you provide. Depending on the form, those fields can include an email address, message, restaurant name, supported metro or city, page path, and HTTPS ordering URL. Do not submit payment information, receipt contents, final cart contents, or delivery addresses through these forms. A submission does not establish ownership or reporting access. Exact duplicates can reaffirm an existing verified destination; new, different, or ambiguous URLs remain private pending evidence review.

Public write endpoints use bounded request sizes and quotas. Eddy derives keyed, non-reversible source fingerprints from limited network request data to prevent abuse and enforce those quotas. Raw IP addresses are not stored in the outcome, referral, feedback, partner-candidate, or community-intake records described above. Daily quota records contain only the keyed fingerprint, date, category, and count.

The website can use localStorage for preferences such as favorites and metro selection. The extension uses Chrome storage for the selected metro or campus and random outcome identifiers. It also stores a recently-shown key and timestamp on supported delivery pages so it does not repeatedly display the same notice. You can clear site data through browser controls and extension data through Chrome controls.

Website pages can load an Umami analytics script from umami.projectgreenbelt.com. Google Analytics loads only when a Google Analytics ID is configured. Eddy's hosting, network, database, GitHub, and Chrome Web Store providers process standard technical data needed to deliver and operate the service. The legacy first-party /api/events and /api/telemetry write endpoints are retired.

Eddy uses current data to return verified restaurant links, operate the extension, limit abuse, avoid repeat notices, measure the direct-link funnel without treating clicks as orders, investigate feedback, and maintain ordering-destination accuracy. Eddy does not use modeled comparison records as verified savings evidence.

The current database does not enforce one automatic deletion deadline for submitted links, feedback, partner-candidate records, referral clicks, or outcome events. Daily abuse-quota records are separated from product-event records. The recently-shown browser key expires for product use after 30 minutes, although its local entry can remain until replaced or cleared; other browser-stored settings and identifiers remain until replaced or you clear them. Eddy will update this section when automated server-side retention is adopted.

You can browse the website without creating an account, clear site or extension storage, block optional analytics scripts, and remove the extension. For an access or deletion request, email jon@eddy.delivery with enough information to locate the record. Because some identifiers are random or pseudonymized, Eddy may not be able to connect a server record to you without an identifier from your browser or extension.

Material changes will be posted on this page with a new updated date.