Broomi Privacy Policy

Last updated: 9 October 2026

Version 2026-10-09

The short version

Broomi is a chores app for a family or a shared house. You make a household, add chores, mark them done, and a housemate confirms the work, which mints points.

Four things in this policy are worth knowing before you read the rest.

1. There is no privacy boundary inside a household. Every member can read every other member's points history, and every member can fetch any photograph in the household. Every member can also see the invite code, and anybody who is handed that code can join and read all of it.
2. Photographs are short lived, but what is derived from them is not. A proof photograph is usually gone within minutes of being confirmed, and in most cases within seven days. The fingerprints the server computes from it are kept for as long as the household exists.
3. Deleting your account is immediate and permanent, and it does not remove everything. Your name comes off your history. The history itself stays in the household.
4. The two rights this policy describes as self service are not in the app yet. Downloading your data and deleting your account exist on Broomi's server and no Broomi app asks for either. Today both run through support@broomi.app.

Each of these is explained in full below.

Who runs Broomi

Broomi is run by Mohammed Abdi, an individual, in the United States. There is no company behind it.

You can reach us at support@broomi.app. That is the address to use for every question in this policy, including a request for your data or for your account to be deleted.

What this policy covers, and which Broomi it describes

Broomi has not launched. Today only a tester environment exists, hosted on Amazon Web Services in the US East (Northern Virginia) region, us-east-1. Every number in this policy is the number that tester environment actually runs on, not a number from a configuration that has never been applied.

Because it is a tester environment, the retention numbers below describe what the code does with a record and not a promise that the record will survive. The database may be reset or rebuilt before launch, which would take everything in it. The Terms say the same thing.

This policy describes the Broomi mobile app and the server behind it.

There are also two older prototype builds, one that runs in a web browser and one built for a phone. They behave differently, and they are described separately under "Artificial intelligence" below, because the difference matters.

What Broomi collects, and why

Your account

Broomi does not collect your date of birth, and holds no age for anybody: not for an account holder, not for a seat on a board, and none derived from anything. A seat used to carry a birth year that could be typed in and that nothing could ever read back; the column was dropped and the year with it. See "Children".

Broomi has no sign in with Apple, no sign in with Google and no two factor authentication. An email address and a password is the only way in. There is also no screen in the app for changing your password or your email address; both exist only as routes on the server.

Your sessions and your IP address

Your IP address is kept in three places, in the clear, and nothing deletes any of them for as long as your account exists: on every acceptance of the Terms or of this policy, on your age declaration, and on every analytics or marketing decision you ever make. All three go, and go completely, when the account itself is deleted, because every one of them hangs off the account record. A fourth place, the rate limiting key, holds only a hash and is cleared daily.

One thing about session records that a reader would not guess, and it is true: every renewal writes a new record rather than changing the old one, copying forward the device label your app sent, and nothing ever deletes them while the account stands. There is no clean up job. A phone that renews a few times a day therefore produces roughly a thousand records a year, each holding a hashed token, that device label and its dates, and they go only when the account itself is deleted.

Broomi's own request log does not record IP addresses: it records the method, the path without the query string, the status, the size, the duration and a trace identifier. The load balancer in front of it is deliberately configured with no access log at all.

Your household

A column also exists for when you last opened Home. Nothing in Broomi ever writes it, so it is always empty, including in your data export.

Three of these records can never be edited or deleted while the household stands: the points ledger, the confirmations and the record of who moved a chore onto whom. An undo posts a reversing entry rather than removing anything. The one exception is that they go when the household itself goes.

One record is not like the others. The row for a single chore run is overwritten rather than versioned. Skipping a run clears who marked it, when, on whose behalf and every photo field, and nothing is left behind to say a mark ever happened.

Deleting a chore or a room does not remove it. It is archived, and its runs and its points history stay.

Nothing in Broomi edits a household setting. Whether a household is managed, whether automatic approval is on, and whether photographs are asked for are all settled when the household is created and cannot be changed afterwards. There is no settings route on the server and no settings screen in the app.

A copy on your own phone

