Privacy
Privacy starts with an honest account of what exists today.
This project page separates the public presentation website from future Huddle product, research and family-data processing.
Two contexts
The public website and the future product need separate promises.
Current scope
The public `.com` site explains the Huddle project and its prototype direction. It should describe only the data flows that are actually present on the deployed website, such as a verified contact route, technical delivery or an approved research-interest form if and when those functions exist.
Future accounts, family profiles, child context, recommendations, marketplace activity and institutional learning require separate purpose-specific notices before they are processed. A product concept is not evidence that those data operations are active today.
This project page separates the public presentation website from future Huddle product, research and family-data processing.
Explain the current privacy boundary, identify the facts that still require verification and prevent future product intentions from being presented as current processing practices.
Privacy by design
Collect less. Explain the purpose. Keep the family in control.
Data minimisation
Until a verified notice and secure purpose-specific route are published, visitors should not send child-identifying information, health details, safeguarding reports, credentials, case files or other sensitive material through general contact fields.
Huddle's intended design principles include purpose limitation, adult control, separation of household and institutional visibility, restricted access and limited retention. These remain design commitments requiring legal, privacy, safeguarding and technical validation.
- 01◎Purpose before collection
- 02◇Minimum necessary data
- 03✓Separate consent and notices
- 04↺Correction, deletion and retention
Before production
What remains to be verified
A complete privacy notice needs named facts, not placeholders or assumptions.
Before production publication, the responsible owner must verify the site publisher, controller, contact route, purposes, data categories, lawful bases, recipients and processors, international transfers, retention, security measures and procedures for exercising rights.
No registered company identity, data-protection officer, processor list, legal basis, retention period, production processing or regulatory compliance is confirmed by this draft. Final wording requires owner and specialist legal and privacy review against the deployed system.
Purpose and provenance
Every data item needs a source, purpose, owner and end date.
Future product notices should distinguish family-entered information, provider facts, public sources, technical records and generated inferences. The purpose and lawful basis may differ for account operation, research, support, safety, commerce and aggregate institutional learning; one consent must not silently authorise every use.
Families should be able to understand access, correction, deletion, portability, objection and withdrawal routes where they apply. Requests need an authenticated, safe process that does not expose another household member or erase records that must be retained for a lawful reason without explanation.
Sensitive context
Huddle should not infer more about a family than the task requires.
Household context may reveal disability, finances, migration, religion, health, relationships or a child’s routine even when those fields are not requested directly. Product design should avoid combining ordinary signals into a sensitive profile and should prohibit family, parent, child and social scoring.
Location should use the least precise form that solves the task. Discovery may need an area, travel estimate or chosen starting point; it does not automatically justify background tracking, a location history or institutional access to where a family goes.
Assessment before processing
High-risk processing needs an assessment before code or consent makes it appear acceptable.
A DPIA or equivalent specialist review may be required for child-related context, systematic recommendation, sensitive inference, monitoring, location, large-scale research or institutional analytics. The review should map necessity, proportionality, threats, affected people, mitigations, residual risk and the accountable approval decision.
Security design should cover identity, role-based access, encryption, logging, backups, deletion, vendor control, testing, breach handling and recovery. These are requirements for future operation; this page does not certify that a production family-data system currently exists or complies with a named regime.
The next responsible step