EFDS Society is a student society site.
EFDS Society is a student society at Imperial College London. This website is operated by the society and is not the official Imperial College London website.
For a question about information held about your account, correction, deletion where applicable, or a privacy concern, please use the contact route.
What the current application uses
When you authenticate, EFDS uses the Supabase Auth identity supplied by the configured provider. The application reads the authenticated user ID, email address, email-confirmation status, and available name metadata for sign-in and profile provisioning.
- Profile: email, optional display name and profile photo, member type, access role, optional officer association, active state, login timestamp, row timestamps, and profile metadata.
- Identity link: the Supabase Auth user ID linking an authenticated account to its EFDS profile.
- External access: approved non-Imperial exceptions may contain an email, access role, optional member type, reason, active state, expiry, creator profile reference, timestamps, and metadata.
The website does not treat a client-provided role or email as authoritative. EFDS authorization is resolved server-side. Members can change their display name and upload or remove their own profile photo in the workspace.
Email first, with optional Google sign-in
Imperial users can sign in with a verified ic.ac.uk or imperial.ac.uk email address and password or a secure email link. Google sign-in is available when its OAuth provider is configured. Both paths use Supabase Auth; EFDS then checks the authenticated email domain and the EFDS profile.
Approved external users may also use the email flow. Authentication establishes identity; it does not automatically grant a committee or admin role.
Identity only
Google sign-in uses basic OpenID Connect identity information and does not request Gmail, Drive or Calendar access. Website sign-in does not call Microsoft Graph or request mailbox, file or calendar permissions.
What Supabase and Vercel do
- Supabase Auth: handles the configured authentication flows and session lifecycle.
- Supabase PostgreSQL: stores the application profile/access model and backend knowledge/operational records, with RLS policies defined by the backend migration.
- Supabase Storage: stores optional profile photos in a private bucket. Members can access their own photo through the authenticated workspace.
- Vercel: hosts and deploys the Next.js website. It is not the EFDS database or identity provider.
Current scope of the backend
The backend schema includes officers, profiles, approved access exceptions, knowledge articles and derived knowledge records, documents, meetings, decisions, action items, and Slack records. These are subject to the application’s private role boundaries and database RLS.
The job tracker currently rendered by the website is static page data; this audit found no demonstrated user-specific persistence for saved jobs. This notice does not claim that every backend table is populated or written by the current website.
Authentication needs a session
The Next.js application uses Supabase’s SSR client to read and update authentication session cookies. These cookies support sign-in, server-side identity checks, and session continuity. The application callback exchanges the authorization code server-side before evaluating EFDS access.
Questions are welcome
No formal published retention schedule is defined in the current repositories. The operational approach is to retain account, authorization, and operational records for as long as needed to run and secure the society service, and to review requests for correction or deletion against account, access, audit, and operational needs.
To ask what account information is held, request correction, request deletion where applicable, or raise a privacy concern, use /contact. Please do not send passwords, access tokens, or other secrets.