The app keeps a copy of your household's data on your device: the household, its members, rooms, chores, points, ledger entries, rewards, redemptions and the current event. So your household's data, including every member's points history, sits on every member's phone as well as on our server, and we cannot reach it there.

The app clears that copy whenever it ends the session, for whatever reason: a sign out you asked for, a refused renewal, a request answered with 401, a session revoked from another device, or a launch that finds no session. The photograph links held in memory go at the same time. The app has to be running and has to notice, though. A phone that is never opened again, or that stays offline, keeps its copy of the household.

What Broomi does not collect

So that nothing here is read as more than it is, these are not collected and not happening:

• No push notifications and no push tokens. The Broomi app asks for no notification permission and carries no push library. The server sends no push message of any kind, and no notification of any kind: no reminder, no email when work is stamped or sent back, and no digest.
• No analytics, no crash reporting and no telemetry. There is no analytics or crash reporting software anywhere in the server or in the app. Nothing records which screens you look at.
• No marketing email. None exists.
• Nothing is sent by the server to any artificial intelligence provider. See "Artificial intelligence".
• Photographs are not copied to a second region.
• No SMS and no telephone number.
• No payment or receipt data is collected today. Nothing in Broomi has ever recorded a purchase.
• No photo library access. The app asks for your camera and deliberately does not ask for your photo library or your microphone.

Some of these have tables waiting for them in the database, and an export of your data can show those sections as empty. Nothing fills them.

Who can see what

There is no privacy boundary inside a household. This is the single most important thing in this policy, and it is deliberate, not an oversight.

Every member of your household can see, for every other member:

• the points ledger, newest first, up to the two thousand most recent entries,
• points earned all time and for the week, month and year, the balance, held points and spendable points, and the current streak in days,
• every chore run: who marked it, when, on whose behalf, and whether a photo the house asked for was not given,
• every confirmation: who confirmed, for whom, when, and whether it was confirmed automatically,
• any photograph in the household, if they have its identifier. The check is only that the photograph belongs to your household. It is not a check on who took it, or on whose run it was attached to. A child's seat is not excluded,
• whether a submitted photograph resembles one that was already sent back, or one submitted recently. This is a comparison of image fingerprints that the server works out for every photograph, shown to the person confirming as a hint,
• which seats are flagged as children,
• the household invite code, which is the credential for joining the whole household.

The invite code and the list above are one fact, not two. Any member can read the code, and anybody that member hands it to can join the household immediately, with no request and no approval, and then read everything in that list: every member's points history, any photograph in the household, and which seats are marked as children. In a household that has not turned managed mode on they can also delete things and remove people. The code can be rotated, which breaks every copy of it, and in a household that is not managed any member can rotate it.

Whoever created the household holds the admin role, in every household. Managed mode is what makes that role bite. In a household that has not turned managed mode on, every member can create, edit and delete chores and rooms, edit the reward shelf, remove members and rotate the invite code, so the role buys little. Three things stay with the admin wherever you are: adding a child seat, reading or withdrawing a child's consent, and changing somebody's role. A managed household that loses its last admin gives the ordinary rights back to every member, and any member with a login can then take the admin seat.

Your seat name also leaves the household in somebody else's data download. Where a housemate downloads their own data, your seat name appears in it wherever you took part in an event of theirs, including in a household they have since left.

What a housemate cannot see is your account itself. Your email address, whether you confirmed it, and your account dates are not reachable by anybody else in the household, including an admin. The member list carries only a name, a role, a colour, the child flag and whether the seat has a login.

Nothing about one household's chores, runs or points crosses into another household.

None of these rules applies to the person who runs Broomi. They keep housemates and strangers out. The operator holds the database and the storage, so nothing in Broomi prevents the operator from reading what is stored or opening a photograph. Where this policy says no person at Broomi looks at something as a matter of course, that is a statement about conduct and not a technical limit.

Photographs

A proof photograph is the most sensitive thing Broomi holds. It is a picture of the inside of somebody's home. This section is longer than the others for that reason.

What is stripped, and where

