Technical review for IT and security teams
Security and data handling
Last updated: 2026-06-25
The conclusion, in 30 seconds
Research data — page text, datasets, plots, and images — is never transmitted to Lablate's servers. By default it is held in browser storage and in a local folder the user selects.
External traffic to Lablate's own infrastructure consists of exactly two things: sign-in (Supabase Auth, Tokyo region) and delivery of the application itself (Vercel). Neither carries research data. If — and only if — the user enables the Google Drive integration, research data moves directly between the browser and that user's own Google Drive, without passing through Lablate's servers.
Where the data goes
What is stored, and where, when you use Lablate.
| Type of data | Stored in | Sent to Lablate's servers |
|---|---|---|
| Research data (text, numbers, plots, images) | User's own computer / institutional OneDrive / Google Drive | Never |
| Credentials (email, display name) | Supabase Auth (Tokyo region) | Yes, at sign-in only |
| The application (HTML / JS / CSS) | Vercel CDN (hosting) | Download only |
There is no “Lablate server” in the usual sense, and no API endpoint that receives research data exists anywhere in the codebase.
Complete list of outbound traffic
The following is every network request Lablate makes in use.
1. First visit
- Destination:
- Vercel CDN
- Payload:
- HTML / JS / CSS (the application itself)
- Nature:
- The same as loading any website. Once cached, the app runs offline.
2. Sign-in
- Destination:
- Supabase Auth (Tokyo region) and the chosen identity provider (Microsoft or Google)
- Payload:
- OAuth authorization code, anon key (a public value), redirect URI
- Nature:
- A standard OAuth 2.0 flow. Contains no research data.
3. Automatic session refresh
- Destination:
- Supabase Auth
- Payload:
- Refresh token (via an HttpOnly cookie)
- Nature:
- Session upkeep by Next.js middleware, nothing more.
4. Sign-out
- Destination:
- Supabase Auth
- Payload:
- The current session token
- Nature:
- Discards the cookie and invalidates the session, nothing more.
5. Google Drive integration (optional, only if enabled)
- Destination:
- Google Drive API (the user's own Google Drive)
- Payload:
- Research data under the folder the user selected (read and write)
- Nature:
- Scoped to drive.file, meaning only the folder the user picked is reachable; the rest of the Drive is not visible. Does not pass through Lablate's servers. Never occurs unless the integration is enabled.
Items 1 to 4 are authentication and application delivery only, and carry no research data. Item 5 occurs only when the user enables the Google Drive integration, and its destination is the user's own Google Drive, not Lablate's servers. There is no other traffic that sends research data anywhere. No third-party tracking is in place; only anonymous usage statistics are collected, through Vercel Analytics, and they contain no research data.
Risk compared with equivalent services
What you entrust to Lablate's authentication layer carries about the same risk as signing in to Slack, Notion, or GitHub. In each case you are entrusting credentials, not your working data.
| Aspect | Notion / Google Docs | Lablate |
|---|---|---|
| Data sovereignty | With the vendor | With the user (entirely) |
| Working offline | Limited | Yes, after sign-in |
| Vendor lock-in | Yes | None (CSV / Markdown / JSON / PNG) |
| If the servers go down | Unusable | Local work continues |
| Blast radius of a breach | Every customer | Your own machine only |
Technical architecture (for engineers)
Lablate is built on React 19 and Next.js 15 (App Router), with page components rendered client-side.
Storage layer (entirely within the client)
- localStorage: page tree, page bodies, datasets (a volatile cache)
- IndexedDB: images (as Blobs) and folder-handle history
- File System Access API: reading and writing the local folder
Grep the source for fetch, axios, XMLHttpRequest, and WebSocket and the only outbound traffic you will find is authentication (Supabase) and, where the user has enabled it, the Google Drive integration (the Google API, against the user's own Drive). No request sends research data to a Lablate server.
Authentication layer
- Protocol: OAuth 2.0 Authorization Code Flow with PKCE
- Identity providers: Microsoft (Azure AD, multi-tenant), Google OAuth, and email magic links
- Session management: HttpOnly cookies, refreshed automatically by Next.js middleware
- Held by Supabase: UUID, email address, provider type, display name
- Not held by Supabase: research data of any kind
- Row Level Security: a user can read and write only their own profile row
How to verify this yourself
If you want to confirm the data flow before adopting Lablate:
- Open DevTools in Chrome or Edge and select the Network tab.
- Do anything you like — create a page, add a dataset, paste an image.
- If no request appears in Network, nothing left the machine. (With the Google Drive integration enabled you will see requests to
googleapis.comon save — that is your own Google Drive.) - Requests to
<project>.supabase.coappear only when signing in; inspect the bodies and you will find no research data.
Frequently asked questions
Q. If the folder syncs to OneDrive, doesn't the data reach Microsoft?
A. Lablate only writes to a local folder on the computer. If that folder happens to be synced by OneDrive, it is Windows that uploads it to Microsoft. This is the same as a file saved from Word ending up in OneDrive; Lablate never calls the OneDrive API. Your organization's OneDrive and SharePoint policies apply unchanged.
Q. Doesn't the Google Drive integration hand data to Google?
A. Only when the integration is enabled does Lablate read and write research data directly to the folder the user chose in the picker. The destination is the user's own Google Drive, and the traffic does not pass through Lablate's servers. Access is confined to the drive.file scope, which reaches only the selected folder and cannot see the rest of the Drive. Without the integration this traffic never occurs, and Lablate works fine with a local folder or OneDrive alone.
Q. Could data be extracted from the Vercel servers?
A. No. Vercel only serves static assets; no endpoint that receives user data exists in the codebase (there are no API Routes under src/app/). Even if Vercel were compromised, the impact would be limited to serving a tampered build — previously saved data is unaffected.
Q. What if Supabase were breached?
A. The exposure would be limited to email addresses, display names, and plan tier. Research data is not stored in Supabase and is therefore out of scope. Supabase runs on managed PostgreSQL in the Tokyo region; the risk level is comparable to signing in to Slack, Notion, or GitHub.
Q. What happens if LLM features are added later?
A. Only when you use an LLM feature would the relevant text or data be sent to an LLM API. That is unavoidable given what such a feature does, but it happens only when you explicitly invoke it — nothing is sent quietly in the background.
Q. What format is the exported data in?
A. There is no proprietary format. The save folder mirrors the hierarchy you built, filled with Markdown (.md), CSV (.csv), and images (.png, .jpg). If you stop using Lablate you can still open everything in Excel, a text editor, or an image viewer, and copying the folder is the whole migration.
Contact
If you have further questions as part of a security assessment or adoption review, please get in touch.
- Email: lablate.app@gmail.com
- Expect a reply within 3–4 business days.