Privacy
jobo saves job posts to your own computer. Three things leave it, each with its own switch, and this page says exactly what they are.
Last updated 8 September 2026 · applies to jobo 1.1.0 and later
The short version
- Everything you save is written to your browser first. Saving works with no account and with the wifi off.
- Your notes, tags, priority and reminders never leave your device. Neither does anything you type into a form.
- Three things do leave, and all three can be switched off: the public words of a post you save, your application stages, and usage analytics.
- jobo has no login. Nothing here is tied to a name, an email or an account, because there isn’t one.
What jobo keeps on your device
All of this lives in your browser profile, on your computer.
- Opportunities — role, company, location, pay, deadline, stage, priority, tags, notes, contacts and dates you record.
- Captures — for each place you saved a job from: the URL, the page or post title, the author’s visible name and profile link, the visible text at the moment you pressed save, timestamps, and how complete the capture was.
- Attachment references — the type and URL of images, documents and videos that were visible. References, never the files.
- Form shapes — what an application form asks for. Never what you answered.
- Activity history — what happened to a record and when, including the snapshots that make undo work.
- Settings — your preferences.
What leaves your device
Exactly three things. Each is listed with what it contains and the one switch that stops it. Nothing else is transmitted by jobo, ever.
1. Job posts you save, to the shared index
On by default. Settings → Shared job index → Contribute my saved jobs.
When you save a job, the capture is also sent to jobo’s server and added to an index shared by everyone using jobo, so that nobody has to find the same job twice.
| Sent | What that means |
|---|---|
| Job details | Title, company, location, pay, experience, skills, application URL, deadline |
| The source | Post permalink, canonical URL, source type and domain, posting time |
| Post content | The visible text of the post, as captured |
| The author | Their name, headline, profile URL, and any contact details the post itself displays |
| Attachments | URLs and titles of images, documents and links in the post |
| An install id | A random value generated when you installed jobo |
This is somebody else’s data. A post was written by a person, and contributing it shares their name, headline and any contact details their post displayed. All of it was publicly visible on the page you saved from — but putting it into a shared index is a further step, taken by you. If that is not something you want to do, switch contributing off. jobo works fully without it.
Contributed jobs can become public pages
A contributed posting that the reading judges to be a genuine job, with a named employer and enough detail to be useful, gets a page on this site at /jobs/…. Those pages are public and can be indexed by search engines.
What is on such a page is deliberately narrower than what was captured:
- The structured reading, not the post. Role, company, location, experience, skills and a summary — jobo’s own description of the opening. The original wording is not republished.
- Never a person’s contact details. Emails, phone numbers and profile links that a post displayed stay in the private dashboard and are never put on a public page.
- Always a link back. Every page names where the posting came from and links to the original, which is where an application should go. jobo is not the employer and receives no applications.
- Most are not indexed. A page is offered to search engines only when it has a real employer, real detail, and has not gone stale. Anything thin, expired, or where the “company” looks like an individual’s name is kept out of the index.
Switching contributing off stops anything further being added. To have a specific page removed, email info@wize.co.in with the link and it will be taken down.
Switching it off sends nothing further, and discards anything still queued rather than holding it. Contributions already made stay in the index: they are not linked to an identity, so there is nothing to look them up by.
How the index deduplicates. One row per job, not per person who saved it. Jobs are matched by the platform’s own post id where there is one, otherwise by canonical URL with tracking parameters removed, otherwise by a hash of the post text. A job saved by five hundred people is one row with a count of five hundred.
Reading a post into fields. A contributed post is read server-side into structured fields — role, pay, location, deadline — using Google Gemini. Only the public words of the post and its author line are sent for that; your install id is not. If the reading fails, or the post turns out not to be a job, the original is kept untouched.
2. Your application tracker
On by default. Which stage a job is at and the dates it changed, so your board works on more than one computer.
Only the stage and its timestamps, against the install id and the job’s id in the shared index. Your notes, tags and priority are not part of this and stay in the browser.
3. Usage analytics
On by default. Settings → Your data → Product analytics.
So it is possible to tell a broken feature from an unpopular one. What is sent is an event name such as “job saved”, the version, and small structured facts about the event itself — a source type, an error code, a count, which setting moved and whether it went on or off.
Never a URL, a job title, a company, an author, a note, a tag, or any captured text. Neither the extension nor this website uses PostHog’s own library: both post named events themselves, precisely so there is no autocapture sweeping up the contents of a job post, and no PostHog session recording.
The switch is read before every single event, so turning it off takes effect immediately rather than at the next restart.
On this website only, Microsoft Clarity records how pages are used, which includes a replay of pointer movement and clicks. Everything on screen that came out of somebody else’s post — the job cards, the detail panel — is marked so a recording never captures it.
What jobo never collects
- Passwords, one-time codes, payment details, government identifiers.
- Anything you typed, uploaded, or that your browser autofilled into a form.
- Hidden form fields, CSRF tokens, session tokens, cookies or the authentication state of any site.
- Comments, reactions, message inboxes, connection lists, or another person’s profile page.
- Your browsing history. jobo has no
tabspermission and cannot see the URLs of tabs you have not acted on. - Content from any tab you have not explicitly acted on.
Access to the sites you visit
jobo asks for access to every site at install. That is the broadest thing it requests, and it is worth being precise about why and what it does not mean.
Why. A job is as likely to be on a company careers page, an applicant tracking system or a job board as on LinkedIn. A save button that has to be enabled site by site is missing exactly where you first need it.
What it is used for. Two things: drawing jobo’s own Save button on the page, and — when you press it — reading the visible content of that one page. jobo does not crawl, does not automate any site, never signs in as you, and reads nothing on a page you have not acted on.
Turning it off. Dismiss the button on a single site with the × on the button itself. Turn it off everywhere in Settings. Either way jobo unregisters the code from the page rather than hiding a rendered element — the switch is real. Saving still works from the toolbar icon, the keyboard shortcut and the right-click menu.
Application forms, specifically
When you save a page containing an application form, jobo records the shape of the form: field labels, whether each is required, select options, helper text, accepted file types and validation rules.
The implementation is value-blind by construction. It reads a fixed allowlist of attributes and never touches a field’s value, files or checked state. Password, hidden and token-named inputs are skipped entirely rather than recorded as empty. The whole feature can be switched off in Settings.
Who else is involved
- jobo’s own index — hosted on Vercel and Supabase, which store the contributed captures described above.
- Google Gemini — reads a contributed post into structured fields, as described above.
- PostHog — processes usage analytics on jobo’s behalf.
- Microsoft Clarity — session replay, on this website only.
- Google Sheets — only if you connect it yourself, see below.
None of them is paid for your data, and jobo sells nothing to anyone.
Google Sheets, if you connect it
- jobo requests the
drive.filescope — the narrowest one that works. It grants access only to files jobo creates or that you explicitly open with it. jobo cannot see the rest of your Drive. - Your opportunity data is written to your spreadsheet, in your own Google account.
- Access tokens are held in memory-backed session storage and are never exposed to page scripts. jobo never receives a refresh token, and no token is ever sent to a jobo server.
- Disconnecting revokes the token with Google and clears the local copy. Rows already written stay in your spreadsheet — they are yours to delete.
jobo’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. jobo uses Google user data only to provide the spreadsheet-mirroring feature you asked for; does not transfer it except as necessary to provide that feature or to comply with law; does not use it for advertising and does not sell it; and does not allow humans to read it, except with your explicit consent, for security purposes, or where the law requires it.
Local diagnostics
A different thing from the analytics above, with its own switch, because it is a different promise: diagnostics never leave the device. jobo counts events locally — how many saves succeeded, how many failed with which non-sensitive error code. Nothing is transmitted; there is nowhere for it to go. The report you can download contains versions, counts, error codes and permission state, and no job text, no URLs and no personal data.
Keeping and deleting
- One record — open it and choose Move to trash, then delete it permanently from Trash.
- Everything — Settings → Delete all local data. This clears every record, resets your settings, and discards your install id; the next contribution, if any, uses a new one.
- Uninstalling removes jobo’s storage with it.
- Take a copy first — Settings → Export all my data (JSON), or a CSV export from the dashboard.
- Google Sheets — disconnecting stops all writing. To remove what was written, delete the rows or the spreadsheet, and revoke jobo’s access at myaccount.google.com/permissions.
- The shared index — contributions are not linked to an identity, so there is no per-person deletion. Email us and we will remove a specific job row.
Security
- Captured HTML passes through an allowlist sanitiser before storage: scripts, styles, frames, event handlers and
javascript:URLs are removed. - Only http and https URLs are ever stored, rendered as links, or opened.
- Every message crossing a context boundary is size-capped, schema-validated and sender-checked before it can reach the database.
- CSV cells beginning with
= + - @, tab or carriage return are escaped, so a malicious job posting cannot execute a formula in your spreadsheet. - Content is length-capped at every layer, so a hostile page cannot exhaust your storage quota.
- No eval, no dynamic code, no inline scripts, and no remotely hosted code.
Children
jobo is not directed at children under 13 and does not knowingly collect data from them.
Changes
Material changes are noted in the release notes and reflected here, with the date at the top of this page updated.
Contact
info@wize.co.in. There is no account for us to look up, because jobo does not have accounts — so tell us what you need and we will find it from what you can give us.