When you upload a photograph, your phone sends it to a holding area. The server then reads it, checks it really is the kind of image it claims to be, decodes the pixels, and copies those pixels into a completely fresh image with an empty metadata record. That fresh image is what is stored.

The effect is that no EXIF, GPS, XMP, ICC, IPTC, PNG text block or comment from your phone can survive. The orientation tag is applied to the pixels and then thrown away, and the colour profile is converted to standard sRGB and then thrown away, so appearance is kept without carrying a tag through. The image is also scaled down to a long edge of 2048 pixels and re-encoded.

Two honest qualifications:

• The stripping happens on the server, not on your phone. For the time between your phone uploading and the server finishing, the original file, with its GPS coordinates if it had any, genuinely exists in the holding area.
• This is a guarantee made by the application, not by the storage. Nothing in the storage layer or the database can verify that a stored file was in fact stripped.

How long the original survives

The original in the holding area is deleted as soon as the photograph's database record is safely written. It is also queued for deletion a second time, at upload plus fifteen minutes, so that no still valid upload signature can put it back. As a last backstop, everything in the holding area expires after two days. If the upload is never completed, the original is taken after one day.

How a photograph is served

A stored photograph is never public. The storage area is configured to block all public access, every object is written with an encryption header the storage will not accept the upload without, every object is marked not to be cached, and access is granted only as a signed link that works for five minutes.

Those are the settings Broomi's code and its infrastructure specify. Broomi has not yet measured them against a live storage area, and the code says so in as many words, so this is a statement about configuration and not about a verified result.

That signed link is a bearer credential. It is not tied to the person who asked for it. For its five minute life, anybody holding the link can fetch the photograph, including anybody it was forwarded to.

Within a household there is no further restriction at all. Any member with a photograph's identifier can exchange it for a signed link.

Inside the storage area, one household's files are separated from another's by the name of the file alone. The storage does not know what a household is, and there is no storage level rule restricting access by household path. What keeps them apart is the database rules above it, which are enforced, and the fact that only Broomi's server can mint a signed link.

Limits

A proof photograph must be a JPEG or a PNG and at most 5 MB. A how-to video must be an MP4, at most 24 MB and at most 45 seconds. A household may upload 50 photographs per day, counted against the household's own local midnight rather than a server clock, and a how-to video costs 5 of those 50. The daily allowance belongs to the household, not to a person, so one housemate can use everybody else's.

How long a photograph is kept

Every number in that table depends on one scheduled job running. That clean up job is the only thing that deletes a stored photograph. There is no storage level expiry behind it: the optional hard expiry on the evidence tag is switched off, and file versioning is off so no rule ages an object out. The job itself is created switched off and runs only where an environment has turned it on. If it stops, or keeps failing, a photograph simply stays until it runs again. Two checks run nightly to report a photograph that has outlived its date and a file queued for deletion that has not gone; reporting is all they do, and nothing acts on either report. The queue has no clock of its own either, so a file whose deletion keeps failing stays queued, with its error, and is retried on every pass.

When the bytes are deleted, they are deleted in two steps so that a crash can never leave a file behind without a record of it, or a record without a file. The file is forgotten only once the deletion has actually succeeded. There is no recoverable earlier version kept, because file versioning is deliberately switched off.

What survives the photograph

For every photograph, the server computes and stores two content hashes and eight perceptual fingerprints. One of the two hashes is of the original file exactly as your phone sent it, before the camera and location data were stripped off; the other is of the cleaned image. A perceptual fingerprint is a small number derived from how the picture looks, one for each way the image could be flipped or turned.

Those fingerprints are compared automatically against photographs sent earlier in the same household, and the result is shown to the housemate confirming the chore as a hint that a picture looks reused. Nothing is refused automatically on that basis. Nothing anywhere in Broomi tries to recognise what the picture shows: there is no content moderation, no image recognition and no moderation service.

The hashes and fingerprints are copied onto the confirmation record and are deliberately kept after the photograph itself is deleted. The confirmation record can never be edited or deleted while the household stands, so they are kept for as long as the household exists. The reason given in the code is to stop one file earning a second photo bonus, and to warn a housemate that a picture looks like one that was already sent back.

