Trust centre
Privacy
A proposed privacy approach for personal property preferences, explainable matching and invite-only buying groups.
Our proposed position
Property Ranker is intended to be private by default and designed to the Privacy Act 1988 and Australian Privacy Principles from launch. Budget, location intent, personal rules and household interactions will be treated as high-trust information.
The public website, authenticated application and administration tools are planned as separate surfaces with controls appropriate to each. Anonymous or pseudonymous exploration should remain available where practical before identification is needed.
Information the service is designed to handle
- Account information: identity and authentication references, account status, sessions and privacy settings.
- Buyer profiles: search areas, budget ranges, property needs, travel preferences, explicit personal rules, draft and published profile versions, and visibility choices.
- Optional context: reasons or notes a person chooses to add. A matching rule should work without a sensitive explanation.
- Buying-group activity: memberships, invitations, shared properties, reactions, comments, inspection tasks and decision history.
- Service and safety records: category-level product events, consent records, privacy requests, support access, security events and audit records.
- Property evidence: licensed listing and property observations, sources, timestamps, confidence, calculation methods and user-submitted corrections.
How information is intended to be used
Information will be collected only when necessary and with a contextual notice at the relevant step. The stated core purposes are to:
- save and apply a buyer's chosen rules;
- calculate and explain property-fit results;
- support invited household collaboration;
- deliver requested service messages and permitted alerts;
- protect accounts, investigate issues and maintain an audit trail; and
- provide access, correction, export and deletion controls.
Marketing, analytics and future personalisation require choices separate from profile processing, sharing and service notifications. Referral partnerships must be optional, consented and clearly disclosed, and must never alter an organic fit score.
Personal preferences and sensitive context
The service should ask for a neutral property rule, never infer a culture or sensitive trait. It will not request or infer ethnicity, religion or cultural identity from a name, language, postcode, browsing or partner behaviour.
If a person enters a potentially sensitive reason in free text, the intended design is to explain its purpose and audience, retain it only with express informed consent, encrypt it and restrict access. Raw preference values must not be sent to advertising, analytics or crash-reporting vendors.
Visibility and buying groups
Each preference is planned to be Private, visible to selected partners or shared with the group. Sharing a property must not reveal a cultural, financial, accessibility or other personal reason by default; other members may instead see that a home does not meet one partner's private requirement.
- Each person uses an independent account and privacy choices.
- Invitations are scoped, expire and can be revoked.
- Removing a member should revoke current access immediately.
- Browsing history, profile reasons and notifications are not exposed without an explicit choice.
- One person's reaction does not silently change another person's private profile.
Providers, analytics and overseas disclosure
The planned service may depend on licensed property data, canonical address, maps, routing, rail, cloud, identity, notification and monitoring providers. Display, storage, sharing, caching and deletion must follow each provider's authorised terms.
Before launch, the final policy must identify relevant overseas vendors and countries, document due diligence and explain how cross-border disclosure is contractually managed. Advertising trackers and unnecessary analytics are to remain off wizard, private-profile and group pages. Product analytics should record category-level events without raw sensitive preference values.
Planned security baseline
The blueprint calls for strong authentication, staff multi-factor authentication, least-privilege access, household isolation, object-level authorisation, encryption in transit and at rest, extra protection for sensitive notes, secure session revocation and audited staff access.
Sensitive values should not appear in logs. Authentication, consent, sharing, export, deletion and administration events should have append-only audit records. Independent penetration testing, encrypted tested backups and an incident and breach-assessment playbook are release requirements.
Proposed retention schedule
These periods are planning proposals and must be validated in a privacy impact assessment and provider contracts.
| Data | Proposed treatment |
|---|---|
| Unfinished profile draft | Delete after 90 days of inactivity, with advance notice where appropriate. |
| Active profile and group activity | Retain while the service is active and the purpose remains necessary. |
| Invite token | Delete the secret on use or expiry; retain minimal abuse and audit metadata for up to 90 days. |
| Closed account | Allow a 30-day recovery window, then purge production data and age encrypted backups out within 90 days. |
| Shared properties and reactions | Delete with the collection or account; revoke visibility immediately when membership is removed. |
| Application and security logs | Retain for 12 months; justified high-risk access or sharing metadata may be kept for up to 24 months. |
| Provider property data | Refresh or delete according to licence, expiry and withdrawal requirements. |
| De-identified analytics | Retain only after assessing re-identification risk and separating it from production identity. |
Access and control
The production service is intended to provide self-service access, export, correction and account deletion; a way to dispute property-derived observations; granular notification settings; consent withdrawal; immediate sharing revocation; and a documented privacy-request and complaint process.
An accountable privacy owner and contact route will be named in the final policy before release. Eligible data breaches will be assessed and notified in line with the Notifiable Data Breaches scheme.