Husora Privacy Policy
1. Who this policy is for and what it covers
This policy covers the Husora application for Android, published under the package name dev.husora.app (the "app").
Husora is not a cloud service with an app attached. It is a local-first home appliance: the software that stores and reasons about your household's information runs on hardware inside your home, which you own and control. The Android app is a thin client. It is a screen and a set of notifications for an appliance on your own network.
The practical consequence, and the reason this policy is shaped the way it is: for the household data this product exists to handle, the developer of Husora is not a party to it. There is no account with the developer, no developer-operated server that your household's information passes through, and no copy of it anywhere the developer can reach. This is not a promise about restraint. It is a description of where the software puts things.
One precision, because "no account" is easy to overstate: signing in with a passkey does register a credential, and that credential is recorded on your household's appliance. It is an account on your own hardware, not with the developer. Your household's appliance necessarily knows who lives in your household — that is what it is for — but the developer holds no directory of Husora users, because there is no developer-operated system in which one could exist.
This policy describes what the app does. It does not describe what your household's appliance does with data once the appliance has it — the appliance is under your household's control, not the developer's, and Section 9 explains what that means for your rights.
2. Summary
- Nothing you enter or choose reaches the developer. There is no analytics SDK, no advertising SDK, and no crash-reporting SDK in the app, and no developer-operated server for it to report to.
- Information does, however, leave your phone. It travels over an encrypted connection to your household's own appliance on your own network, and nowhere else. This distinction matters for reading Google Play's Data safety label as well as this policy: Play defines "collect" as transmitting data off a user's device, whoever receives it, so sending your answer to your own appliance counts — this is not a "collects no data" app in Play's sense, even though the developer receives nothing. Section 4 says exactly what leaves and where it goes.
- Some information is stored on your phone, in this app's private storage, so that an answer you gave is not lost when your phone is out of range of the appliance.
- The app requests exactly two Android permissions: notifications, and network access. (A third entry appears in the installed app's permission list —
dev.husora.app.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION. It is not an Android system permission and grants no access to anything: it is a signature-level permission the app defines for itself, added automatically by an Android support library so that the app's own components cannot be reached by other apps. It is named here because it is visible on the installed package, not because it does anything.) - Automatic cloud backup of this app's data is switched off in the app itself, so that your household's questions and answers do not ride a backup service the appliance never sees.
- Developer-controlled infrastructure is contacted in exactly one narrow case. It is caused by how Android passkeys work rather than by anything the app chooses to send, and it is described honestly in Section 6.
3. What the app stores on your phone
All of the following is stored in this app's private storage on your device, which other apps cannot read. None of it is transmitted to the developer.
Answers you have not yet been able to deliver. When you answer a household question (for example, a dinner poll) while the appliance is unreachable — you are away from home, the appliance is off — the app keeps your answer on the phone until it can be delivered. Only the most recent answer per question is kept; changing your mind replaces the earlier answer rather than queuing a second one.
Answers the appliance refused, and the reason given. Kept so that the app can tell you truthfully that an answer did not go through. Without this record, a refused answer and a delivered answer would look identical, and you would be told your answer was in when it was not.
A record of the answers you have given, so the app can show you what it has recorded and whether each one reached the appliance. This record contains the question's identifier, the name of the household member the answer is attributed to, how the answer was given, and the answer itself.
Household questions the appliance has sent you, kept so that a later reminder about the same question can be matched to the question it reminds you about.
How to reach your appliance: its network address and port, the name its certificate is verified against, your household's certificate authority certificate, and your appliance's published verification key. These are settings and public keys, not secrets.
Your device's pairing credential — the identifier and access token that let this phone speak to your appliance as a known device. This is stored encrypted (see Section 8).
Depending on what your household's appliance sends you, the content above can include household members' display names, the labels of the food options you are offered, and the names of merchants. Your household's stored allergies and dietary requirements are not among them. None of the stores listed above has a field for an allergen or a dietary requirement, and the appliance does not send its preference records down to the phone — they stay on the appliance. Allergy information can come to rest on this phone in exactly one way: you typed it into an answer yourself, as Section 4 describes, in which case it is held in the record of your answers and in an undelivered answer until that answer is delivered.
One related case, stated here so that it is not discovered later. A proposal your appliance sends you can name an allergen on screen, in a sentence explaining why a dish was ruled out for someone. It is not written to any of the stores listed above, and it is never displayed in a notification (Section 7) — the notification shows the merchant's name and a fixed sentence.
It does, however, live somewhere for longer than the screen, and that is worth being exact about rather than rounding down. The proposal is carried to its screen inside the notification itself, as data attached to the tap. So from the moment the notification is posted until you tap or dismiss it, the proposal — including any such sentence — is held by Android's notification system, not by this app's storage. That is ordinary Android behaviour for any notification that opens onto content, and it stays on your phone; but "it lasts as long as the screen does" would be wrong, because it is there before you have opened anything.
All of this information is your household's and is held on your device. None of it is transmitted to the developer. Some of it does go to your household's appliance — that is what an undelivered answer is waiting to do — and Section 4 sets out exactly which parts and by what route. Nothing on the list above goes anywhere other than your own appliance.
4. What leaves your device, and where it goes
The app makes network connections to exactly one destination: your household's appliance.
What travels up that connection, field by field, is a short list:
- The identifier this phone was paired as, on every call. The appliance uses it to work out whose answer this is.
- Your answer to a household question: which question it answers, whether you answered from the notification or inside the app, and then either the option you tapped or the text you typed — never both.
- During a sign-in: a request to begin, and the signed response your authenticator produced.
- A request asking the appliance who this device is signed in as.
Coming back down the same connection are the questions, proposals and approval requests your appliance wants to show you.
Two things about that list deserve to be said rather than left for you to work out:
- A typed answer is not constrained, and this app asks about food. When a question offers a keyboard, what you type goes up exactly as you wrote it. "Nothing with peanuts", "gluten-free please" is a normal and useful answer to "what's for dinner?", and it is health information. No field in this app is labelled for allergies and the app has no screen for entering preferences — the household's stored allergies and dietary requirements live on the appliance and are never sent up from the phone — but a free-text answer can carry health information because you chose to put it there, and it then goes to your appliance the same way any other answer does.
- What the phone does not send. It sends no name as a claim of who you are — who an answer belongs to is decided by the appliance from the paired device, not from anything the phone asserts. It sends no allergen or dietary field, no financial information, and executes no payment. Enrolling a new authenticator would send a label you choose for it, which could be a name; no screen in the released app starts an enrolment, so nothing sends one today.
Three properties of that connection are worth stating precisely:
- It is encrypted with TLS.
- It trusts only your household's own certificate authority. The public certificate authorities that your browser trusts are deliberately not loaded. A certificate that would satisfy any browser satisfies nothing here, because your appliance is not a public website — and a connection that a network in between could intercept would be carrying your household's private life.
- Notifications arrive down that same connection, held open to the appliance, rather than through a push service operated by a platform vendor. This is a deliberate design choice with a privacy consequence: your household's questions do not pass through anyone else's servers on the way to your phone.
The app has no other network destination. There is no developer-operated server for it to talk to, and it does not report to one.
How this reads against Google Play's Data safety label. Google defines collection as transmitting data from an app off a user's device. That definition turns on the device boundary, not on who receives the data — so everything listed above counts as collected, even though the only recipient is hardware you own and the developer receives nothing. That is why this policy does not say "no data collected", and why the app's Data safety declaration should not say it either. What the label cannot express, and what this section is for, is the difference between data leaving your phone for your own appliance and data leaving your phone for somebody's business.
5. What the app does not do
Each of the following has been verified against the app's source code and its complete dependency list, not merely intended:
- No advertising. The app contains no advertising SDK and displays no ads.
- No analytics. There is no third-party analytics SDK, no usage telemetry, and no event reporting of any kind.
- No crash reporting. There is no crash-reporting or performance-monitoring SDK. The app does not send crash reports to the developer.
- No advertising identifier. The app does not read or transmit the Android advertising ID, and does not build or use any profile for advertising. (This one is established by absence rather than by a line of code: the locked list of every library that reaches a released build contains no advertising-identifier library, nothing in the app calls for one, and the app declares no
AD_IDpermission.) - No location. The app does not request or access device location, contacts, calendar, camera, microphone, photos, files, or the device's phone or SMS functions. It holds no permission that would let it.
- No sale of personal information, and no sharing of personal information with data brokers or advertisers. There is no data to sell: none reaches the developer.
- No cloud backup of this app's data. Automatic backup is switched off in the app's own manifest, deliberately. A household's polls and replies riding a vendor's backup service would be exactly the kind of leak this product exists to avoid.
6. The one thing that reaches the developer, and what it is
Honesty requires naming this, because the alternative — a blanket claim that nothing whatsoever touches developer infrastructure — would be false.
Husora signs you in with passkeys (WebAuthn). Every Husora passkey belongs to the relying party id.husora.dev. For Android to allow this app to use a passkey scoped to that domain, the platform's credential machinery — not code written for this app — fetches a file from https://id.husora.dev/.well-known/assetlinks.json and checks that the domain names this app and its signing certificate. This is how Android prevents an imposter app from claiming to be Husora and being handed your credentials. It cannot be done on your local network; the fetch goes over the public internet.
To be exact about who makes it: that machinery is Google Play services, which is partly a system component on your phone and partly a set of Google libraries built into this app (see Section 11). The app does not construct the request, does not choose when it happens, and never sees its result except as "the ceremony was allowed" or "it was refused" — but it would be a distinction without a difference to claim the request has nothing to do with the app, so it is disclosed here as though it were the app's own.
That domain is served by infrastructure the developer controls, hosted on Cloudflare. The ordinary request metadata of any web request — the source IP address and the time — is therefore visible to developer-controlled infrastructure. This is inherent in serving the file at all; it is not a logging choice that could be switched off while still serving it.
What that does and does not reveal:
- It reveals a network address and a timestamp, and the inference that a device is setting up or using a Husora passkey.
- It reveals nothing about who you are, which household you belong to, what your appliance holds, or what any household member has said, preferred, or eaten. None of that information is in the request, because the request is a plain fetch of one public file that is identical for every user in the world.
- The file being fetched is public by design. It is a statement about which app is allowed to use the domain's passkeys. It contains no user data.
- It is not combined with anything else, because there is nothing else to combine it with — no account, no profile, no other record of you exists on developer infrastructure.
Request metadata is retained only for the period Cloudflare retains it for the account, and is not used for advertising, profiling, or any purpose other than operating and troubleshooting the service.
Related, and different: the passkey itself is created and held by whichever credential provider you use on your device — for example Google Password Manager, or a third-party password manager you have installed. Where that provider stores your passkey, and whether it synchronises it across your devices, is governed by that provider's privacy policy, not this one. The app never sees your passkey's private key; neither does your appliance. What the app receives from the provider is a signed assertion, which it passes to your appliance to verify.
7. Notifications
The app requests the Android notification permission at first launch. Notifications are how a household question reaches you in time to matter, so the app is substantially less useful without them; if you decline, the app remains usable for answering questions inside the app itself.
Three facts about notification content that you should know:
- Notifications can contain household content — the name of a merchant, the labels of the options you can choose, in a confirmation notification the answer you gave, and, on an approval request, the spending amount your household authorised. Whether that content appears on your locked screen is governed by your device's own notification settings, which the app does not override. If you would rather household content did not appear on a locked screen, change that setting in Android's notification settings for this app.
- No notification names an allergen, or the reason a dish was ruled out for somebody. The screens can (Section 3); the notifications that lead to those screens are built from the merchant's name plus either a fixed sentence or the authorised amount, and nothing assembles a safety finding into one. This is a property of what the app constructs, not a setting you have to go and find.
- The app switches off Android's automatically-generated smart-reply suggestions on every notification it posts. This is a privacy and integrity measure rather than a cosmetic one: those suggestions are generated by reading the notification's text, and a tap on one would record an answer against a household question that no person actually chose.
8. Encryption and security
In transit. All communication between the app and your appliance is protected by TLS, pinned to your household's own certificate authority as described in Section 4.
At rest on your phone. Your device's pairing credential — the identifier and access token that authorise this phone to your appliance — is encrypted with AES-GCM using a key generated inside the Android Keystore that cannot be extracted from the device. The encrypted value, not the credential, is what is written to storage.
Two deliberate limits on that, stated plainly rather than glossed:
- The Keystore key is not configured to require your screen lock each time it is used. This is a considered trade-off: requiring an unlock would make it impossible to answer a household question from a notification on a locked phone, which is the app's central purpose. The protections that remain are the non-extractable Keystore key and Android's per-app storage boundary. The credential protected this way is a household-scoped access token that your appliance can revoke — not a master key to anything.
- The appliance's address, your household's certificate authority certificate, and your appliance's published verification key are stored unencrypted in the app's private storage. This is intentional: they are public values and trust anchors, there is nothing in them for an attacker to learn, and an attacker who can already rewrite this app's private storage has defeated the device by a shorter route.
Logs. The app writes diagnostic entries to the Android system log. Every line this app itself writes goes through a single place, and what it may contain is deliberately constrained to the kind of event and to identifiers the system itself generated (such as a question's identifier). Household members' names, food items, answers, reasons, merchants, and the text of error messages are excluded by design, and a test fails the build if any other logging call appears in the app's own code. The reason for the strictness is that the Android system log leaves the household — it is readable over a debugging connection, captured in bug reports, and surfaced by manufacturer support tools.
The libraries the app is built on write their own log lines, which this project does not author. Release builds are processed by a code shrinker configured to strip debug- and verbose-level logging — including the string-building behind it, which is where content would hide — and the built application is checked to confirm that stripping actually took effect. Higher-severity lines from those libraries are not stripped; they are not household content, but no claim is made here about their exact contents, because none has been measured.
Whatever is written, the system log stays on the phone. Nothing in this app transmits it anywhere.
9. Retention, deletion, and your rights
On your phone. Retention differs by store, and it is worth saying exactly rather than in general terms, because two of the four are kept indefinitely:
- A queued answer is removed as soon as the appliance accepts it, and removed as soon as the appliance refuses it.
- A refusal is cleared the moment you answer that question again — you are having another go, and the old complaint is no longer about anything.
- Household questions the appliance has sent you are held so a later reminder can be matched to them, and are not deleted afterwards. There is no expiry and no clean-up pass.
- The record of the answers you have given is appended to and never trimmed. Nothing in the app removes a line from it or shortens it.
So the honest summary is: the two stores that exist to make a send correct clean up after themselves; the two that exist to make the display correct grow for as long as the app is installed. Neither of them is transmitted anywhere, both are inside this app's private storage, and both are erased by uninstalling or by clearing storage. A time limit on them would be a reasonable thing for this app to grow and it does not have one today.
You can delete everything the app holds on your device in either of two ways:
- Uninstall the app. Android deletes this app's private storage, including everything listed in Section 3.
- Clear storage for Husora in Android's app settings, which has the same effect without removing the app.
The app contains a "Forget appliance" action, which erases the pairing credential and the Keystore key that protects it in a single step. Two things about it must be said plainly rather than implied:
- It is not reachable in the version on Google Play. The action sits on the screen that configures an appliance connection, and that screen is available only in developer builds. In released version 0.1.0 there is no in-app button that deletes anything. Uninstalling, or clearing storage, is the deletion route that actually works today, and both delete everything in Section 3 including the pairing credential. Making the forget action reachable in a released build is a change the app needs; until it lands, this policy will not claim an in-app deletion path that a released build does not have.
- Even where it is reachable, it does not delete household data. It removes this phone's authority to speak to your appliance. It does not by itself delete the queued answers, recorded answers, refusals, or held questions described in Section 3 — for that, clear storage or uninstall.
Requesting deletion. Because the developer holds no copy of anything, there is nothing for the developer to delete on request. If you want to be sure a device's authority has been revoked, that is done on the appliance by your household's administrator. Enquiries may be sent to the address in Section 12.
On your appliance. Household data on the appliance belongs to your household, and deletion, correction, export and access are performed there, by your household's administrator, using the appliance's own interfaces. The developer cannot access, retrieve, correct, export, or delete data held on your appliance, and cannot do so on your behalf, because the developer has no access to it and no route by which to gain any. Where you have rights of access, correction, deletion, or portability under the law that applies to you, they are exercised against the party that actually holds the data — which for household data is your household, not the developer.
Passkey deletion. A passkey is deleted in two independent places: from your credential provider (your password manager or Google Password Manager), and from your appliance, which holds the corresponding public credential record. Removing one does not remove the other.
10. Children, and households that contain them
Husora's target audience on Google Play is 13 and over. The app is not directed to children under 13, and the developer does not knowingly receive personal information about children under 13 — indeed, the developer does not receive personal information about anyone, as Sections 4 to 6 describe. Read that as it is written: information does leave the phone (Section 4), and it goes to the household's own appliance. What does not happen is any of it reaching the developer.
That statement, however, would be incomplete on its own, and this section exists because the honest answer is more nuanced.
A household contains children, and Husora is built for households. An appliance may hold information about a child who lives there — their name, their food preferences, their dietary requirements and allergies — because that is what a household system for coordinating meals and schedules has to know in order to be useful, and in the case of allergies, in order to be safe. A child may also be a participant: a question can be sent to a phone a child holds, and the app can render a response surface designed for a child.
The important distinctions:
- Children are participants in a household, not the app's install audience. The app is listed for 13+ and is not part of Google Play's Designed for Families programme.
- Information about a child in a household is entered and controlled by the household, on hardware the household owns, under the authority of the household's adult administrator. It goes to the appliance and stops there.
- None of it reaches the developer. There is no server on which a developer could hold a child's name, preferences, or allergies, and no path by which such information could travel to one. The single developer-visible signal described in Section 6 is a network address requesting a public file, and it is the same request for every user regardless of age.
- Two different protections apply to what a child is shown, and only one of them is live today. The type that carries a household question refuses, for everybody, the combinations that are wrong for anyone — a child-friendly question that nevertheless opens a keyboard, or a question nobody can answer. That refusal is unconditional and is in force. Separately, the app contains a check that compares the response surface against who this device is signed in as and narrows an over-permissive one. That second check does not engage on any build you can install. Establishing who is holding the phone needs a signed round trip to the appliance that the notification path cannot make, so the app's answer is always "cannot verify", and the honest behaviour in that state is to show what arrived rather than to black out the question. The design principle is still that what a person may see is decided by which view was constructed for them, not by hiding fields in a display layer; the enforcement of it on the phone is written and tested but not yet reachable. It is named here because a policy that claimed the protection was operating would be claiming something the software does not do.
- Parents and guardians who want to review, correct, or delete information about a child do so on the appliance, through the household administrator. Since the developer holds none of it, a request to the developer cannot be fulfilled by the developer — it can only be redirected to the household.
If you believe a child under 13 has installed and used this app, or that information about a child has reached the developer contrary to this policy, contact us at the address in Section 12. We will investigate, and if anything about a child is found on developer-controlled infrastructure it will be deleted.
That commitment is deliberately scoped to what the developer can actually perform, because a broader one would be undeliverable. Information held on your household's appliance cannot be deleted by the developer — Section 9 explains why there is no route to it — so a request about appliance-held data can only be redirected to your household's administrator, who can act on it. Saying otherwise here would be a promise the software makes impossible to keep.
11. Third parties
- Google Play distributes the app and, independently of the app, collects information about installations and Play interactions under Google's own privacy policy. The app does not add to that.
- Your credential provider (Google Password Manager or a password manager you have chosen) stores your passkey and is governed by its own privacy policy, as described in Section 6.
- Cloudflare serves the passkey domain-verification file described in Section 6 and processes the associated request logs.
- Google Play services libraries are built into the app, and this should be named rather than left to be discovered. Using a passkey on Android requires Android's Credential Manager, and the component that makes a credential provider available to it ships as a set of Google Play services libraries inside the app. These are what carry out the domain check described in Section 6 — so the one thing in this product that reaches developer-controlled infrastructure is performed by third-party code inside the app, not only by the operating system around it. Two of these libraries arrive as a side effect of that dependency and are never called by this app: one for reading one-time codes out of SMS (the app holds no SMS permission, so it could not be used) and one for signing in with a Google account (the app offers no such sign-in). The app contains no advertising, analytics, attribution, crash-reporting or telemetry library of any kind.
There is no other third-party service in the app.
What the app sends over its own network connection goes to one place: your household's appliance, which is your hardware and not an organisation. That is the whole of what this app transmits, and Section 4 lists it field by field.
One adjacent path is worth naming rather than folding into that sentence, because it is not the app's network connection and the app is not the party that decides where it goes. When you sign in, Android hands the ceremony to the credential provider you chose, and a synced provider — Google Password Manager among them — stores your passkey under your own account with that provider and may replicate it to your other devices. The app does not select the provider, does not see your passkey's private key, and sends the provider nothing about your household; but "the provider holds a credential of yours" is a real relationship with a third party, and it is described in Section 6 and governed by that provider's own privacy policy. It is named here so that the paragraph above is read as what it is — a statement about this app's own transmissions — rather than as a claim that nothing anywhere in a sign-in involves anyone else.
12. Contact
Husora is developed and published by Andrew Wahrenberger, the developer of record for dev.husora.app on Google Play.
Privacy enquiries: privacy@husora.dev
No postal address is published here. Google Play requires a public physical address of developers who sell paid apps or offer in-app purchases; Husora does neither, and this policy does not publish a home address in place of an obligation that has not arisen. If that changes — if the app is ever monetised, or if a jurisdiction that applies to a user requires a controller address — an address will be published here in the same revision that makes it necessary, and the effective date will change with it.
We will respond to privacy enquiries about the app. For requests concerning data held on your household's appliance, please see Section 9 — those are exercised on the appliance, and we have no ability to act on them.
13. Changes to this policy
If this policy changes, the revised version will be published at https://husora.dev/privacy, and the effective date at the top of the page will change with it. Material changes — in particular, any change to what leaves your device or to who receives it — will be described on the page itself, so that "what changed" does not have to be reconstructed by comparing two versions.
The app's behaviour and this policy are intended to stay in step. If you find a statement here that the software does not match, please tell us; we treat that as a defect in the software or the document, not as a matter of interpretation.
14. This version of the app
This section describes the specific published version and will be updated as the app changes.
As of the effective date above, the released version of the app is 0.1.0. In this version, the screen that configures the connection to an appliance is available only in developer builds, which means an installed release build of version 0.1.0 has no appliance address and no pairing credential, holds no household data, and makes no network connection to any appliance. That last part is worth stating as the code states it, because "no connection" could otherwise mean "a connection that fails": the one function that builds the connection looks for the stored credential first and returns "nothing to connect to" before any socket is opened, so on a release build no connection is attempted rather than attempted and refused. Everything in Sections 3, 4 and 7 describes what the app does once it is paired with an appliance; in this version, pairing is not yet reachable from a build installed from Google Play.
The same is true of the passkey path in Section 6. Signing in begins with a request to your appliance, before your credential provider is ever contacted; with no appliance configured, a release build of version 0.1.0 stops at "not paired" and never starts a passkey ceremony. The domain-verification fetch described in Section 6 happens as part of a ceremony, so this version of the app never causes one. Stated that precisely on purpose: what the app does is checkable in its own source, and it starts no ceremony here; when Android or a credential provider fetches that file on its own schedule is not this app's behaviour to promise about, and no claim about it is made. Section 6 is stated in full because it describes the mechanism honestly and will describe this app's behaviour the moment pairing lands — not because it describes the version you have installed today.
And the deletion action in Section 9 is likewise unreachable here, for the same reason: it lives on the developer-only connection screen. In released version 0.1.0 the deletion routes that work are Android's own — uninstall, or clear storage.