They cannot be turned back into the picture. They are still a permanent derived record of a photograph of the inside of a home, and they outlive it. They are also left out of your data export, so nothing in the product ever shows you that they exist.

Who handles a photograph

Only Amazon Web Services. Your phone uploads the bytes straight to Amazon S3, and the server reads, writes and deletes them there. There is no content delivery network in front of the photograph storage: the signed link your app follows goes to the storage itself. The one content delivery network Broomi uses carries this policy, the Terms and the three small files that present them, and is described under "Third parties".

No outside service processes the image. Checking, stripping, re-encoding, hashing and fingerprinting all happen inside Broomi's own server process. There is no image moderation service, no computer vision service, no image hosting service and no error reporting service anywhere in this path.

Photographs are not used for advertising, and nothing in Broomi sends them to train a model. One exception exists and it is not the Broomi app or its server: see "Artificial intelligence".

Email

Broomi sends exactly six messages. Every one of them is a direct consequence of something done on an account. There is no newsletter, no digest, no product announcement and no mail sent on a schedule or to a list. Broomi sends no notification of any kind about household activity.

Three further facts about mail, all true:

• Mail is sent from no-reply@broomi.app and no reply address is set, yet three of the six messages tell you to reply. A reply will reach nobody. Write to support@broomi.app instead.
• Sending is best effort and a message can be lost. A message is handed to a small pool of background workers after the request finishes. If the server restarts at the wrong moment, a message in flight is lost and no record is kept that it was ever requested. We cannot promise that a verification, reset or security warning email will arrive.
• A failed send writes the subject and the recipient's address into the operational log. The log removes link tokens. It does not remove email addresses.

Mail is rate limited: 20 link requests an hour from one connection, 10 an hour to one mailbox for a verification, reset or email change letter, and 5 an hour per account for any mailed link. The download notice can arrive at most three times a day, because the download itself is capped at three. One exception is deliberate: a reset letter to an address that account has already confirmed is exempt from the per mailbox ceiling, so the one route back into an account cannot be throttled away by traffic aimed at that inbox.

Mail is delivered through Amazon Simple Email Service. No tracking configuration is enabled, so Broomi does not record whether you opened a message or clicked a link in it.

Children

This is the section to read most carefully, and the section where Broomi's code does least.

What a child is in Broomi

A child in Broomi is a seat on a household board, not an account. An adult adds the seat and ticks "Kid". A child has no email address, no password and no way to sign in, and a child seat cannot be given a login later.

Adding a child seat is an admin's act in every household, managed or not. Only an admin can add one, and a household with no admin at all cannot add one until somebody is made an admin. A child seat can never be made an admin.

Because a child cannot sign in, a child never performs an action in Broomi themselves. Every tap is made from an adult's session, and the record says which adult tapped.

The points, though, are the child's. Broomi credits a chore to the person it was for and not to the finger that tapped, so an adult ticking a child's chore pays the child. A child seat therefore builds up its own points ledger, balance, held and spendable points and streak, can be named as the doer on a confirmation, can be the assignee of a chore, and can be the target of a reward priced against that child's own balance. A photograph taken from an adult's phone can be attached to a child's chore.

What is held about a child

The child's seat itself holds a name of 1 to 40 characters, a colourway, a role, the child flag, and the dates the seat was created, joined and was removed. That is the whole of it. A seat once carried a birth year, a background colour and an avatar as well; nothing ever read any of the three back, and all three were dropped.

That is the seat, not everything Broomi holds about the child. On top of it, the household holds everything credited to that seat: the child's full points ledger, balance, held and spendable points, their streak, every chore run assigned to them or credited to them, every confirmation and send back that names them, their redemptions and point holds, their programme enrolments, badges and cosmetics. All of it is readable by every member of the household, and none of it has a retention period.

Broomi holds no age and no birthday for a child. It does not ask for one and has nowhere to put one.

Every member of the household, not only an admin, can see which seats are flagged as children.

Parental consent, described honestly

Under the United States Children's Online Privacy Protection Act, a service that is directed to children, or that knowingly collects personal information from a child under 13, must obtain verifiable parental consent before that information is collected. Here is exactly what Broomi does, with nothing smoothed over.

