Privacy

Personal Recipe Memory is a cookbook app for saving home recipes, sharing public dishes, and taking part in cooking conversations.

This page outlines the kinds of information the app is built to collect and display. It is not complete legal advice, and it does not describe a finished operator policy.

TODO. Add the operator identity, any registered business details, and the date this policy becomes effective. Do not publish those details until they are supplied.

Depending on how you use the app, Personal Recipe Memory may store:

• Account sign-in details such as email and a password managed by the authentication service.
• Profile fields you choose to provide, such as username, display name, bio, and cooking level.
• Recipe content you save, including titles, ingredients, steps, and related notes.
• Recipe photos you upload.
• Community activity such as comments, questions, likes, saves, and reports.
• Private cooking notes you attach after cooking a recipe.
• Notifications created by activity on your account or content.

TODO. Confirm whether any additional categories are collected (for example, support tickets or server logs) and list only those that actually exist.

The current app uses this information to:

• Create and keep your cookbook account.
• Show your recipes, profile, and cooking history to you.
• Show public recipes in Discover, Search, and public profiles.
• Support comments, questions, likes, saves, and notifications.
• Handle reports and moderation tools used by staff.
• Run security checks on sign-up, sign-in, password reset, and reporting forms.

TODO. Add any other purposes the operator actually uses, such as support or abuse investigation. Do not add marketing or analytics uses unless they exist.

TODO. Supply the legal bases that apply in the operator’s jurisdictions (for example, contract, consent, or legitimate interests). Do not invent GDPR, CCPA, or similar claims until counsel reviews them.

Recipes, photos, comments, questions, and cooking notes are content you add to the app. Public recipes and public community posts can be seen by other visitors. Private recipes and private cooking notes are meant for the account that created them.

TODO. Add the operator’s legal treatment of user content, including any license needed to host and display it. Do not invent ownership transfers.

Each recipe can be marked public or private. Public, published recipes may appear in Discover, Search, and on a cook’s public profile. Private recipes are not listed in those public surfaces.

Staff moderation can remove community-facing content from public views. That does not, by itself, describe how long copies are kept.

TODO. Clarify any extra rules for changing privacy, unpublishing, or residual copies in backups once those practices are defined.

An account uses an email address for sign-in and recovery. Profile usernames and display names can appear with public recipes and community posts.

TODO. Describe how email is used beyond sign-in (for example, confirmation or reset messages) and whether profile fields are optional or required.

Recipe photos are stored so the app can show covers and images on recipe pages. Access to private images is intended for people who are allowed to view that recipe.

TODO. Add storage-provider details, regions, and any signed-URL or access rules the operator wants stated publicly.

If you comment, ask a question, like, save, or report content, that activity is stored so the community features can work. Some of it is visible to other signed-in users on public recipes.

TODO. State whether likes, saves, or reports are visible to other users, and how notification records are handled.

The app uses session cookies so a signed-in visit can stay signed in across pages. Selected forms also use Cloudflare Turnstile, a challenge used to reduce automated abuse on sign-up, sign-in, password reset, and content reports.

This page does not describe advertising cookies, analytics pixels, or a cookie-consent banner. Those are not part of the current product UI.

TODO. Publish a complete cookie and similar-technology inventory once reviewed. Do not list tracking products that are not in the app.

The app relies on third-party infrastructure to run authentication, database storage, file storage, and bot-protection checks.

TODO. Name each processor, its role, and where a reader can find that provider’s own privacy terms. Do not add vendors that are not actually used.

TODO. Add retention periods for accounts, recipes, photos, community posts, reports, and backups. Do not invent time limits until they are decided.

Signed-in areas use authenticated sessions. Public pages show only content the app treats as public. This is a description of the current design, not a guarantee against every risk.

TODO. Add any security practices the operator is prepared to state, without over-promising.

TODO. Describe access, correction, export, and objection rights that actually apply, including the region and process. Do not copy a generic GDPR/CCPA clause until it is reviewed.

The current product lets you sign out and edit profile fields. It does not yet include a self-serve account deletion screen.

TODO. Explain how a person can request account and content deletion, what is removed, and what may remain for legal or safety reasons.

TODO. State the intended audience and any age limit. Do not claim the service is directed to children, or that it is not, until that decision is made.

TODO. Describe where accounts and files may be processed and any transfer safeguards. Do not invent countries or transfer mechanisms.

When this policy is completed, the operator will need a process for updating it and showing readers that it changed.

TODO. Add how changes will be announced and whether continued use counts as acceptance.

TODO. Provide a privacy contact method (and mailing address if required). Do not invent an email address, form, or company address here.