Security

Your account, your sets of books, your documents and the records made from them are stored and served from the Amazon Web Services Canada (Central) region. The emails we send you go out from the same region. The one exception is reading a document, which is performed by Google outside Canada — section 12, and Privacy §6.

The site and the application are served over HTTPS only. Every page is sent with a strict-transport-security header covering this domain and its subdomains for two years, so a browser that has seen this site once refuses an unencrypted connection to it afterwards. Uploads and downloads of your documents travel over the same encrypted connections.

• Documents are stored with server-side encryption (AES-256) in a bucket with every form of public access blocked.
• Records are held in a database that is encrypted at rest and has deletion protection switched on, so the table cannot be dropped in a single click.
• Our own secrets — such as the key used to read documents — are held in AWS Secrets Manager, never in the site’s code and never in a configuration file.

• Only the account that owns them. Every record is stored under its account, and every read is filtered by the signed-in account before anything is returned.
• There is no sharing and no second login. An accountant keeps a client’s set of books on their own Practice plan; nobody is ever invited into your account.
• Our staff do not read your documents. We open an account only where you have asked us to for support, or where we are legally compelled to.
• Access is not hidden, it is refused. Permissions are enforced on the server for every request, never by leaving a control out of the interface.

There is no public address for a document: the storage bucket has no public read access and no public base URL exists. When you open a record, the server checks that your account owns it and then issues a one-off signed link that expires after sixty seconds.

The link also forces the file’s type from its stored name — JPEG, PNG or PDF — so a stored file can never be served back to a browser as a web page. A key that is not exactly the shape we store documents under is never signed at all.

Only JPEG, PNG and PDF, up to 10 MB. The type is checked in the browser, again when the upload is authorized, and once more from the file’s own leading bytes when it is read — so a file renamed to look like an image is caught. The link that authorizes an upload is valid for five minutes and writes to one place only: your own account’s area of the storage.

• Sign-in is handled by Amazon Cognito. Your password is kept only in a protected form that cannot be read back; it never reaches our own servers, and we can never see it.
• A password must be at least eight characters with an upper-case letter, a lower-case letter, a number and a special character. The rule the site shows is exactly the rule the server enforces.
• Your email address is verified with a code. We will never ask you for your password or for a verification code — anyone who does is not us.
• A second factor at sign-in is not offered today. When it is, it will be offered to you rather than imposed, and it will never be allowed to lock you out of records you are legally required to keep.

Every private route of the API sits behind an authorizer that validates your sign-in token before the request reaches any code of ours. The code then checks ownership again for the specific set of books or document you asked for, and answers 404 — not 403 — for anything belonging to another account, so the API never confirms that someone else’s record exists.

Isolation is tested rather than assumed, including the awkward case of one set of books whose identifier begins with another’s.

Each server function runs with its own role, holding only the permissions its own job needs: the function that authorizes an upload may write to the documents area and nothing else, the function that keeps your sets of books may touch only that one table, and each may write only to its own log. None can reach another product’s resources in our account. Our keys live in AWS Secrets Manager and are fetched at run time; none is in the site’s code, in a page, or in a configuration file.

• Strict-Transport-Security — browsers must use HTTPS for this domain.
• X-Frame-Options: DENY — no other site can frame this one, which stops click hijacking.
• X-Content-Type-Options: nosniff — a browser must take a file’s type as we declare it.
• Referrer-Policy: strict-origin-when-cross-origin — following a link away reveals the site, never the page you were on.
• Permissions-Policy — the camera is available to this site (you photograph receipts with it); the microphone and location are switched off entirely.

Records can be restored to any second in the last 35 days, and document storage keeps earlier versions of a file, so a bad overwrite or a wrong deletion can be undone. A record inside its six-year period is never destroyed silently — the Data Retention page sets out the whole life of a record, including what a removal really does.

When a document is added, the file is sent to Google’s Gemini service to be read, together with today’s date and the list of expense lines on that set of books’ form. Your name, email address, mobile number and account identifier are never sent. We use the paid service, under whose terms Google does not use what we send to improve its products. The model only proposes a result: our own code refuses any expense line that does not exist on that form, and flags an uncertain reading for your review.

Our server logs record what happened — which function ran, which document identifier, how long it took, and any error — together with an internal account identifier. They never hold the contents of a document, and error messages are redacted before they are written. Logs are kept for 30 days and then deleted automatically.

Every server function is exercised against a strict local harness before it is deployed — including the cases that matter here: a request with no sign-in, another account’s set of books, a document identifier that belongs to someone else, a signed link for a key that is not ours, and a response body checked field by field to be sure it carries nothing internal. The front end is audited the same way on every release.

If a security incident creates a real risk of significant harm to you, we will notify you and the Office of the Privacy Commissioner of Canada as soon as feasible, as PIPEDA requires, and tell you what happened and what to do about it. We keep a record of every breach of security safeguards for at least 24 months, whether or not it was reportable — Privacy §13.

If you believe you have found a security problem, please tell us before telling anyone else, at contact@cinintiriks.ca. Tell us what you found and how to reproduce it. We will acknowledge you, work with you on it, and we will not pursue anyone who reports a problem in good faith and does not access, change or keep another person’s data.

No system is perfectly secure, and anyone who tells you otherwise is selling something. We are a small company, we do not hold a SOC 2 report or an ISO certification, and we say so plainly rather than implying audits we have not had. What we commit to is narrower and more useful: holding only what the service needs, keeping the ways in as few as possible, checking every request on the server, and telling you promptly if a breach affects your information.

CININTIRIKS INC.
contact@cinintiriks.ca
1‑833‑980‑0707 (toll-free)
375 University Ave, Unit 102 Suite 3334
Toronto, ON M5G 2J5, Canada