• A child's seat cannot be committed without a consent record. This is not an option an admin may take: Broomi refuses to write a child seat at all unless a consent method is given with it. The seat and the consent are written in one transaction and commit together, or neither does. A refused consent rolls the seat back with it. There is no committed moment at which a child's seat exists in Broomi with nothing standing for it.
• The consent is not obtained before the seat is created. Inside that transaction the seat is written first and the consent is written after it, and the consent is stamped later than the seat by the width of one statement. The project measured it at twelve milliseconds. Whether a consent recorded in the same transaction as the seat satisfies "before any collection" is not something Broomi's code decides.
• Four consent methods exist in the record: an adult's attestation, a card check, a signed form and a video call. In practice only the first is possible, because Broomi performs no card check, collects no signed form and makes no video call. An adult's attestation is a tick box.
• No shipping Broomi app can add a member of any kind, or record, read or withdraw a child's consent at all. The mobile app has no screen and no request for either. Its only member call is a removal. So no child seat can be created from any released Broomi app today, and the only thing that has ever exercised these routes is Broomi's own test suite.
• Where a method other than the tick box is claimed, the only evidence stored is a free text string of at most 200 characters. Nothing uploads, fetches, checks or validates whatever that string refers to.
• The gate depends on a flag the adding adult chooses. Adding a member and leaving the "Kid" flag unticked writes a live seat with no consent record and raises no alarm. Nothing anywhere asks or infers whether the person being added is under 13, and there is no other signal on a seat that could be compared against the flag. The only "are you 13 or over" question in Broomi is the tick box an adult sees when creating their own account, and that is a self declaration that nothing verifies.
• Recording a consent through the add a member route passes no rate limit, although every other write into the same record is capped at twenty a day per account.
• The consent record is the most legally sensitive record Broomi holds and it keeps no IP address, while acceptances of the Terms and the age declaration both keep one.

For completeness, the parts that are built properly: only an admin may add a child seat or record, read or withdraw a child's consent, in every household shape; the consenting adult is always read from the signed in session and can never be named in a request, so a consent can never be attributed to somebody who did not give it; the record is append only, so a withdrawal strikes rows rather than erasing them; a child can never be made an admin, and five separate mechanisms enforce that; the consent table cannot be read or written by the part of the system that serves the app at all; and two standing database checks report any live child seat with no consent record, and any consent record that could not have come from the proper route.

What a withdrawal does, and does not do

Withdrawing consent records the withdrawal and changes nothing else. It does not remove the child's seat, and it does not delete a single point, confirmation, photograph or badge. Nothing in the product reads a withdrawal afterwards.

What is missing

• No retention period for a child's data is set anywhere. There is no sweep, no expiry and no scheduled deletion keyed to a child's seat, to a consent, or to anything credited to a child.
• No way to rename a seat, a child's or anybody else's, once it is created. The member routes are add, remove, consent and role only, so an adult who mistypes a child's name cannot correct it.
• No parent facing export of a child's data. No part of Broomi hands an adult the child's chores, points, confirmations or history. An adult's own export carries the consents that adult gave, with the child's name, the method and the dates, but deliberately not the evidence string.
• No way for a child to exercise any right themselves, because a child has no account and no session.
• Removing a child first tries to delete the seat outright, and falls back to keeping it with the name replaced by "Former housemate", when the household's history still points at it. Where the seat is deleted outright, the consent records are deleted with it, so the evidence that consent was ever given is destroyed by the same act that removes the child.

How long things are kept

These are the numbers the running code actually implements. They describe what the code does with a record, not a promise that the record will survive a pre launch reset of the tester environment.

Your rights

Write to support@broomi.app for anything in this section.

Two of these rights are built on Broomi's server: downloading your data and deleting your account. Neither of them is in the Broomi app today. No released client calls the download route, the deletion route or the route that previews a deletion. The only way to use any of them at present is to write to support@broomi.app and ask us. Everything below describes what the server does when we run it for you.

Download your data

