Tally — privacy

Last reviewed: 16 October 2026. Applies to the extension in this repository.

Tally sends your data nowhere. It talks to your Jira site and to nothing else. There is no Tally server, no account, no analytics, no telemetry, no crash reporting, and no third-party code running at any point. Everything it reads stays in your own browser profile.

This document is written to be the source of both the store listing's privacy answers and the justifications reviewers ask for. Anything asserted here is checkable against the code.

---

Single purpose

Tally reads the Jira Cloud worklogs your own account can already see and presents them as timesheets, alongside a local stopwatch that helps you notice time you have not logged yet — and logs that time to Jira when you ask it to.

What Tally reads from Jira

Only through your existing signed-in Jira session, and only from the one site you connect:

Every POST above is a read. Jira requires POST for them because the id list or the query is too long to put in a URL.

What Tally writes to Jira

Worklogs, and nothing else. Only when you press a button that says so, and only ones your own account logged.

The limits are enforced in the extension's service worker, not just hidden in the interface:

• Your worklogs only. Before any edit or delete, Tally checks the cached worklog's author against your account id and refuses if they differ. This is deliberately stricter than Jira itself, which lets a project administrator change anyone's worklog.
• Never automatically. No sync, refresh, or background task writes anything. Every write is one button press, and deleting asks you to confirm first.
• Nothing but worklogs. Tally does not create, edit, comment on, transition or delete issues, and has no code path that could.
• No email. Every write sends notifyUsers=false, so logging your own time never mails an issue's watchers.
• Remaining estimates move the way Jira's own interface moves them — logging 2h takes 2h off, deleting puts it back. Settings has a switch to leave estimates untouched instead.

Earlier versions of Tally were read-only and said so. That changed in August 2026: identifying unlogged time and then asking you to retype it into Jira made the whole tool end in a dead end.

Tally asks for worklogs by person. Yours, and — only once you add them to the Team view — the people you chose. The search that finds them returns each issue's worklogs whoever logged them, so Tally also learns the names of colleagues who logged on the same issues as you, for the Team view's people box; it keeps their worklogs only if you add them. Personal views filter to your own account id, and fail closed — if Tally cannot determine which account is yours, it shows an error rather than guessing.

And by issue, only while you are looking at one. On the Team view you can search for an issue and see who logged time to it. Tally then reads that issue's work log — and, when you open its child work items, those of the issues under it, and theirs. A work log is the list Jira shows on the issue itself, and Tally reads only as much of it as your account can see, adds it up by person, and shows it. None of it is kept. What Tally remembers is which issues you chose, so that it can read them again the next time you look.

What is stored, and where

All of it is local to your browser profile. None of it leaves your machine.

IndexedDB (database tally) — the worklog cache, so views open instantly instead of waiting on the network: cached worklogs, issue keys/summaries/projects/statuses, the display names of people whose worklogs Jira returned, and sync bookkeeping. Emptied by Settings → Your Jira → Cached worklogs → Clear, or by removing the extension.

chrome.storage.local — everything that must survive a browser restart. In full, because a complete list is more useful than a representative one:

chrome.storage.session — the keys of the Jira issues you most recently had open, twelve at most on any one site, each with the moment it was seen and the address of the site it was on, so the stopwatch can fill the newest in for you and the issue pickers can offer the last three before you type; while Tally is fetching from Jira, when that fetch began, when it last made progress and how far back it has reached, so the top bar can say it is fetching; when each stretch of days was last read from Jira, for you and for each person on your Team view, so that days opened twice in a minute are read once and the top bar can say when what is on screen was fetched; and, while Tally's window is open, the browser's id for that window, so pressing a button twice brings it forward rather than opening a second one. Session storage is held in memory, is never written to disk, and is cleared when the browser closes. The stopwatch also ignores a sighting once it is fifteen minutes old. See "What the grant lets Tally see besides the Jira API" below.

Never stored anywhere: your Jira password, an API token, or any credential. Tally has none. It relies entirely on the session cookie your browser already holds, which stays in the browser's own cookie jar and is never read by extension code.

The stopwatch is local only. Starting, stopping, notes and the issue key you may attach are never sent to Jira or anywhere else. Logging that time in Jira remains something you do yourself.

Permissions, and why each one exists

