Jestr Apps is a Chrome extension that quietly mirrors the browser apps you already use into storage you own, so you can keep reading your own data when those services are unreachable. This policy explains exactly what it reads, where that ends up, and who else can see it. The answer to the last question is: nobody.
1.What this policy covers
This policy covers Jestr Apps, the browser extension published by Jestr and distributed through the Chrome Web Store. Its source code is public at github.com/jestr-ai/jestr-apps, so every claim below can be checked rather than taken on trust.
Section 13 separately covers the small amount of data the jestr.ai website itself handles. Nothing in this policy applies to the apps Jestr backs up — Google, Microsoft, Reddit, Telegram and Anthropic each have their own privacy policies governing your accounts with them.
2.The short answer: there is no Jestr server
Most privacy policies are long because the product sends data somewhere. Jestr Apps does not, and cannot: the extension has no backend. It was built with no accounts, no OAuth consent screen and no API keys precisely so that there is no service of ours in the path between you and your data.
Every network request the extension makes goes to the app’s own origin — the same servers your browser already talks to when you open that app in a tab. It adds no destinations of its own. As a result:
- We do not collect, receive, store or process your data. We never have it.
- No employee, contractor or subprocessor of Jestr can read your backups.
- There is no breach of our servers that could expose your backed-up content, because it is never on them.
3.What Jestr Apps reads and stores on your device
When an app is enabled, the extension asks that app’s own endpoints for the data you can already see in your browser, and writes a copy to your device:
| App | What is copied to your device |
|---|---|
| Google Drive | Docs, Sheets and Slides you open, plus files in the folders it enumerates, exported as .docx, .xlsx and .pptx, with a short version history |
| SharePoint | Document libraries on the team sites you visit: the file bytes plus the site and folder structure they sit in |
| Posts, comments, community icons and full-resolution media from communities you open or subscribe to, and your own posts and comments | |
| Telegram | Private chats, groups and channels, including message text, photos, videos and avatars |
| Claude | Your claude.ai conversations and the artifacts extracted from them |
Alongside the content itself, the extension keeps a local index it needs in order to work: item titles, the URLs items came from, timestamps, sizes, content hashes, per-app settings and the schedule state that tells it what has already been backed up.
These are your files and your private messages. The copies Jestr Apps makes therefore contain whatever you keep in those accounts, which may include personal, confidential or sensitive information. Jestr does not inspect, classify or profile that content — it validates, hashes, encrypts and writes it. All of it stays on your device.
4.Where that data is stored
| Location | What lives there |
|---|---|
| OPFS | The extension’s own private storage inside your Chrome profile. This is the working copy, and it is encrypted. |
| Your folder | A plain folder on your disk that you choose once, using Chrome’s File System Access permission. This is the durable copy, also encrypted. It is written to, and read only when you explicitly run an import. |
chrome.storage.local | Settings, schedule state and the per-item index of titles, URLs, timestamps and hashes. Local to this Chrome profile, not synced to any account. |
| IndexedDB | The SharePoint site catalogue, local to this profile. |
All four are on your machine. None of them is a Jestr service, and none of them is synchronised anywhere by the extension.
5.What Jestr Apps never does
- It never transmits your backed-up content, your file names, your messages or your browsing to Jestr or to any third party.
- It contains no analytics, telemetry, crash reporting, usage statistics, advertising SDK or tracking pixel.
- It never asks for a password, and never stores a credential: no token, no key, no copy of a cookie is written to disk.
- It never sells, rents or shares personal data, and it is never used for advertising, ad personalisation, data brokerage or determining creditworthiness.
- It runs no persistent content scripts in your pages. Code is injected into a page only while a Telegram backup is actually running, and nowhere else.
- It uses your data for one purpose only: making, verifying and serving back your own local backup.
6.How it reaches your accounts without a password
You are already signed into these apps. Your browser holds a live, authenticated session for each of them, and an extension with permission for a site can issue requests that carry it. Jestr Apps calls the same private endpoints the web app itself calls, so it receives exactly what the app would have shown you — no more, and no less.
Three details are worth stating explicitly:
- One cookie is read, for one header. Google’s data frontend requires an anti-forgery header derived from the
SAPISIDcookie. The extension reads that cookie in memory to compute the header, and sends it only to Google’s own endpoint, which is what expects it. The value is never stored, logged or sent anywhere else. - One header is rewritten, on our own requests only. A
declarativeNetRequestrule rewrites theOriginheader on the extension’s own calls to Google’s Drive data frontend, because an extension origin is not one Google trusts. The rule is scoped so that it cannot touch the traffic of a real Drive tab. - Telegram is driven in the page. Telegram Web keeps its session inside the page and speaks its own protocol over a WebSocket, so there is no request an extension can make. Instead a small script is injected into a tab you already have signed in, and asks the page’s own client for your history. It asks for no phone number and no login code, and injects nothing until a backup is actually running.
Two consequences follow. The extension can never reach anything you cannot, because each server applies your own permissions to every call. And it cannot outlive your session: sign out, and collection simply stops and tells you so.
7.Auto redirect
Auto redirect is an optional switch. While you have it armed, navigations to an app Jestr covers are intercepted and served from your local copy instead of the live site, so the pages still open with the network down. The interception happens entirely inside your browser: no request about where you are going is sent to Jestr, because there is nowhere to send it. The toolbar badge shows AR the whole time it is armed, and you can turn it off from the panel or from the interstitial itself.
8.Permissions, and why each one is requested
| Permission | Why it is needed |
|---|---|
tabs, webNavigation | To notice when you open a document or an app page, which is what triggers a backup, and to serve a local copy when Auto redirect is armed |
storage, unlimitedStorage | To keep settings and the local index, and to hold backups in the extension’s own storage without Chrome evicting them under storage pressure |
alarms, idle | To run syncs on a schedule, and to do the heavy work while the machine is idle so it stays out of your way |
cookies | Solely to read the SAPISID cookie and derive the anti-forgery header Google’s data frontend requires (section 6) |
declarativeNetRequest | To rewrite the Origin header on the extension’s own requests to that frontend, scoped so it cannot affect your normal browsing |
webRequest | Read-only observation of claude.ai’s own API calls to learn the API version header it currently expects. It never modifies or blocks a request |
offscreen | To run the long-lived hidden page that performs fetches and writes files, which a Manifest V3 service worker cannot do |
scripting | For Telegram alone: to inject the collector into a tab you already have signed in, and only while a backup is running |
sidePanel | The whole user interface is the side panel |
notifications | To tell you when something actually needs you: signed out, storage full, folder access lost |
The extension also requests host permissions for the apps it backs up and the content delivery hosts they serve files from: docs.google.com, drive.google.com, drive.usercontent.google.com, drivefrontend-pa.clients6.google.com, *.googleusercontent.com, *.sharepoint.com, www.reddit.com with Reddit’s media hosts, web.telegram.org and claude.ai. It holds no permission for any other site, so it cannot see, read or alter the rest of your browsing.
9.Encryption at rest
File contents are sealed before they are written, in the extension’s own storage and in your folder alike:
| Layer | What it does |
|---|---|
| Passphrase | PBKDF2-SHA256 with 2,000,000 iterations, which unwraps the vault key. The passphrase itself is never stored |
| Per file | A fresh ephemeral ECDH P-256 key pair, through HKDF, into AES-256-GCM |
| Recovery code | 128 bits of entropy, issued once at setup, bound so it cannot be replayed elsewhere |
| File names | Item identifiers rather than titles, so a directory listing is not a table of contents |
The lock re-arms on every browser restart, and reading anything back requires your passphrase. Backups keep running while locked, because sealing needs only the vault’s public key.
What is not encrypted, stated plainly: the local index in chrome.storage.local — item titles, URLs and timestamps — and the SharePoint catalogue in IndexedDB. Neither is copied into your backup folder, so a stolen folder yields nothing readable. A copied Chrome profile would show what you have, not what is in it.
We hold no copy of your passphrase, your recovery code or your vault key, and no way to derive them. Lose both the passphrase and the recovery code and your backups cannot be decrypted, by us or by anyone. That is a deliberate property of the design, not a gap in it.
10.Your control: pausing, clearing and deleting
- Pause any app from the side panel and it stops collecting immediately.
- Clear an app’s data from its own settings to remove what has been collected for it.
- Uninstall the extension and Chrome deletes its storage, including OPFS and the local index. Your chosen backup folder is untouched: it is your folder, and you can delete it yourself at any time.
- Storage is capped, never evicted. One shared budget governs every app. At the limit the extension stops backing up and tells you, rather than deleting one backup to make room for another.
- Nothing to request from us. Rights of access, correction, export and erasure over the backed-up content are exercised directly on your own device, because we hold no copy of it and no account records tied to your use of the extension.
11.Chrome Web Store Limited Use compliance
Jestr Apps complies with the Chrome Web Store Limited Use requirements. Specifically:
- User data is used only to provide the extension’s single purpose — making a local backup of the apps you use and serving it back to you offline.
- User data is not transferred to any third party. There is no onward transfer to disclose, because no data leaves your device.
- No human reads your data. We have no access to it at any point.
- User data is never used or transferred for advertising, ad personalisation, data brokerage, or determining creditworthiness or lending purposes.
12.Data categories, in Chrome Web Store terms
The Chrome Web Store treats data as collected when it is transmitted off the user’s device. By that measure Jestr Apps collects nothing. Several categories are nonetheless handled locally on your machine, and are listed here so the picture is complete:
| Category | Transmitted off device | Handled locally |
|---|---|---|
| Personally identifiable information | No | Only insofar as your own documents and messages contain it |
| Health information | No | Not sought; never identified or singled out |
| Financial and payment information | No | Not sought. No payment is taken by the extension at all |
| Authentication information | No | One cookie value read in memory to derive a request header; never stored |
| Personal communications | No | Telegram, Reddit and Claude content you choose to back up, encrypted at rest |
| Location | No | Not accessed |
| Web history | No | Navigation events are observed to trigger backups; the URLs of backed-up items are kept in the local index. No browsing history is compiled or retained beyond that |
| User activity | No | Which covered app tab is open, and whether the machine is idle, purely to schedule work |
| Website content | No | The files, posts and pages you back up, encrypted at rest |
13.The jestr.ai website
This page is served from jestr.ai, and the website is a separate thing from the extension. If you submit your email address on the site to request access, we store that address so we can contact you about the product. We do not sell it or share it for advertising. Ask us at privacy@jestr.ai and we will delete it. The extension itself neither reads nor sends anything to this website.
14.Children
Jestr Apps is a tool for professionals and is not directed at children under 13. We do not knowingly collect personal information from anyone, children included, since we receive no user data at all.
15.Changes to this policy
If the extension’s handling of data changes, this page changes with it and the effective date at the top is updated. Material changes — anything that would alter one of the guarantees in the summary above — will be reflected in the extension’s Chrome Web Store listing as well. The previous wording of this page remains in the public repository’s history.
16.Contact
Questions about this policy, or about how the extension handles anything not covered here:
- Email privacy@jestr.ai
- Or open an issue at github.com/jestr-ai/jestr-apps/issues