One route exists: a single download, authenticated, which hands you a JSON file in the response itself. It is limited to three downloads per account in any 24 hours. There is no emailed link option, deliberately: a link to all of a person's data sitting in a mailbox is a credential.

The file covers your account, your acceptances, your age declaration, your current consents and the full history of them, your sign ins, your email links, and then every household you hold a seat in or ever held, each with twenty one sections covering the household, your seat, your balance, chores, runs, steps, assignments, the ledger, redemptions, redemptions you decided, rewards, confirmations, programme enrolments, badges, cosmetics, photographs, parental consents you gave, subscriptions you bought and the how-to cards you wrote.

The file contains IP addresses: the address every acceptance, every consent decision and your age declaration was made from. The download shows you more than any Broomi screen does: there is no session list in the app, and nothing in the product displays a stored IP address back to you.

Photographs appear as details only, never as images: an identifier, what it was for, its type, size, dimensions and dates.

The file never contains your password, any token, a push token, photograph bytes, a storage location, a content hash, an image fingerprint, a payment receipt, or the evidence string from a parental consent.

Two sections of the file read tables that nothing in Broomi currently fills, so they will be empty: subscriptions, and the steps ticked on a chore.

A housemate's seat name appears in your file wherever they took part in something of yours, and your seat name appears in theirs on the same rule.

Downloading sends you the notice email listed above. A download that takes longer than fifteen seconds is cancelled, and the attempt still counts against your three.

Delete your account

Deleting requires your current password, not just being signed in. Password attempts are limited to ten an hour.

Before anything happens, the server can produce a summary of what deletion will do: how many households you are leaving, how many will be deleted and their names, how many seats will have the name taken off them, and how many subscriptions will be cancelled. No Broomi app shows that summary to you. Ask for it at support@broomi.app before you ask for a deletion, and we will send it to you and wait for your confirmation.

Deletion is immediate and irreversible. There is no grace period, no recycle bin and no window in which you can change your mind.

Other rights

To ask for a correction, to object, or to exercise any right your local law gives you, write to support@broomi.app. There is no correction route of any kind inside the product: a seat's name cannot be changed once it is created, and the only screens that change anything about you are the ones that create your account.

What deletion does, and what it does not remove

What it removes

Deleting your account hard deletes the account record. There is no copy kept and no marker left behind. With it go every sign in session, which is how you are signed out everywhere, every email link record, every acceptance of the Terms and of this policy, your whole consent history, your age declaration, and the record of any invite code you used.

Every IP address Broomi held about you goes at that moment, because all three places that hold one hang off the account record: the acceptances, the age declaration and the consent decisions.

Every household in which nobody else can still sign in is deleted outright, and with it that household's rooms, chores, runs, points ledger, confirmations, rewards, redemptions, enrolments, photograph records and invite code. A child seat with no login does not keep a household alive. The photograph files are queued for deletion in the same step and are then actually deleted from storage by the scheduled job described under "Photographs".

What it does not remove

This is the part most policies gloss over.

In any household where somebody else can still sign in, your seat is kept, not deleted. The name on it becomes the literal words "Former housemate" and a leave date is set. This reaches every seat you hold or ever held, including a household you left years ago, which until that moment still carried your real name.

Everything pointing at that seat stays: your points ledger, your confirmations, the chore runs you marked, confirmed, sent back or were assigned, the record of chores you moved, your redemptions, the rewards you created, your programme enrolments, badges, cosmetics, the parental consents you gave, and the how-to cards you wrote. The identity comes off. The activity does not.

Three more things do not go:

• Photographs you uploaded stay in a surviving household, on their own clock. Deletion does not touch them, and a how-to image or video can therefore be kept indefinitely, as described above.
• The fingerprints and hashes of photographs stay on confirmation records.
• Database backups still hold the deleted rows until they expire on their own clock, which in the running environment is seven days. Nothing reaches into a backup to remove one account.

Nothing about a payment is kept, because nothing in Broomi has ever recorded one. If a paid tier is ever built, a receipt would be a record of a real payment and this section would have to say what happens to it.

