Security

Separation is structural, not a filter

Every company on Kaza gets its own database. Not a shared table with a company column and a query that remembers to filter on it, a separate database, reached through a separate binding.

The distinction matters because the common way multi-tenant systems leak is a query somebody forgot to scope. Here there is no query that could reach another company’s rows even if it were written wrong, because those rows are not in the same place.

Documents

Applicant uploads (pay stubs, pieces of ID) are stored privately and are not reachable by a public link. They are served only to someone signed in whose role permits it.

Accounts and access

• Passwords are stored as salted hashes. Nobody at Kaza can read or recover one.
• Access is by role. A contractor sent to a repair sees the address, a first name and a phone number, never income, an application, or any other tenancy. A building’s owner sees numbers for their own buildings and no personal details at all.
• Sign-in attempts and other sensitive endpoints are rate limited per account, so a stolen-password list cannot be tried at speed.

A record that cannot be quietly rewritten

Consequential actions, who decided an application, who remitted a deposit, when a notice was served: are written to an append-only activity log. It cannot be edited after the fact, deliberately: it protects the applicant, and it protects you at a tribunal.

A signed lease carries a hash of the exact text that was signed. Alter a term afterwards and the hash no longer matches and the signatures are void, which is what “tamper-evident” has to mean to be worth anything.

Backups, and proof they work

Databases are backed up, and the backup tool can be run in a mode that restores a dump and verifies it rather than assuming it would have worked. An untested backup is a rumour; this one has been exercised.

Nothing an applicant types reaches a third party

The application form is served by us, submitted to us, and stored by us. There is no third-party form service in the path and no analytics or advertising script on the page. The browser is instructed to refuse connections to anywhere but this site, so an applicant’s income and identification cannot cross into an ad network even by accident.

That is a deliberate contrast with how these forms are usually built. Embedding a form service on a page that also carries an advertising pixel sends applicant details to that advertiser, in Canada a privacy problem rather than a design preference.

Email

Kaza will not send from a domain it cannot prove belongs to you. Until your own domain is verified, mail goes out from ours with your name on it and your address for replies. Every message carries a one-click unsubscribe, and an address that unsubscribes or complains is suppressed across the whole platform rather than for one company.

Payments

Kaza never holds or moves your residents’ money. Rent goes from the renter to your own account and we are not a party to it. Our own subscription fee is a separate flow through a payment processor, and no card details ever reach this application. There is no card form here to enter them into.

The browser side

Kaza sets a strict content security policy: the pages load code, fonts and images from Kaza itself and nowhere else. There is no third-party script on any page: no analytics, no advertising tag, no chat widget, so there is nothing embedded that could read a form as it is filled in.

Personal information is never put in a web address, because addresses end up in browser history, in logs and in the referrer sent to the next site.

What we do not claim

Kaza is a small operation, and it is more useful to you to know the edges than to read a page of badges. We hold no SOC 2 report and no ISO certification. There is no 24/7 security operations centre. What there is: a deliberately small third-party surface (named individually on the sub-processors page), structural separation between companies, and an owner who answers info@3d3d.ca.

If you find a security problem, send it to that address. We would much rather hear it from you than from a customer.