Deliberately not requested: tabs, downloads, scripting, cookies, webRequest, <all_urls>. Tally registers no content scripts and injects nothing into any web page.

About the "read and change your data" wording

Chrome writes that warning from the host pattern, and Chrome has no permission narrower than "read and change" for site access — every site grant is described that way regardless of what an extension actually does.

In Tally's case the "change" half is now accurate, and narrowly so: it changes worklogs you ask it to change, on the one site you connected, and nothing else. Every request — read or write — passes through one function, src/background/jira-fetch.ts, so the full set of endpoints Tally can reach is the list in the two tables above and is checkable in a single file.

What the grant lets Tally see besides the Jira API

Chrome hides a tab's URL from an extension that lacks access to that site, so this grant also lets Tally read the URLs of your open Jira tabs. Three features use that:

• The connection bar looks for an open atlassian.net tab so it can connect to the site instead of asking you to type it — and keeps looking after a miss, so visiting your Jira is all it takes.
• The stopwatch fills in the issue key from the Jira issue you were most recently looking at. This one runs continuously, not once at setup: the service worker watches tab activation and navigation for as long as it is running.
• The issue pickers — the Issue field in Log time, and the one on a row that has no issue yet — offer the last three issues you had open, before you type anything. They read the same record the stopwatch does.

What those two keep is the last twelve issues you had on screen on a site, for the four sites you most recently looked at, each as its key, the moment it was seen and the address of the site — PROJ-1043, a timestamp and https://acme.atlassian.net — in chrome.storage.session. The stopwatch uses only the newest, and not once it is fifteen minutes old; the pickers offer the newest three that are on the site you connected and are not already one of Your Seven. Session storage is held in memory rather than written to disk, and Chrome clears it when the browser closes; it is used here rather than a plain variable only because Chrome shuts the service worker down after about thirty seconds idle, which would otherwise lose a sighting before you pressed Start. None of it leaves your browser. A sighting is only ever recorded from an atlassian.net URL that contains an issue key, so a Jira tab showing a dashboard, a board, or your profile records nothing at all. The one thing it can cause is listed in the table of requests above: while a picker is open and about to offer an issue Tally has never met, Tally asks your Jira for that issue's summary and project. Nothing is asked about an issue you merely looked at, and nothing while no picker is open.

Tally still does not request tabs, which would grant this for every site in the browser and would read as "Read your browsing history" on the install prompt.

Why the wildcard, and how it is contained

The wildcard exists because Atlassian Cloud sites are per-tenant subdomains and Tally cannot know yours until you tell it. Two things bound it:

• Only one site is ever contacted. Every request goes through one function using the single stored origin. Reading tab URLs, as described above, is the only other thing the pattern buys.
• A narrower path is offered. The typed-site field in Settings → Your Jira requests one specific site instead. A wildcard granted for detection is handed back if you leave without a site stored; one that a stored site depends on, or that the install already held, is never touched, because the automatic re-detection on sync depends on it.

You can revoke either at any time in Chrome's extension settings; Tally handles the loss as a normal state and says what happened.

What Tally does not do

• No servers, accounts, analytics, telemetry, crash reporting or advertising
• No selling, sharing or transferring of data — there is nobody to transfer it to
• No remote code: no CDN scripts, no remotely hosted fonts. Everything is bundled, as MV3 requires
• No reading of any site other than the Jira site you connect
• No writing to Jira except worklogs, and only when you press a button that says so — never automatically, and never to a worklog logged by anyone but you

Exports

CSV and JSON exports are generated in your browser and saved by your browser. They are not uploaded anywhere. A file you then send to someone else is outside Tally's control — and note that a Team export contains other people's hours, so treat it the way you would any timesheet.

Removing everything

Uninstalling the extension removes all of it: the cache, the settings and the stopwatch entries. Nothing survives elsewhere, because nothing was ever sent elsewhere. To clear the cache without uninstalling, use Settings → Your Jira → Cached worklogs → Clear.

A limitation worth stating plainly

The Team view shows only what your Jira permissions return. Work on projects you cannot browse, issues under issue-level security, and worklogs restricted to a group or role are all absent, so totals there can be lower than reality. Tally states this above the numbers rather than in a footnote, because a manager acting on a total that quietly excluded three projects would be acting on a number about a real person.