Public beta
Privacy
How the public beta uses browser storage, anonymous analytics, external recipe services, and production logs.
No Fluff Dinner has no user accounts and does not ask for your name or email to make a recipe card. This page describes what the current code does; it does not claim a retention period or provider setting that the beta does not implement.
What stays in your browser
The app creates a random anonymous ID in local browser storage so it can estimate repeat use. A separate random session ID is kept in session storage so activity can be grouped into one browser session. These IDs are not accounts and are not connected to a name or email.
Imported and AI-generated recipe cards are saved to local browser storage as recent recipes. The saved records include the recipe, ingredients, instructions, notes, and source attribution. Recent history is limited to 20 recipes. Your Meal Plan, scale choices, and grocery-checklist state are stored there too.
There is no time-based expiry for this browser data. It remains until you clear Recent Recipes or the Meal Plan in the app, clear this site's browser data, or your browser removes it. Clearing site data also resets the anonymous ID. Session storage normally ends with the browser session.
Anonymous analytics
The beta automatically sends product-usage events to the app's analytics route. They help answer whether people return, where recipe requests fail, and whether features such as Meal Plan and print are useful.
- Events include the anonymous and session IDs, event name, time, site hostname/origin, and deployment environment.
- Depending on the action, an event may include success or failure, error category, duration, selected mode, request or Meal Plan correlation IDs, result and ingredient counts, scale factor, validation score, export type, and OpenAI model/token counts.
- Events may include a search term, recipe title, publisher/source name or domain, and recipe URL. The main submitted-request event records input length instead of the raw prompt, but other search and validation events currently can include the search term or URL.
- Durable analytics may include a one-way hash of the browser user agent. Application analytics do not intentionally store names, email addresses, raw IP addresses, full recipe bodies, ingredients, or instructions.
When durable analytics are enabled by the operator, sanitized events are appended to a PostgreSQL database. The current repository has no automatic analytics expiry job and promises no fixed retention period. It also has no automated public deletion endpoint.
Problem reports
The in-product report form does not require an account. If you send a report, the app stores a stable report ID, workflow and result type, safe failure category and error code, available request or Meal Plan correlation IDs, site environment and hostname, deployment identifier, coarse device class, and an optional short description. For imported recipes it can also store the public source URL without its query or fragment and the normalized publisher domain.
Reports are appended to the same PostgreSQL infrastructure used for durable analytics. The form limits and sanitizes the optional text and does not intentionally store API keys, authorization headers, cookies, database URLs, raw provider responses, internal stack traces, full prompts, full recipe bodies, ingredients, or instructions. The current repository has no automatic report-expiry job or public deletion endpoint.
Services needed to answer your request
Information is sent to outside services only as needed to run the feature you choose or to operate the hosted beta:
- Recipe search: hosted searches send your search terms to Brave Search. A local development setup may use DuckDuckGo instead.
- URL import and validation: the app requests the public URL from the recipe publisher's site. The publisher therefore receives the URL request and ordinary network request information.
- AI recipe generation: the recipe-generation prompt, including ingredients you enter in “Use Ingredients” mode, is sent to OpenAI with instructions and the expected recipe format.
- Hosting and analytics: the documented hosted beta uses Vercel and can use a PostgreSQL provider for durable analytics. Those providers handle data under their own terms and configured settings.
In short, recipe URLs, search terms, and recipe-generation prompts may be sent to the third-party provider required to perform the requested feature. Do not submit information you do not want processed that way.
Recipe content and source ownership
The server processes imported or generated recipes and returns them to your browser. The current application does not save full recipe cards, ingredients, or instructions in a server-side recipe database. Recipe titles, source details, and activity facts can still appear in analytics or logs as described on this page.
Recipe publishers and authors retain ownership of their third-party content. No Fluff Dinner preserves the source name and link, and the source attribution remains visible on imported recipe cards and Meal Plan exports. Importing a recipe does not transfer ownership to No Fluff Dinner.
Production logs and traffic protection
Optional beta request logs can contain input length, request intent, outcome, recipe title, source name, candidate count, and error type. Optional analytics logs can contain the analytics fields listed above, including a search term or source URL when an event supplies one. Temporary search diagnostics can contain queries, candidate titles, publisher domains/URLs, provider status, and error details.
To limit abuse, the server derives a temporary HMAC value from a platform-supplied IP address. It is kept in warm-instance memory for rate and concurrency checks and is not written to application analytics. Protection logs record the route, operation, broad reason, host, environment, and time without the raw IP, request body, browser IDs, or protection key. The hosting provider may separately keep infrastructure request metadata; this code does not define its retention period.
Contact and deletion requests
You can remove browser-held recipes, Meal Plan data, and identifiers with the in-app clear actions where available or by clearing this site's browser data. To ask about server-side analytics associated with your anonymous browser ID, use the contact page. The app does not promise a deletion timeline or an automated deletion result.
When the operator email is configured, it is the primary contact path for privacy and deletion requests as well as general beta feedback. If the contact page says it is not configured, no public contact destination is currently available. Do not send your browser ID, recipe URLs, prompts, or other sensitive information through unrelated channels.