Deletion also has one side effect worth knowing: if erasing the last admin of a managed household would leave it with no admin, the longest standing remaining adult with a login is made admin automatically, without being asked.

Third parties

Amazon Web Services is the only third party that the Broomi app and the server behind it send your information to. There is no advertising network, no analytics vendor, no crash reporting service, no payment processor and no push notification provider.

There is one exception, and it is not the app or the server. Two older prototype builds send household content, and in one place a photograph of the inside of a home, straight from the device to an artificial intelligence provider, under an API key the person pastes in themselves. See "Artificial intelligence" below. If you have ever used one of those builds with a key pasted in, your information was carried by somebody other than Amazon.

A content delivery network carries five files, and nothing else. The page you are reading is a file in a private storage area, delivered by Amazon CloudFront. The five are this policy, the Terms, a short page that links to those two, a page shown for an address that does not exist, and one stylesheet. There is no sixth file behind it. Opening any of them is an ordinary web request, so CloudFront receives your IP address and the string your browser identifies itself with, the way every website you open does. The delivery is deliberately set up with no access log, so Broomi holds no record of who read either document and could not produce one if it were asked; what Amazon keeps about serving a request is governed by Amazon's own terms and not by this policy. The pages set no cookie, carry no script, and load nothing from anywhere else: the stylesheet comes from this same address and is the only thing any of them fetches. Nothing you do in the Broomi app passes through CloudFront, and no photograph, no record and no credential sits behind it.

Everything the server does runs in the US East (Northern Virginia) region, us-east-1. The Amazon services that hold or carry personal information are:

• Amazon RDS for PostgreSQL, which holds every record described in this policy.
• Amazon S3, which holds the photograph and video files.
• Amazon Simple Email Service, which delivers the six messages listed above. What reaches it is the recipient's address, your display name where the message carries it, and, in the deletion notice, the names of the households being deleted.
• Amazon ECS on Fargate and Amazon ECR, which run the server and the scheduled clean up jobs.
• Amazon CloudWatch Logs and Metrics, which hold the operational logs described under "Security".
• Amazon SNS, which sends alarm notices to the operator, not to users.
• Amazon CloudFront, which delivers the five files described above, and which therefore receives the IP address of anybody who opens one of them.
• AWS Secrets Manager, AWS KMS, Amazon EventBridge Scheduler, an Application Load Balancer with AWS Certificate Manager, Amazon VPC, AWS Backup, AWS Budgets and AWS IAM, which carry credentials, scheduling, routing, backups and billing rather than user records.

Broomi's server makes outbound network calls to exactly two outside destinations, both of them Amazon: the email service and the file storage.

Broomi does not sell your information, and does not share it for advertising.

Artificial intelligence

Broomi's server sends nothing to any artificial intelligence provider. There is no AI route in the server, no AI software in its dependencies, and the infrastructure actively forbids giving the server an AI provider credential: a standing test fails if anyone adds one. The Broomi mobile app contains no reference to an AI provider at all.

There is one real exception, and it is not the app this policy describes. Two earlier prototype builds of Broomi call an artificial intelligence provider directly from the device, using an API key the person pastes in themselves, which is held in plain text in that build's own storage. One of those builds runs in a web browser. The other is a phone build, made with React Native, so the honest statement is not that only a browser does this. Each makes three such calls, and in one of the three it sends a photograph of the inside of the home. The request goes from that device to that provider, under that person's own key, on that provider's terms, and billed to whoever pasted the key. The key is stored beside the identifier of the member who supplied it. The Broomi server is not involved and never sees any of it.

The browser build also asks the browser for permission to show notifications, and the banner it shows carries the chore title, the room name and the chore's point value. Nothing about that leaves the device. The phone prototype's notification code does nothing at all.

Security

What follows is what Broomi actually does. Nothing is claimed beyond it.

