How RecipeRadar Handles Privacy and Personal Data

Updated

RecipeRadar states that the service "should not collect or store any personally-identifiable information," and that all data transmitted by the app — whether to the service or between instances of the app — "should provide mutual content-integrity guarantees." The code is released under the AGPLv3, so you can inspect and modify it yourself. These are stated design principles from the project's own About page, not third-party audit results, so treat them as the project's commitments rather than independently verified facts.

What the project commits to

From RecipeRadar's About page, the privacy-relevant principles are:

  • No collection or storage of personally-identifiable information. This is written as a leading principle for the service.
  • Content-integrity guarantees on transmitted data. The stated aim is that data sent to the service, or between app instances, carries mutual integrity guarantees.
  • Free and open source under AGPLv3. The code for both the app and the service is meant to be freely available for inspection and modification.
  • No proprietary software or development tools. The project states it should not rely on proprietary software or tooling.
  • Distraction-free and privacy-respecting by design. The service is described as aiming to be distraction-free and privacy-respecting.

RecipeRadar also describes itself as a Community Interest Company registered in the United Kingdom, with goals "legally aligned with community benefit rather than to maximize shareholder profit." That structure is relevant context for why the privacy stance is framed the way it is, but it is not itself a privacy guarantee.

How to verify these claims yourself

Because the project is open source, the practical way to check the privacy behavior is to read the code rather than rely on the description:

  1. Find the source repository. The About page states the code is available for inspection and modification under AGPLv3; use the project's own links to locate it.
  2. Look at what the client sends. Search the codebase for network calls and the payloads they build, and check whether any field could identify a user.
  3. Look at what the server stores. Check the service-side code for persistence layers, logging, and any account or session handling.
  4. Check the license file. Confirm the AGPLv3 terms so you know your rights to modify and redistribute.

Expected result: you either find no personally-identifiable fields being transmitted or stored, consistent with the stated principle, or you find something that contradicts it — in which case the code, not the About page, is the more reliable source.

What is not stated

The page evidence does not describe:

  • A cookie policy, analytics setup, or third-party trackers.
  • Data retention periods or deletion procedures.
  • Account requirements or what happens to data if you create one.
  • Any independent privacy audit or certification.

If any of these matter for your decision, they are open questions you would need to resolve by inspecting the code or contacting the project, not by assuming a default.

Who this fits

If your main concern is whether a recipe and meal-planning tool will build a profile of you, RecipeRadar's stated design — no personally-identifiable information, open code, no proprietary dependencies — is aimed directly at that concern, and the AGPLv3 license gives you a way to check rather than trust. If you need documented retention policies, formal compliance certifications, or a signed data-processing agreement, the available material does not show those, so this would not be the right fit on that basis alone.

The honest summary: the privacy posture is a set of explicit, checkable commitments backed by open code, and the appropriate level of trust is whatever you can confirm by reading that code.