Extension privacy
Browser extension privacy notice
Which browser data the Tab Organizer extension reads, what it stores on your device, what the browser may synchronise, and what does not leave your browser.
Switch to DeutschExtension privacy
Which browser data the Tab Organizer extension reads, what it stores on your device, what the browser may synchronise, and what does not leave your browser.
Switch to DeutschTab Organizer works on the tabs, windows, and tab groups in your browser. To do that it has to read the addresses and titles of your open tabs, and it stores working data on your device.
The first thing to settle is which package this describes, because two of them exist. The primary subject of this notice is the package the Chrome Web Store is distributing — the one on your device if you installed from the Store. The provider requested that package from Google's own update service on 20 August 2026, unpacked it, and read its manifest and both of its bundled scripts. Unless a passage says otherwise, the sections below describe that package. This website also documents an edition the provider builds from its own source, which Google is not distributing; where a passage describes behaviour only that edition has, it says so in those words. Which package this describes gives the inventory, the differences, and how to tell the two apart.
There is no provider-side and no network analytics or telemetry: neither package contains an analytics service, crash reporting, or advertising code, and no code path in either uploads a tab address, a tab title, or a stored record to an interface of the provider's. Two things that does not say. It does not say that nothing counts anything: the distributed package keeps an activation counter for your tabs in your browser's own storage, and the documented edition adds a dormant usage-counter schema, a panel, and a read and export path for it — a defined shape and an interface, which the build the provider inspected does not write. And it does not say that nothing derived from your tabs can reach a network: the favicon paragraph below is the concrete exception, and it is disclosed here rather than buried further down.
On the network the two packages differ, and the difference is stated rather than averaged. The distributed package contains no address belonging to the provider at all. It opens no page on this website when it is installed, it registers no address for your browser to open when it is removed, and it contains no client for any service of the provider's. The only external address its ordinary interface offers you is the voluntary donation link, and nothing follows that link unless you click it. Two further external addresses are in the package as example.com default values belonging to the dormant internal test-command surface described under which package this describes; no shipped surface offers them and nothing in ordinary use invokes them, but they are in the code and the summary says so rather than leaving the correction to a later paragraph. The documented edition does open a page on this website by itself after installation, and does register a fixed address for your browser to open after removal; network connections describes those requests and marks them as belonging to that edition.
Something touches the network in both packages without the extension asking for it, and it is easy to miss: the icons. Where the interface lists your tabs, it shows each tab's own favicon by its own web address, so displaying that list can make your browser fetch or revalidate an icon from the site the tab belongs to. That request goes to whoever hosts the icon at that address, which is normally that site and normally not the provider — but not always: an icon address that is itself the provider's, which is what a tab you have open on the provider's own website has, makes the provider's host the one that receives it. The sections on network connections, browser synchronisation, and exported session files say exactly what leaves your browser and to whom.
One more thing belongs in a summary rather than in a footnote. If you switch on "Allow in Incognito" for this extension in your browser, neither package filters private windows out of what it records. The section on private and incognito windows sets out exactly what that means.
The provider is an individual established in Switzerland. Email is the channel published here for all data protection enquiries. The applicable Swiss law is the Swiss Federal Act on Data Protection (FADP).
The provider is established in Switzerland and has no establishment in the European Union, so the General Data Protection Regulation can reach this processing only through its Article 3(2)(a) — only if the extension is offered to people who are in the Union.
The extension is published in the Chrome Web Store without country restriction and can be installed anywhere in the Union. Its interface is translated into nineteen languages, German among them. The Store description advertises that the grouping rules recognise regional sites and gives German consumer email services as its examples. This website publishes a complete German-language version of every page, including this notice. That the extension is free of charge does not matter for Article 3(2)(a).
On those facts the provider does not treat the Regulation as inapplicable. This notice is written so that it also gives the information required by Article 13, a legal basis under Article 6 is stated below, and the rights in Articles 15 to 22 are honoured for users in the European Economic Area, within the practical limits set out under your rights.
Article 27 requires a controller in this position to designate a representative in the Union unless the exception in Article 27(2) applies. At the date of this notice no representative has been designated. You can reach the provider directly at the email address above, and the supervisory authority of your country of residence or workplace remains available to you.
Two builds of Tab Organizer exist. A privacy notice that quietly described the one you do not have would be no use to you, so this section says which is which, and the rest of this notice describes the one you are overwhelmingly likely to be running.
The package the Store distributes, and what was read in it. The provider requested the extension from Google's own update service for its Store listing on 20 August 2026, unpacked what it received, and read the manifest and both bundled scripts. That artifact was 433,130 bytes with the SHA-256 digest 78bd6bfb5fe5ca921dfed71f84dbd9f973940d82b8ce85e4c2e58a06f3a9494b. The digest is published because it identifies a build exactly, which — as the last paragraph of this section explains — the version number does not. What the reading established:
tabs, storage, windows, tabGroups, system.display, alarms — and nothing else. No host permission of any kind, no side-panel permission, and no content scripts.example.com default values, and the next item is what they belong to.__e2e_. They are an automation surface for the provider's own end-to-end tests, and they were packaged with the release. Invoked, they can do what the extension can do: create or close tabs — including tabs at the example.com default addresses above — move tabs and groups between windows, switch synchronisation on, substitute a fake display layout, and return internal state. Two facts bound them, and both were checked in this package. They are reachable only on the extension's own internal message channel: the manifest declares no externally_connectable entry and the package contains no listener for messages from outside it, so no website and no other extension can call them. And nothing in the shipped interface calls them — the popup script contains no reference to any of those names — so in ordinary use they sit unused. They do not belong in a published package; removing them is a change in the extension repository and not something this website can do, and this notice discloses them because they are in the package you have.The edition this website documents, which Google is not distributing. The provider also builds an edition from its own source and prepares it for release. It is not in the Store, and this notice makes no statement about whether or when it will be — it is described here because this website documents it, not because it is promised to you. Where a passage below describes that edition it is marked, and marked behaviour is behaviour the package on your device does not have. The differences the provider has established are: a sidePanel permission; one host permission, https://votes.taborganizer.app/*, together with the community-vote client code that permission exists for; the page opened on this website after installation and the fixed address opened after removal; grouping rules, group taxonomy, context profiles and the oversized-group settings added to the synchronised set; a page activation index keyed by address that deliberately outlives the tab; up to ten recovery snapshots; and the dormant local usage-counter schema with its panel and its read and export path.
What the comparison does not cover. The two builds were compared on the dimensions listed above — manifest and permissions, surfaces, addresses and network paths, the keys written to each storage area, and the presence or absence of the named features. They were not compared line by line, so the list of differences is what the provider found and not a proof that no other difference exists. Where a later reading of either build changes an answer above, this notice is revised and the effective date at the top of this page moves with it.
How to tell which one you have. Not by the version number: both builds report the same one, and chrome://extensions shows you only that, so this notice does not pretend that page can distinguish them. What does distinguish them there is the permission list. The details page for the distributed package shows the six permissions above and no site access at all; the documented edition adds the side panel and a site access entry for the vote address. The digest above identifies the distributed artifact for anyone who wants to check a download against it. And the Store listing shows what the Store is offering now, which is not necessarily what you installed.
Most of what the extension does happens inside your own browser under your control, in the same way as a locally installed program. Where those operations are attributable to the provider, the provider is the controller — and running on your device does not by itself make an operation someone else's. Which operations the provider treats as its own, and why, is set out operation by operation under legal basis.
The provider is not the controller for the browser itself. Your browser vendor decides how the browser, its account, and its synchronisation service work, and processes data under its own privacy terms. For that processing the vendor is an independent controller and not the provider's processor: it decides on its own account where synchronised data are stored, how long they are kept, and on what basis they are transferred. The provider has no access to your browser account, cannot read your synchronised data, and cannot delete it for you.
Browser synchronisation is where those two answers meet, and the provider does not use the vendor's independence to disown its own part in it. That some of your settings are written to the browser's synchronised storage area rather than to storage that stays on the device is the provider's decision, taken in the extension's code, and so is the choice of which categories go there — the group names you type in the distributed package, and in the documented edition also grouping rules and taxonomy entries that can name sites you visit. That decision is what puts the data into the synchronisation channel in the first place, and the provider answers for it: for choosing that storage area, for the categories it selects, for telling you which they are, for stating in the synchronisation section who receives them, where that recipient says it processes them and on what transfer basis, and for telling you how to stop the transfer. What happens to the data after they reach the vendor's infrastructure is the vendor's own processing, decided by the vendor. Whether the two of them are joint controllers for the synchronisation stage would need a contractual and factual analysis the provider has not completed, so this notice does not assert joint controllership either way; it states what the provider decides and answers for, and what it does not.
Depending on the feature you use, the extension reads and processes:
Tab addresses and titles can be revealing in themselves. A single address can show what you work on, what you read, who you communicate with, and it can point at a health condition, a political or religious commitment, trade-union involvement, or your sexual orientation — the categories Article 9(1) GDPR treats as special and Article 5(c) FADP calls sensitive personal data.
Both packages also compare that material against a list. To choose a group for a tab, the extension matches the tab's address and its title against a set of domains and keywords built into the package. That is the provider's own classification of your browsing, and the section on legal basis works through what it does and does not do rather than leaving you to guess. What that section does not do is treat the absence of a copy on the provider's servers as the answer to Article 9. Where this material goes on your device is set out in the sections below.
The distributed package declares these permissions and no others:
| Permission | What it is used for |
|---|---|
tabs | Read, search, activate, move, group, and close tabs; read addresses and titles for grouping, search, statistics, and sessions |
storage | Store settings, group data, counters, and recent sessions on the device, and synchronise the settings listed below through the browser |
windows | Read, focus, create, merge, and position windows, including when restoring a session |
tabGroups | Read, create, rename, recolour, and collapse the browser's native tab groups |
system.display | Read display work areas so saved window layouts can be restored on the right screen |
alarms | Schedule badge updates and periodic cleanup of stale data |
Neither package declares content scripts, so neither runs code inside the pages you visit, and neither can read page content, form input, or passwords.
The documented edition adds two entries, and both are named here rather than folded into the table above. It declares sidePanel, so that the interface can be shown in the browser's side panel when you choose that as the host. And it declares one host permission, https://votes.taborganizer.app/*, for the community vote described under network connections; in the build the provider examined that permission is unused, because no code path in it contacts that address. The distributed package declares neither.
The extension writes to your browser's local extension storage. In the distributed package this includes:
The distributed package also uses the browser's session storage area for one short-lived record: which tab groups the extension created itself, each entry with an expiry time. Your browser clears that area when the browser session ends.
Only in the documented edition. Google is not distributing the following, and the package on your device does not have it:
A page activation index. Instead of an entry per tab, this edition stores the address without its fragment — including any query string — together with an activation count, the last activation time, and when the entry was first seen. This index deliberately survives closing a tab, so that suggestions stay stable. It is emptied when you restore a session, and otherwise stays until the extension is removed.
Your grouping rules and group taxonomy, including rule patterns you write. A pattern can be a domain, a hashed domain, an address, a page title, a wildcard, or a regular expression, so it can itself describe sites you visit. These are also written to synchronised storage in that edition.
Context profiles and which one is active, with the profile names you choose. Each profile holds its own copy of your rules and taxonomy.
Recovery snapshots: up to ten, and they are a second set of complete captures rather than part of the five recent sessions. Their purpose is that an action which replaces your state cannot lose it without a way back: a snapshot is written first, and only if writing it succeeds does the action run. The actions that trigger one are restoring or loading a session, adopting a synchronised state, dissolving a group or ungrouping everything, the close-all-but-active cleanup, and importing migrated data. A snapshot holds, for every window, its tabs' addresses, titles and favicon addresses, whether each tab is pinned, the tab groups with their names and colours, the address of the active tab, the window position, size, state and focus, which display it belongs to and your display layout — together with the time it was taken, which action it belongs to and that action's own parameters, a generated identifier, and how many tabs and windows it holds. A snapshot is not deleted after you restore from it: the eleventh displaces the oldest, and the whole set goes when the extension is removed.
A dormant local usage-counter schema, panel, and read and export path. This edition carries a review-prompt feature for which a counter record is defined in local storage, together with the interface that would display it. What exists in the build the provider inspected is the schema, the panel, and the read and export path — and no production writer creates or updates the record: the component that would increment the counters is never instantiated by the background bootstrap, and the two messages the interface sends when the popup opens and when a synchronisation error is shown have no registered handler, so they have no effect. The read path returns zeros when the key is absent. So a fresh installation of that edition on the inspected build does not create the record and does not persist those counts. A schema, a panel, and a fallback read path are not a record in local storage, and this notice does not describe them as one.
What such a record would hold, if one already existed on your device or if a future build wrote it, is set out so that nothing is hidden behind the word "dormant": how many times the popup was opened and when it last was, the calendar days on which the extension was used and how many distinct days that is, a rolling daily and seven-day active-day figure, when the extension was first seen and under which install reason, how many synchronisations succeeded and when the last one did, when synchronisation was first enabled, when a synchronisation error was last shown to you, and counts of saved sessions and duplicate cleanups. The dormant writer would drop day keys older than 90 days — but only when runs, and on the inspected build nothing calls it, so there is no active writer and therefore no pruning path that runs at all. The read and export path the panel uses reads whatever key list it finds and does not prune it. Ninety days is accordingly what that code would enforce in a build that actually invoked the writer, and not a retention limit this notice can state for the inspected one. Those would be integers and timestamps; the shape holds no address and no page title, and no code path transmits it anywhere. The panel is called "Privacy & local metrics", names the record, says it exists to time a review request after positive use, and offers it to you as a JSON export; on the inspected build it reads zeros. Whether a record written by some other build could survive an update is not something the provider can establish from that build, and it does not claim either way. The same goes for how long such a record's day keys would then last: with no writer running, nothing prunes them, so their survival and their retention are unestablished. What is established is the endpoint — removing the extension deletes the extension's local storage, as deleting your data describes. On any reading what is at stake is a set of counts in your own browser, not a transmission.
There is no single deletion period for all of this. The data are kept while you use the extension, subject to the limits above, and are removed when the extension is removed, as deleting your data explains. None of these records is uploaded to an interface of the provider's — subject to one disclosed exception that runs the other way: a favicon address stored in a session can be rendered, and rendering it makes your browser request that address from its host, which in the case described under network connections can be a host the provider controls. So the accurate statement is that the extension does not upload its stored records or your tab addresses and titles to the provider, not that nothing stored can ever produce a request.
Your browser decides whether this extension sees a private window at all, and so do you: an extension has no access to incognito windows unless you switch on "Allow in Incognito" for it under chrome://extensions. That switch is off by default. While it is off, nothing in this section applies to you.
If you switch it on, this is what both packages do, stated plainly because it is not what the switch invites you to assume. Neither declares an incognito value in its manifest, so Chrome applies its default, spanning: a single extension process serves your ordinary and your private windows together. Chrome marks the tabs and windows of a private session with an incognito property, and Chrome's own documentation states that chrome.storage.local and chrome.storage.sync are shared between the regular and the incognito context. There is no separate private store for an extension to write to.
The extension does not test that property before it records. The events that create and update the activation record are handled without distinguishing a private tab from an ordinary one. The queries that read your open tabs and windows — for a session capture, and in the documented edition for the activation index at start-up and for a recovery snapshot — are not restricted to non-private windows; the window query these paths use asks for the "normal" window type, which is a window type and not the opposite of private. The distributed package does copy a window's private flag into the descriptor it builds for a capture, but it does not use it to leave anything out. So a private tab's address can sit in ordinary local storage while that tab exists, a session capture taken while such a window was open can contain its tabs, and in the documented edition, where the activation index is keyed by address and deliberately outlives the tab, an address first seen in a private window can remain in ordinary local storage after that window is gone.
Chrome's guidance for extension authors is that an extension which saves browsing history should not save history from incognito windows and should check the incognito property. Neither package implements that check. This notice says so instead of describing a filter that is not there, and it makes no promise about behaviour it cannot show you in the product.
What you can do about it. Leaving "Allow in Incognito" switched off is the browser's default and keeps private windows out of the extension altogether. If it has been on, removing the extension deletes its local storage entirely, as deleting your data describes; there is no separate control that removes only the entries a private window produced, because nothing marks them as such.
Some settings are written to chrome.storage.sync instead of local storage. If you are signed in to your browser and synchronisation is switched on, the browser vendor transmits those settings through its own infrastructure to your other browser installations.
In the distributed package the settings written to synchronised storage are:
In the documented edition that set is larger and also includes your group taxonomy with its display names and any extra domains you assign to a group, your grouping rules, your context profiles and which one is active, and the settings for splitting oversized groups.
What deserves attention in each case is the same point, so it is made for both. A group name is a string you type, and a string you type can be as revealing as anything else you write down. Grouping rules and the extra domains in a taxonomy can contain the names of sites you visit. Either way, what the provider selected for this channel is data that can name your interests, and it is therefore part of what the browser vendor's synchronisation service carries. Your open tabs, the activation record, the domain-to-group assignments, and your recent sessions are not written to synchronised storage in either package, and neither are the recovery snapshots or the usage-counter schema of the documented edition.
Who decides what, and who receives it. Putting these settings into the synchronised area is the provider's decision, as the section on responsibility says, and the list above is the provider's disclosure of what that decision hands over. What then carries them is the browser's own service: Chrome's official documentation for the storage API states that items in the sync area are synchronised using Chrome Sync and that, when you have syncing enabled, they are synchronised to every Chrome browser you are signed in to, and Google's own documentation for signed-in Chrome describes such data as saved in your Google Account.
So for Google Chrome the recipient is Google, processing that copy for its own account and under its own terms. Because the disclosure into that channel is the provider's own decision, the provider states what that disclosure means rather than sending you away to work it out. The following is taken from Google's own published documents, read on 20 August 2026:
If you use another Chromium-based browser, the recipient is that vendor and its own published terms apply; Google is named here because Chrome is the browser this extension is distributed for, and this notice is revised before another browser is supported. The provider has no access to the synchronised copy, cannot read it, and cannot delete it for you.
What you can do about it, and the two controls do not do the same thing. Switching off extension synchronisation in your browser, or using the browser without signing in, is what keeps this data on your device: the same storage area then behaves like local storage, and nothing enters the synchronisation channel. If you would rather these settings did not travel at all, that is the control to use, and it is the only one that achieves it.
A custom synchronisation passphrase is a different thing and does not stop the data travelling. Google's help page for the feature, read on 20 August 2026, describes it as follows: with a passphrase "you can use Google's cloud to store your Chrome data without letting Google read it." The same page states that when you change your passphrase, the data encrypted by it are deleted from Google's servers. Both sentences say the same thing from opposite sides: with a passphrase in place the synchronised data are still uploaded to Google's infrastructure and still stored there, and what the passphrase does is encrypt the content so that — on Google's own statement — Google cannot read it. That is a safeguard against the recipient reading the content, not a way of keeping the content off the recipient's systems. In the Regulation's terms it changes nothing about whether processing occurs: Article 4(2) GDPR counts storage and "disclosure by transmission" as processing, whether or not the recipient holds the key. An earlier version of this notice presented the passphrase as one of two controls that would stop the settings travelling. That was wrong, and the correction is this paragraph rather than a quiet deletion.
The extension does not offer a per-category synchronisation switch of its own, and that too is the provider's design decision rather than a limitation of the browser.
Exporting a session writes a .tabsession file to the location you choose. Session files are not encrypted and are plain, readable JSON. A file can contain the address and title of every tab included, favicon addresses, group information, window and display geometry, the capture time, and the platform.
The file includes a field named checkmark. It holds a value computed by hashing the tab addresses in the session together with a fixed string built into the extension. It is an unused checksum-like field retained in the file format, and it gives you no assurance of any kind: not confidentiality, because it is not encryption and the rest of the file is plain text; not integrity, because nothing recomputes it; not authenticity or provenance, because the fixed string is in every copy of the extension, so anyone can produce or replace the value for any file they like. Import validation accepts any string in that field up to a length limit and never compares it against the file's contents. Do not treat its presence as telling you where a file came from.
Anyone who can read the file can read your browsing structure. Look at a session file before you share it, store it as carefully as the tabs it contains, and delete it separately when you no longer need it. The extension never sends exported files anywhere; only you move them.
A capture covers the windows that were open when you took it, and it does not exclude a private window: if you have allowed the extension into incognito, an exported file can contain private tabs, as the section on private and incognito windows explains.
Importing runs the other way, and a file you did not write is untrusted input. The favicon field of a session is an address, and nothing requires it to belong to the sites listed in the file; where such an icon is displayed, your browser contacts whatever server that address names, as described under network connections. Import session files only from a source you trust, and read an unfamiliar file before importing it.
Neither package bundles an analytics or telemetry service, an advertising library, or a crash reporter; neither loads remote code; and neither opens a connection to an interface of the provider's in order to do its work. There is no provider-side and no network analytics or telemetry of any kind — nothing measures your use of the extension anywhere other than in your own browser's storage. Measuring does happen there, and the accurate claim is the narrower one: the performance counters are integers held in memory for internal budget checks, the activation record described under what is stored on your device holds counts and timestamps in local storage, and the documented edition adds the dormant usage-counter schema, panel, and read and export path described in the same section, which the inspected build does not write. None of them is transmitted, and no code path exists that would transmit them.
What follows is what the provider has found and what it therefore discloses. It is a list of the network paths it knows about, not a proof that no other path exists: an absolute claim of that kind cannot be established by reading code for connection calls, as the favicon entry below shows.
Favicons displayed in the interface. The extension does not ship the icons it shows next to your tabs. It takes the icon address the browser reports for a tab — normally an address belonging to the site that tab points to — and puts it in an image element, and your browser loads it from there. Your browser may satisfy that from its cache; it may equally retrieve or revalidate the icon over the network. Where it does, the request goes to whoever hosts that icon, and they receive what any request for an image carries: the IP address of your connection, the time, the address requested, and the browser and operating-system information your browser sends. The recipient is the host named by that icon address. Normally that is the site whose icon it is, or a service delivering the icon for it, and normally it is not the provider — but "normally" is as far as this notice goes, and it does not say "never". The address comes from the tab, so where the tab is open on the provider's own website the address is the provider's own: https://www.taborganizer.app/favicon.ico is served by the provider's host. In the distributed package that happens when you have such a tab open yourself; in the documented edition it also happens because that edition opens a page on this website after installation and another after removal. Either way, while such a tab is listed, rendering its icon is a request the provider's host receives, with the same metadata as any other host would get. An imported session file can do the same deliberately: its icon address is arbitrary and can be aimed at the provider or at anyone else. Two further consequences are worth naming. First, such a request can tell that site that its icon was rendered at that moment, which for a tab you have open is a fact about how you are using your browser. Second, the icon address in a session file is not verified against anything: the file format accepts any web address in that field, so an imported session you did not create yourself can point an icon at a server of the file author's choosing. Treat session files from other people as untrusted, as the section on session files says. Neither package declares a content security policy of its own restricting where images may be loaded from, so neither blocks this; what limits it is your browser's cache and which lists you open.
Links you click. The interface of the distributed package contains a voluntary support link to an external donation site; the documented edition adds links to the Chrome Web Store listing and to the documentation. Following a link is your action, and the destination site then applies its own privacy terms and sees the same ordinary request metadata.
Pages this website's documented edition opens — not in the distributed package. The distributed package contains no address on this website and opens no page here, in either direction. In the documented edition, after a fresh installation the extension opens the setup guide in an inactive background tab, and after removal the browser opens the feedback page. The two addresses are not alike, and the difference is stated rather than averaged. The install address is chosen by language: the extension reads your browser's user-interface language and requests the German path for German settings and the English path otherwise, so that request carries the coarse fact that your browser is set to German or to something else, which the receiving host sees together with the request metadata. The removal address is fixed and locale-free — — and this website resolves it to the English page for everyone; German is reached only if you then follow a language link, which stores nothing. Neither address carries a query string or a fragment, and neither carries a version, an installation identifier, a tab count, or any other state. Each is a request to the provider's host, which receives what any web request carries: your IP address, the date and time, the requested path, the method and the status returned, the amount of data transferred, browser and operating-system information from the user-agent string, and a referring address if your browser sends one. Because the fresh-install page opens by itself, that first request is an event that correlates in time with the installation. The website privacy notice describes how those requests are handled, by whom, and for how long.
The extension processes browser data in order to provide the functions you invoke. Swiss law does not ask for a legal basis for every operation in the way the GDPR does: processing by a private person is permitted unless it unlawfully infringes the data subject's personality (Article 30(1) FADP), and where it does, Article 31 asks for a justification. For the functions you invoke, what governs is the purpose you invoked them for and the principles in Article 6 FADP; no consent is collected for them and none is relied on. Two questions need more than that paragraph — sensitive personal data, and the disclosure to your browser's synchronisation service — and both are answered below rather than settled here.
Where the GDPR applies, the basis is Article 6(1)(f), and it is not Article 6(1)(b). An earlier version of this notice relied on Article 6(1)(b) for the core functions, describing it as "processing necessary to provide the functionality you requested", while the Swiss analysis below relied on no contract at all. A basis that exists only where there is a contract cannot be combined with a refusal to identify one, and the second position is the one the provider can support, so Article 6(1)(b) is gone.
Article 6(1)(b) is not a general basis for requested functionality. It applies only where the processing is objectively necessary to perform a contract to which you are party, or to take steps you requested before entering into one, and a controller cannot bring it into play by writing processing into its terms. The provider has not established a contract between you and it, does not rely on one, and does not rely on objective contractual necessity for any of the operations described here. The facts it can state are these: the extension is free, no account is opened, no order can be placed, and nothing is purchased. Two things that sentence deliberately does not say. It does not say that installing a free extension could never form a contract — under Article 1 of the Swiss Code of Obligations the conclusion of a contract requires a mutual expression of intent by the parties, that expression "may be express or implied", and the provision makes no payment a condition — so whether a contract arose in an individual case is a question of formation, and this notice does not decide it either way. And it does not overlook the legal notice on this website, which is framed as terms of use: it asks you not to use the product if you do not accept them, states a right to use, sets out use you must not make, allows that right to be withdrawn, chooses law and jurisdiction, and says that continued use after a change means the amended terms apply. Those provisions may purport to bind. Whether they were effectively incorporated and accepted by you is not something this notice establishes, and it neither denies them nor treats them as proof that a contract was concluded. What it says is the narrower thing: the provider has not established such a contract and builds no legal basis on one. This notice does not manufacture a contract in order to gain a legal basis, and it does not treat installation as consent either. The Swiss analysis stays consistent with that position: it does not rely on Article 31(2)(a) FADP, for exactly the reason it does not rely on Article 6(1)(b) GDPR.
So the general Article 6 layer for the extension's functions is Article 6(1)(f) — the provider's legitimate interests — and it is allocated below operation by operation, with the interest each one serves, why the operation is necessary for it, and what the balance against your interests and fundamental rights rests on. Consent under Article 6(1)(a) carries nothing at present: none is asked for and none is obtained anywhere in either package. If the community vote is ever offered, it will run on consent, which is why it will be off until you switch it on and withdrawable by switching it off again.
Data that can reveal a special category. Tab addresses and titles can reveal matters that Article 9(1) GDPR treats as special categories, as the section on what the extension reads says. The provider does not answer that with Article 6 alone, and it does not rest the answer on the fact that it holds no copy of your tab data. An earlier version of this notice did rest on that fact. It was wrong to, and the reasoning below replaces it.
What the law asks, read directly rather than summarised from commentary. Article 9(1) prohibits processing personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade-union membership, and processing health data or data concerning sex life or sexual orientation, unless one of the conditions in Article 9(2) applies. Article 4(2) defines processing to include recording, storage, retrieval, consultation and use, so an operation performed entirely on your own device is processing. Article 4(7) makes the controller the party that determines the purposes and the essential means of an operation. In Meta Platforms and Others (Case C‑252/21) the Court of Justice held that the prohibition applies wherever the processing allows information falling within one of those categories to be revealed — irrespective of whether the controller was aiming to obtain it, irrespective of whether an inference drawn would be correct, and irrespective of the stated purpose of the processing (paragraphs 68 to 70). The facts before the Court were collection by a social network operator on its own systems, linked to accounts it held (paragraph 71), but the test it stated is not confined to those facts. In Jehovan todistajat (Case C‑25/17) the Court held that a party can be a controller for processing to which it has no access at all: a religious community was a joint controller of the data its members collected while preaching, "without it being necessary that the community has access to those data" (paragraphs 68, 69 and 75). The European Data Protection Board states the same in its Guidelines 07/2020 — actual access by the controller is not necessary (paragraph 45), and controllership can attach to a single operation rather than to a whole chain (paragraph 43), with the data categories, the retention and the recipients counting as essential means (paragraphs 42 to 45). Possession is therefore not a condition of Article 9, and this notice does not treat it as one.
Which operations are at issue, and who determines them. Four have to be kept apart, because they do not have the same answer.
politics under news, and the localised lists for several of the translated languages carry their own equivalents of it, mostly under news as well — so a page whose address or title contains one of those words can be sorted by it. Beyond those entries the classification does not sort your tabs by health, belief, religion, trade-union involvement or sexual orientation, and a clinic's website is treated exactly like a newspaper's. What the provider does not claim is that any of this puts the operation outside Article 9(1): on paragraphs 68 to 70 of C‑252/21 what matters is whether the processing allows such information to be revealed, not whether the provider wanted it to, and reading and matching an address that names a clinic plainly can.Which legitimate interest carries which operation, and on what balance. Article 6(1)(f) needs three things for each operation, not one for the group: an interest, the necessity of that operation for the interest, and a balance in which your interests and fundamental rights do not override it. They are set out one operation at a time, and where the balance is uncomfortable this notice says so instead of averaging it away.
You may object to processing that rests on Article 6(1)(f) under Article 21(1), and the email address above is where to do it. One consequence is stated plainly rather than left for you to discover: because these operations run inside your own browser, an objection the provider upholds is carried out through the controls described under deleting your data, which are yours — the provider cannot reach into your device to stop an operation there, and it will say so rather than promise otherwise.
What condition applies, and what is missing. For operations 1, 2, 3 and 4 the general basis is Article 6(1)(f), allocated and balanced above. Every one of them needs an Article 6 basis, and none of them is left without one: Article 9 does not replace that layer. Where an operation falls within Article 9(1), a condition under Article 9(2) is required in addition to the Article 6 basis and not instead of it — the two requirements stack, and satisfying one does not dispense with the other. On that additional requirement the provider states plainly what it does not have: no explicit consent under Article 9(2)(a) is asked for, given, or obtained anywhere in either package. Installing an extension from a store is not explicit, purpose-specific consent to special-category processing, and asserting a consent that is never collected would make this notice untrue rather than compliant. Article 9(2)(e) is not invoked either: on paragraphs 74 to 79 of C‑252/21 visiting a site does not make the visit manifestly public, and the Article 9(2) derogations are to be construed strictly. None of the remaining conditions — employment and social security, vital interests, a not-for-profit body's own members, legal claims, substantial public interest, health care, public health, or archiving, research and statistics — describes organising a person's own browser tabs. So for an operation attributable to the provider that does fall within Article 9(1), the provider has identified no Article 9(2) condition. That is the honest position and this notice states it, rather than implying that no condition could ever be needed. What the provider does put beside it is the set of facts under operation 1: the processing runs on your device, on data your browser already holds, at your request and for the purpose you invoked; nothing is aggregated off the device; there is no evaluation by the provider and no dataset in its hands; and the controls under deleting your data are yours. Those facts bear on how serious the exposure is. They are not an Article 9(2) condition and are not offered as one. If you consider a particular operation to be Article 9 processing attributable to the provider, write to the address above; it will be assessed individually, and the answer will not be that the question cannot arise.
Operation 3 carries the same Article 6 basis as the other three — Article 6(1)(f), balanced above, on the interest, necessity and balance stated for it — and it is the additional Article 9(2) condition that is likewise missing there. The position is weaker rather than stronger, because a disclosure to a third party is involved. What the provider can do without inventing a fact, and does, is disclose it fully: which categories go into the channel, who receives them, in which states, on what transfer basis, and the one control that prevents the disclosure — switching off extension synchronisation, or using the browser without signing in. That control, and its limits, are in the section on browser synchronisation, which also states what a custom passphrase does and does not do: on Google's own description it stops Google reading the synchronised content, and it does not stop the content being transmitted to and stored on Google's infrastructure, so it is not a way of preventing this disclosure. An earlier version of this notice counted it as one, and that error is corrected here as well as there. The extension offers no per-category switch of its own, and that is the provider's design decision.
Under Swiss law. Article 5(c) FADP defines sensitive personal data to include data on religious, philosophical, political or trade-union views or activities and data on health, the intimate sphere, or racial or ethnic origin. Article 6(7)(a) requires consent to be express where consent is the basis for processing such data; the provider collects no consent of any kind, and therefore relies on none. Article 30(2)(c) treats disclosing sensitive personal data to third parties as a breach of personality unless Article 31 justifies it, and the disclosure that matters here is operation 3 — the categories the provider writes into the browser's synchronisation channel, which can contain a group name or a rule that is sensitive within Article 5(c). The provider therefore states its Article 31 position rather than passing over it. It does not rely on your consent, because none is collected. It does not rely on Article 31(2)(a), because the provider has not established a contract between you and it and relies on none — the same position that removes Article 6(1)(b) GDPR from this notice, and for the same reason. What it relies on is the general ground in Article 31(1), an overriding private interest, and it names the interest and its limits rather than asserting the conclusion: the purpose is to carry the group settings you created to your other browser installations, which is a function you switch on in your browser and can switch off there; the categories written are the smallest set the feature needs, which in the distributed package is the group names and their colours; nothing goes to anyone other than your own browser vendor, for your own account; and one control — switching off extension synchronisation, or using the browser without signing in — prevents the disclosure from happening at all. A custom synchronisation passphrase does not, and the account here does not pretend that it does: with a passphrase the settings are still transmitted to and stored on Google's infrastructure, and what Google says the passphrase changes is whether Google can read them. Whether that interest overrides yours is decided on those facts and not by this notice asserting it, and if you consider that it does not, Article 32(2) FADP lets you demand that the disclosure stop — and the control above lets you stop it yourself immediately. For your tab addresses and titles there is no disclosure to the provider to justify under Article 31, because the extension makes none.
The affirmative Limited Use statement. The Chrome Web Store Limited Use policy requires an affirmative statement, on a website belonging to the extension, that the developer's use of the data complies with the Limited Use restrictions. This is that statement, made without hedging: the provider's use of information received from Google APIs, and of all user data the extension can access, adheres to the Chrome Web Store Limited Use requirements. Concretely, data the extension can access are used only to provide and improve its disclosed single purpose of organising tabs, windows, and sessions, together with the operational purposes that belong to it. They are not sold or rented; they are not transferred to data brokers, advertising platforms, or other information resellers; they are not used for personalised advertising; they are not used to determine creditworthiness or for lending purposes; and they are not used to build profiles for any other purpose.
The policy's remaining restriction concerns humans reading user data, and it is answered here with the facts rather than with a slogan, because the facts are not uniform. The extension uploads no tab address, no tab title, no complete session capture and no stored record to the provider: there is no transmission of that material to the provider and therefore no copy of it there for anyone to read, which is a property of how the product is built rather than a promise about conduct. One qualification belongs with that sentence instead of being left out of it, and it is the favicon address: an icon address is a stored field, and rendering it can transmit the address, as the next paragraph sets out. What the provider does receive is narrower and is disclosed rather than denied. Requests reach the provider's host in the cases set out under network connections: rendering a stored favicon address that points at this website, and, for the website-documented edition only, the page opened after installation and the page opened after removal. Each of those requests carries the ordinary metadata any web request carries — the IP address of your connection, the time, the path, and the browser and operating-system information your browser sends — and the provider's hosting processor receives and logs it on the provider's behalf, as the website privacy notice sets out under hosting. That is processing for which the provider is responsible.
The accurate statement therefore has to exclude the favicon case rather than cover it over. A rendered favicon can transmit the requested favicon address and the ordinary request metadata that goes with it, and it does not transmit the complete tab, session or storage record. The requested path, and any query string it carries, is itself part of the favicon field your browser reported for a tab or that a session file supplied, so a part of that stored field does reach the host — and where the address names this website, that host is the provider's. The transmission in that case is your browser's request for an image rather than an upload by the extension, and this notice does not use the distinction to deny it: what the provider's host and its hosting processor receive is stated in the paragraph above. What does not reach them is the record the field sits in — not the tab's address, not its title, not the complete session capture, and not the stored record. So the provider receives no copy of your complete tab, session or storage record. That is narrower than what two earlier versions of this notice said: the first denied any copy at all, and the second denied any copy of tab, session and storage data. Both were wider than this notice's own network section, and both are corrected here.
The policy publishes an example formulation for that statement: "The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements." The provider makes the Limited Use commitment in the first paragraph of this section, and states openly why it does not adopt the wider half of that example sentence. That half would be a claim of compliance with the User Data Policy as a whole, and the provider does not make that claim while its own Store dashboard declaration is inaccurate. The two positions are separate and both are true: the extension's actual data use adheres to the Limited Use restrictions, and the provider does not certify its own compliance with the User Data Policy overall. The next paragraph is why.
The Store listing carries a short data-use declaration, and at the date of this notice that declaration and the listing text read more absolutely than the facts above. The listing says that the extension runs locally in your browser, with no account, no tracking, and no collection of data at all, and the Store's developer declaration states that the developer will not collect or use your data. This notice, by contrast, discloses that the extension reads your tab addresses and titles, classifies them against a built-in list, keeps an activation record and up to five session captures in your browser, writes group names and colours into the browser's synchronisation channel, does not exclude private windows where you have allowed it into them, and can cause a request for a stored favicon address. Chrome's own User Data FAQ is explicit that local-only handling and use of chrome.storage.sync still require disclosure, and that a discrepancy between a product's behaviour, its dashboard disclosures and its privacy policy is itself a policy problem. The provider does not resolve that by certifying compliance in this notice while the discrepancy stands. It states the position instead: this notice is the accurate description, the Store's short-form declaration understates what the extension does, and correcting that declaration on the Store dashboard is the provider's own outstanding task. If you find a statement in the Store listing that reads more absolutely than this notice, this notice is the one to rely on.
The extension has no user account, no login, and no authentication against a provider service. It assigns no installation identifier, no device identifier, and no advertising identifier. It does not process payments; no purchase can currently be made, and no payment service is embedded. There is no advertising code and no advertising recipient.
The heading is deliberately qualified, and so is the claim under it. What is absent is provider-side tracking: neither package contains analytics, telemetry, or advertising code, and no code path reports your use of the extension to an interface of the provider's or to any measurement service. What this notice does not say is that no signal about your use can reach anyone else, because two disclosed paths defeat that. The browser's synchronisation service carries the settings listed under browser synchronisation to your browser vendor. And a request for a stored icon address can tell the host of that address that its icon was rendered at that moment, as network connections explains. Neither is provider analytics; both are real, and an absolute here would be contradicted by this notice's own disclosures three sections up. What is present, and is described under what is stored on your device, is record-keeping in your own browser — the activation record with your tabs' addresses in it, up to five session captures, and in the documented edition the address-keyed activation index and the dormant usage-counter schema. An unqualified "no tracking" would not be true of a product that keeps those, so this notice does not say it.
Of the four categories above — the locally stored data, the session-scoped record, the synchronised settings and your exported session files — the provider holds no complete record, so it cannot delete them on your behalf. One exception belongs here rather than out of sight: where a stored favicon address points at this website, the request your browser makes for that icon reaches the provider's host, and its hosting processor logs the requested favicon path together with the ordinary request metadata on the provider's behalf. That log is none of the four categories above, and none of the controls above reaches it; what is kept in it, by whom, and for how long is what the website privacy notice sets out under how long data are kept.
Under Swiss law, and where the statutory conditions are met, you can ask whether personal data about you are processed and request the information the law requires (Article 25 FADP), request that inaccurate data be corrected (Article 32(1) FADP), object to processing that rests on the provider's overriding interest, and bring an action for the protection of your personality in which you may ask that a processing operation or a disclosure be prohibited or that data be deleted or destroyed (Article 32(2) FADP).
Article 28 FADP gives a right to have the personal data you provided released to you in a common electronic format, and transferred to another controller, where the provider processes them by automated means and either with your consent or in direct connection with a contract between you and the provider. Those conditions are what decides the question, and the provider does not substitute a shorter answer for them. In particular, the fact that data sit in your own browser rather than on a server does not by itself put a category outside the right: where processing is attributable to the provider, the provider is the controller for it, as the section on responsibility says, and the implementing ordinance counts data the controller has collected about you and your behaviour while you use a service or a device as data you disclosed (Article 20(1)(b) DSV), while data the controller generates by its own evaluation of supplied or observed data fall outside it (Article 20(2) DSV). Which of the two conditions is ordinarily in question is named rather than left for you to work out: no consent is collected for the extension's functions, and the provider has not established a contract between you and it and relies on none — the same position that removes Article 6(1)(b) GDPR from the legal-basis section. On that footing the second statutory condition is ordinarily not met, which is the same reason the website notice gives for its request logs. The provider does not settle that condition against you by declaring it: whether a contract exists between you and it is a question of contract formation, not something this paragraph decides, and if you say that one does, that is assessed on its own facts rather than answered by this sentence. What is stated here is the provider's position on the statutory test, not a refusal in principle.
What is true, and is the practical answer for most categories, is this. Your settings, group names and colours, sessions and activation record — and in the documented edition your rules, taxonomy, recovery snapshots and any usage counters — sit in your browser's own storage and in your browser account, and insofar as they remain only in the browser or the browser account, the provider holds no complete record of them that it could release. That is not a claim that no part of them ever reaches the provider, and the exception is stated here rather than saved for the end of the paragraph: a request for a provider-hosted favicon can place the requested favicon path — itself part of a stored favicon field — and the ordinary request metadata that goes with it in a log the provider's hosting processor holds on its behalf. For those categories as they stand in your browser, the deletion section says how to reach them, and the export function already hands you your sessions in a common electronic format. If you want a specific category assessed against Article 28 rather than described — the activation record, a session capture, a recovery snapshot, or any other — ask; it will be assessed on those conditions individually rather than refused in principle. The requests your browser makes to this website are a separate matter, and the difference between the two packages is narrower than an earlier version of this paragraph stated. The Store-distributed package makes no automatic installation or removal page request: it opens no page here after a fresh installation and none after removal, and it contains no address on this website at all. Both packages can make the provider-hosted favicon request described under network connections, whenever a tab you have open or a session you imported carries a favicon address on this host, and the documented edition adds the installation and removal pages on top of that. Where such a request happens, the provider's hosting processor receives and logs it on the provider's behalf, and the rights that attach to that log — access under Article 25 FADP, release and transfer under Article 28, and the corresponding GDPR rights — are the ones the website privacy notice sets out for request data, on the statutory conditions and on individual assessment. This paragraph routes them there rather than answering them by saying that no such request exists.
Where the GDPR applies, the rights of access, rectification, erasure, restriction, objection, and data portability under Articles 15 to 21 apply, as does the right to withdraw a consent under Article 7(3).
Write to the email address above. Please note the practical limit, and note what it covers: for the records that exist only on your device or in your browser account, the provider does not receive them, keeps no account for you, and cannot identify you from them, so for those it can only explain how to reach them — the controls described under deletion are yours, not the provider's. The limit stops there. It does not extend to the request logs described above: where a provider-hosted favicon request has been made, its hosting processor holds the log of that request on the provider's behalf, and the rights attaching to that log are the ones the website privacy notice sets out for request data.
The Federal Data Protection and Information Commissioner supervises private controllers in Switzerland. You may report a processing operation to the Commissioner if you believe it breaches data protection rules; the Commissioner opens an investigation where there are sufficient indications of a breach and informs you of the steps taken and the outcome if you made the report (Article 49 FADP). That is a supervisory procedure in the public interest and not a claim that awards you a remedy; claims against the provider are asserted directly and, failing that, in the civil courts.
Where the GDPR applies, you may in addition lodge a complaint with the supervisory authority of your country of residence, your place of work, or the place of the alleged infringement under Article 77, and you have a right to an effective judicial remedy under Article 79. Complaints about the browser or its synchronisation service belong with your browser vendor and the authority competent for it.
The extension is a tab-management tool for people who work with many browser tabs. It is not directed at children, and the provider does not knowingly process personal data of children.
This notice is updated when the permissions, storage, synchronisation, or network behaviour of either package changes, and when a fresh reading of the distributed package changes an answer given above. The current version and its effective date are shown at the top of this page.
checkmark field. Neither manifest declares an incognito key, so Chrome's spanning default applies to both. And both match a tab's address and title against the same list of domains and keywords built into the package in order to choose a group.recordPopupOpen()https://www.taborganizer.app/uninstallThe community vote — in the documented edition only, and present there as code rather than as a reachable feature. The distributed package contains no vote client and no reference to that address whatsoever. In the documented edition the extension contains the client code for a feature that would let you assign a category to a site. Its payload would consist of a one-way SHA-256 hash of the site's registrable domain and a category key; addresses, host names, titles, tab or window identifiers, and any user identifier are rejected before sending. No interface offers the feature, and the code path that performs the network call is reachable only through the automated-test bridge, which the release build replaces with a no-op. Nothing is therefore sent to votes.taborganizer.app, and the host permission declared for it is unused.
Before that changes, this notice will be revised to state the complete payload; the connection metadata the receiving service necessarily sees, which includes the source IP address, the time, and the extension version sent in a request header; who operates that service and in which country; the legal basis; the retention period; and how to have an entry deleted. It will also say plainly that a hash of a registrable domain is a pseudonym and not anonymous data: the set of registrable domains is small enough to hash candidate names and compare them, so such a value can be linked back to the site it stands for.