• Your password is stored only as an Argon2id hash. Nothing reversible is kept anywhere, the database refuses to store a hash of any other kind, and the part of the system that serves the app is not permitted to read the hash column at all. The comparison happens inside the database.
• The password rule is at least 8 characters including at least one digit, up to 128 characters. There is no requirement for a capital letter or a symbol.
• One household's records cannot be read from another household's session. The household is taken only from your signed token and never from anything in the request, membership is checked on every request, and the database itself enforces a rule on every household table that confines a read to the one household in the session. A request with no valid token therefore reads nothing at all, rather than everything.
• The tables holding session records, renewal tokens and email links cannot be read by the part of the system that serves the app. It can only call a small set of functions that each take a hash and return the narrowest possible answer. A flaw in a request handler cannot read them.
• Points cannot be written by a modified app. The part of the system that serves the app can only read the ledger, and the ledger and the confirmations refuse every edit and every delete.
• A failed sign in gives one message for every cause, and the server deliberately equalises the timing too, so the sign in route cannot be used to test whether an address has an account. Sign up is different, and says plainly that an address is already taken, which is a deliberate trade for usability.
• Sign in, password reset and link requests are rate limited. There is no lock on the account itself after repeated failures.
• Every photograph file is written with an encryption header, marked not to be cached, and kept out of public reach by a public access block the infrastructure configures on the storage area. Those are the configured settings; Broomi has not yet measured them against the live storage area.
• Operational logs are kept 30 days. The load balancer's own access log is switched off, the server's request log deliberately records the path without the query string and no referring page, and a filter replaces the value of any token in a link with a marker, all so that a live verification or reset link cannot end up in a log. That filter covers Broomi's own output and cannot reach a log written by anything in front of it.
• Database backups are kept 7 days.
• Two checks run nightly to notice when a photograph has outlived what this policy promises, and when a file queued for deletion has not gone. They report and nothing more. No code acts on either report, so somebody has to read it.

Six weaknesses belong here, because leaving them out would make this section a better advertisement than a true statement.

• Signing out does not take effect instantly. A sign in token is valid for 10 minutes and is checked by its signature alone, with no lookup. After signing out, after "sign out everywhere", or after a password change, an already issued token keeps working for up to 10 minutes. There is also no screen in the app for signing out everywhere.
• Staying signed in does not need your password for up to a year. Renewal tokens last 60 days and rotate, and only the one year cap on a chain forces the password again.
• A signed photograph link works for anybody who has it, for five minutes.
• A stolen session can take everything, and cannot delete anything. The data download needs only a valid sign in token, three times a day, and hands over the whole account including the IP addresses and browser strings of every past sign in. Deleting the account, by contrast, needs your current password. The asymmetry is deliberate, and it is worth knowing when you decide how carefully to guard a signed in device.
• One secret signs every session. The sign in token is signed with the application's own general secret, the same secret the rest of the server uses, so a single compromise of that one secret would mint a valid session for every account.
• Inside the photograph storage, one household's files are separated from another's by the file name alone. There is no storage level rule enforcing it. See "Photographs".

There is no two factor authentication.

Analytics, tracking and marketing

Broomi runs no analytics, no crash reporting and no advertising or tracking technology. There is none in the server and none in the app. Nothing records which screens you look at, and nothing builds a profile of you.

Broomi does record a decision from you on three subjects, if it ever asks: analytics, crash reporting and marketing email. Every decision is kept, with the time and the IP address it was made from, and no decision is treated as consent. Nothing in Broomi currently reads any of those decisions, because none of the three things exists, and neither app shows the question, so there is nowhere to make a decision in the first place. If you want one recorded, write to support@broomi.app.

Broomi sends no marketing email of any kind.

Household invitations are not emailed either. A person joins by typing the household's invite code into the app.

Changes to this policy

When this policy changes, the new version is published with a new version line and a new date. A change that affects what you agreed to will ask you to accept the new version the next time you sign in. A correction that changes nothing you agreed to will not interrupt you.

Your acceptance is recorded with the version, the time and the IP address it came from. Please note that, as described above, that record is destroyed if you delete your account.

Contact

For any question about this policy, for a copy of your data, for a correction, or to ask about deletion, write to support@broomi.app. Today that mailbox is the only route to the data download and to account deletion, because neither has a screen in the app.

Please do not reply to an automated Broomi email. Those are sent from an address nobody reads.