Technical review for IT and security teams
Security and data handling
Last updated: 2026-09-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 (or, if the user enables an integration, in their own Google Drive or OneDrive).
Lablate's own traffic consists of delivery of the application (Vercel), sign-in (Supabase Auth, Tokyo region; signing in is optional), error reports when a fault occurs (Sentry), and anonymous usage statistics (Vercel Web Analytics). None of these carries research data. If — and only if — the user enables the Google Drive or OneDrive integration, research data moves directly between the browser and that user's own cloud storage, without passing through Lablate's servers. The one exception is what a user chooses to attach when sending a bug report or suggestion from the in-app form (including anything visible in a screenshot), which is sent to Sentry only when the user sends it.
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) | A folder on the user's own computer (which may be one synced by institutional storage such as OneDrive) / the user's own Google Drive or OneDrive (only if connected) | Never |
| Account information (email, display name, etc.; only if the user signs in) | Supabase Auth (Tokyo region) | Yes, at sign-in and session refresh |
| Bug reports and suggestions (message, optional email, images or files the user attaches) | Sentry (United States) | Yes, only when the user sends a report |
| The application (HTML / JS / CSS) | Vercel CDN (hosting) | Download only |
Nothing on lablate.com (Vercel) receives and stores research data. The only server-side code is page delivery, the sign-in callback (/auth/callback), and session-cookie refresh. Error reports and bug reports are forwarded to Sentry through /monitoring on lablate.com so that ad blockers do not drop them. For the same reason, violation reports from the browser's Content Security Policy are forwarded to Sentry through /csp-report. Both routes only relay and store nothing.
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 loaded, editing continues even if the network drops. No service worker is installed, so the app cannot be reloaded or started while offline.
2. Sign-in (optional)
- Destination:
- Supabase Auth (Tokyo region) and the chosen identity provider (Microsoft or Google), or, for a magic link, an email to the address entered
- Payload:
- OAuth authorization code, anon key (a public value), redirect URI. After sign-in: fetching the profile (display name, plan) and loading the provider's avatar image directly from the provider's image host (no referrer sent)
- Nature:
- A standard OAuth 2.0 flow. Contains no research data. Every feature works without signing in, in which case none of this traffic occurs.
3. Automatic session refresh
- Destination:
- Supabase Auth
- Payload:
- Refresh token (via a cookie)
- Nature:
- Session upkeep by Next.js middleware and the in-browser Supabase client when a page is opened, 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.
6. OneDrive integration (optional, only if enabled)
- Destination:
- Microsoft Graph API (the user's own OneDrive)
- Payload:
- Research data under the folder the user connected (read and write)
- Nature:
- Scoped to Files.ReadWrite.All. Technically this reaches every file on OneDrive the user can access, because Microsoft offers no narrower scope equivalent to Google's drive.file while still allowing a folder shared by someone else to be connected. In practice Lablate reads and writes only under the folder the user connected. Does not pass through Lablate's servers. Never occurs unless the integration is enabled.
7. Error reports (only when a fault occurs)
- Destination:
- Sentry (Functional Software, Inc., United States)
- Payload:
- Error message (truncated to 200 characters), stack trace, URL of the page, browser and OS type, and an anonymous user identifier (a hash of the account ID while signed in, a random per-device ID when signed out)
- Nature:
- Used only to investigate faults. Research data itself is not sent. Console logs, records of on-screen clicks and input, and URL query strings are excluded from what is transmitted, and cloud-storage file and folder names in request URLs are masked. Email addresses, display names, and the raw account ID are never sent. Because an error message can pick up a fragment of user-derived text, message formats known to carry such fragments are masked, and all messages are truncated to 200 characters.
8. Bug reports and suggestions (only when the user sends one)
- Destination:
- Sentry (Functional Software, Inc., United States)
- Payload:
- Report type and message, an email address if the user enters one, images, screenshots, or files the user attaches, the page URL (without the query string), browser and OS type, display language, screen size, and the anonymous user identifier
- Nature:
- Only reports sent from the button at the bottom right of the app. A screenshot is taken only when the user presses “Attach current screen” and can be removed or redacted before sending. Because attachments may contain research data, the form always shows a notice.
9. Anonymous usage statistics
- Destination:
- Vercel Web Analytics
- Payload:
- Page views, country (inferred from IP), and feature-usage events (connecting a folder / creating a page / importing a dataset / previewing or exporting a PDF). Event values are limited to fixed enumerations (such as the kind of source) and numbers.
- Nature:
- Collected without cookies and in a form that cannot identify an individual. Folder names, file names, and the contents of research data are never included.
Items 1 to 4 are authentication and application delivery only, and carry no research data. Items 5 and 6 occur only when the user enables a cloud integration, and their destination is the user's own Google Drive or OneDrive, not Lablate's servers. Item 7 is sent only when a fault occurs and item 9 only to understand usage; neither carries research data itself. Item 8 occurs only when the user sends a report and contains only what the user chose to attach. There is no other traffic that sends research data anywhere. No advertising or behavioural tracking is in place, and session replay is not used.
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, once loaded |
| Vendor lock-in | Yes | Minimal (open formats such as Markdown / CSV / JSON / PNG) |
| If the servers go down | Unusable | Local work continues |
| Blast radius of a breach | Every customer | Each user's own storage 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 / IndexedDB: a working cache of the page tree, page bodies, datasets, images and so on, plus folder-handle history and display settings
- File System Access API: reading and writing the local folder (the source of truth)
- Google Drive API / Microsoft Graph API: only when a cloud integration is enabled, the browser reads and writes the user's own Drive or OneDrive directly
Outbound traffic is limited to what the complete list above names (authentication, cloud integrations, error reports, bug reports, and usage statistics). No request sends research data to Lablate to be stored.
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: cookies (@supabase/ssr, SameSite=Lax; not HttpOnly, because the in-browser client also reads them), refreshed automatically by Next.js middleware
- Held by Supabase: UUID, email address, provider type, display name, avatar image URL, plan; plus, as standard Supabase Auth behaviour, sign-in timestamps, the IP address and user agent of each session, and an authentication audit log (including IP addresses)
- Not held by Supabase: research data of any kind
- Row Level Security: a user can read and update only their own profile row (rows are created only by the sign-up trigger and deleted along with the account)
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.
- Inspect the destination and body of each request that appears. The only requests carrying research data go to your own storage (
googleapis.comwith the Google Drive integration,graph.microsoft.comwith the OneDrive integration). - The other requests you may see are usage statistics (
/_vercel/insights, event names only, such as page creation or dataset import),/monitoringwhen an error occurs or a bug report is sent (relayed to Sentry), and session upkeep while signed in (<project>.supabase.co). None of their bodies contains research data (apart from anything you attach to a bug report yourself).
Frequently asked questions
Q. On a shared computer, is signing out enough?
A. A normal sign-out does not erase the copy of your notes kept in this browser, the list of connected locations, or the link to Google Drive / OneDrive (so that you can keep working as a guest after signing out). On a shared computer, use “Sign out and erase from this device” in the account menu (or “Erase data on this device” on the start screen if you are not signed in). If there are edits that have not been saved to a folder yet, erasing is stopped so they are not lost. Display settings such as language and theme are kept.
Q. If the folder syncs to OneDrive, doesn't the data reach Microsoft?
A. It depends on how you use it. (1) Opening an OneDrive-synced folder as a local folder: Lablate only writes to a local folder on the computer and never calls the OneDrive API; it is Windows that uploads it to Microsoft, the same as a file saved from Word ending up in OneDrive. (2) Connecting to OneDrive directly: the browser calls the Microsoft Graph API and reads and writes research data under the folder you connected. In both cases the destination is your own OneDrive and the traffic does not pass through Lablate's servers. 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. Why does the OneDrive consent screen say "all files"?
A. Because Microsoft offers no delegated permission equivalent to Google's drive.file, which is limited to what the user picked. Connecting to a folder someone else shared with you requires Files.ReadWrite.All, and the consent screen shows that scope. In practice Lablate reads and writes only under the folder you connected. If that scope is a concern, you can skip the OneDrive integration and use a local folder (including an OneDrive-synced one) or the Google Drive integration instead.
Q. Could data be extracted from the Vercel servers?
A. Research data is never stored on Vercel. The only server-side processing on Vercel is page delivery, the sign-in callback (/auth/callback), session-cookie refresh, and the relays to Sentry (/monitoring and /csp-report); no endpoint that receives and stores research data exists in the codebase. If Vercel were compromised, the risk is serving a tampered build — that is, the app running in your browser itself being altered. Past data cannot be pulled from Vercel, but data you open while running a tampered build could be exposed. This risk is common to every web app that runs in the browser.
Q. What if Supabase were breached?
A. The exposure would be limited to email addresses, display names, avatar image URLs, and plan, plus sign-in timestamps and the IP addresses and user agents used to sign in. (If you use Lablate without signing in, Supabase holds nothing about you.) 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. The save folder holds a Markdown file (.md) per page, datasets as CSV (.csv), images (.png, .jpg), videos (.mp4, .webm), and plots as PNG, so if you stop using Lablate you can still open everything in Excel, a text editor, or an image viewer. As the editable source, page bodies and table/plot settings are also saved as JSON, diagrams in Excalidraw format (.excalidraw), and chemical structures as CDXML (.cdxml). None of these is encrypted or a proprietary binary, 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.