Security Architecture

01Shape of the system

Ownership Society Academy is a server-rendered web application backed by a managed Postgres database. Course content — slides, plates, syllabus — is public and needs no account. Everything belonging to a student sits behind authentication.

02Authentication

Accounts are handled by a managed authentication service. Sign in with Google, or with an email address and password. Passwords are never stored by this application: they are hashed and held by the auth service, and the site only ever sees a short-lived session token.

03Per-student isolation in the database

Every student-owned table — answers, revision history, feedback, reading notes, certificates — has row-level security enabled, with policies that compare the caller's authenticated user id to the row's owner. Isolation is enforced by the database itself, not by application code that could be bypassed.

• A signed-in student can read, write and delete only their own rows.
• Anonymous visitors have no read or write access to student-owned tables.
• Tables with no policy for a role are closed to that role by default.

04Authorization for faculty

Roles are held in a dedicated roles table, never on a profile record that a user could edit, so a student cannot promote themselves. Faculty-only actions — editing readings and questions, changing feedback settings, reading contact messages — re-check the role on the server for every request. Nothing is trusted because the browser said so.

05Server-side boundaries

Privileged work happens in server functions. Feedback generation, certificate issuance, admin edits and contact submissions all validate their input, verify the caller, and only then touch the database. Privileged database credentials exist solely on the server and are never bundled into browser code.

06Secrets and keys

API keys for the AI feedback model and the service-level database key are stored as server-side secrets, injected at request time, and never logged, echoed, or returned to the browser. The browser holds only a publishable key that is powerless without a valid session and the row-level policies above.

07Transport and data at rest

All traffic is served over HTTPS. Database storage and backups are encrypted at rest by the managed platform, which also handles patching and point-in-time recovery.

08Input validation

Every server entry point validates its payload against an explicit schema before doing work, including the contact form. Database writes use parameterised queries, so submitted text is data and never executable SQL.

09What we deliberately do not do

Reducing what is collected reduces what can be lost.

• No payment card data is collected or stored on this site.
• No third-party advertising or analytics trackers follow you across the web.
• No student coursework is published, shared between accounts, or used to train models.

10Reporting a vulnerability

If you believe you have found a security problem, please report it privately through the "Contact Walter Barry" page or to wrbarry3@gmail.com before disclosing it publicly. Include the steps to reproduce it. Reports are welcome and will be acknowledged.