Privacy and data security

01 · What Rosty holds

What Rosty deliberately ignores from SurfGuard imports: date of birth, postal address, and any phone numbers in SurfGuard. The import code skips those columns on purpose — the app has no use for them, and data that Rosty doesn't hold it can't leak.

02 · Where your data lives

There are three separate copies of a club's data, stored in different places.

The live app

Every club gets its own deployment on Railway, a hosting provider similar to AWS. "Its own deployment" means its own running copy of the software, its own storage, and its own database file. There is no shared database and no shared logins. An issue with one club's data cannot reach another club's.

Railway does not offer Australian hosting — just the US, Europe and Singapore. All Rosty deployments are currently hosted in Singapore, the closest available Railway site. New clubs are pinned there automatically during setup.

Backups

Each club's database is backed up every night.

• Backups are stored in Amazon S3 in Sydney.
• Each club has its own storage bucket -- not a shared one with folders.
• Each club's app has its own access key to S3 for backups which provides access to that club's bucket only.
• A key stolen from one club cannot access another club's database.
• The app's key also cannot destroy backups. It can overwrite the current copy but every previous version survives.
• Old versions are kept for 400 days to span a full off-season. This lets us investigate an issue from the previous season if necessary.
• Public access is blocked.
• Once a month the app automatically checks backup viability by doing a test restore.

How your data is protected

In transit. Everything between a member's phone and the app travels over HTTPS. Session cookies are marked secure and HTTP-only, so they cannot cross a plain connection and cannot be read by scripts running in the page.

At rest. The live database sits on an encrypted disk provided by Railway. The nightly backups are encrypted by Amazon S3 with AES-256. Both use encryption managed by those providers rather than a key we hold ourselves — which is ordinary practice. This means encryption protects against somebody obtaining the storage, but not against the providers themselves.

Access — where most of the real protection is. Each club's app can reach only its own database. Each club's backup credential can reach only that club's own storage bucket and nothing else, and it deliberately cannot destroy backups. A credential stolen from one club's environment on Railway could not read another club's database. And there are no member passwords stored anywhere, because there are none to store.

03 · Who can see what

Rosty has four levels of access, and each is a deliberate step up in privileges.

These permissions are defined in one place in the code so a new feature can't inadvertently relax any safeguards.

Members and admins log in without passwords. Admins receive a code by email while patrollers get a personal link. There are no member passwords for us to store, lose, or have stolen.

If a link goes astray — forwarded to the wrong person, left on a shared device, lost with a phone — your club can reissue it. Admins can replace a single member's link. Owners can replace all member links at once at the start of the season or if links have leaked. Issuing new links signs all members out until the new links are sent. It's therefore left as a deliberate decision rather than something automatically done.

The "prefer not to patrol with" entries specifically

This deserves a direct answer, because it is the most socially sensitive thing in the database.

• Members enter these themselves, and see only their own.
• The rostering optimiser uses them to build the roster but they never appear on the finished roster. A patroller cannot see who named them. A committed member could probably glean insights about "prefer not to patrol with" preferences by looking at the roster, but that's true of manual rosters today.
• Club admins can see them. They can get to the information on the member's record in the admin screens, and preferences are included in the admin members spreadsheet export. That said, an admin has to go looking for them.
• The logic here is that this is exactly the kind of information a member would previously have shared with the patrol coordinator, so it would have been known by the coordinator anyway. But that's our logic and not a rule — if your club would rather admins can't see this information, please let us know.
• The audit log — records that a member updated their preferences and when, but not who they named. See section 4.

04 · What’s logged

Rosty keeps an audit log inside each club's own database that is visible to the club's owner. It records two things.

Changes: admin logins, support logins, admin access granted or revoked, member sign-in links reissued (one member's or the whole club's), roster clearing, structural changes to activities and patrol rules, and database resets.

Data leaving the club: whenever someone exports the member list, exports every member's sign-in link, downloads the whole database, or downloads a roster. These are all reasonable things for your club's owner to do — the point is not to prevent them but to be able to answer “who has a copy of our member list, and when did they take it?”

Changes to member preferences — including the “prefer not to patrol with” entries — are also recorded, deliberately as a count rather than as names. The log says that a member updated their preferences and when. It does not say who they named.

Each entry records who, what and when. Entries are kept for two seasons and then deleted. Routine roster edits are captured in the roster change summary.

05 · Sharing between clubs

By default, no data moves between clubs at all. Each deployment is self-contained and there is no shared database.

The one exception is the inter-club assistance feature, which a club opts into. When a club cannot fill a patrol, it can raise the shift with nearby clubs. The feature works in two steps, deliberately:

Nothing else crosses between clubs.

06 · SurfGuard

Rosty does not connect to SurfGuard. There is no API key, no live sync, and no automated access to SLSA systems. Information moves in one direction and only when your authorised admin generates a standard membership-and-awards report out of SurfGuard and uploads that file to Rosty.

SurfGuard imports can be run as often as you like throughout the season. Members are matched on their SurfGuard ID, so new imports will update existing members' contact details and qualifications. They also offer to add anyone new, for example after a cohort of new SRCs comes through.

07 · Leaving and deletion

Your club's data belongs to the club. There is no lock-in.

Getting data out of Rosty. Owners can download the entire database file, and export members, rosters and access details as spreadsheets, at any time, without asking us.

Deleting your data. If you decide to stop using Rosty, we will delete your club's deployment, its database, its nightly backups, its storage bucket and its end-of-season archives, and confirm to you in writing when everything is done. We would obviously rather you stayed because the app is useful, but clubs are free to leave at any time and for any reason.

Three honest caveats:

• Deleting a whole club is a manual process we perform, not a button you press. It is deliberate and quick, but it depends on us doing it.
• Backups are versioned for 400 days, so "delete everything" means we explicitly destroy those versions rather than waiting for them to age out. We will do that on request and confirm it.
• The end-of-season archive is deliberately hard to delete, so it requires some manual steps on our part. Yearly backups are locked for seven years against the app itself and against every credential a club's deployment holds, so that nothing which compromises a running service can destroy your history. Removing it takes a specific override that only we can use. This approach was chosen over a stronger lock so that we could delete your data if asked.

08 · What we’re working on

This document covers things we've done to ensure security of your data. But a privacy document listing only strengths is not much use to a board making a decision. These are the gaps we are aware of, in roughly the order we intend to close them.