1. Scope and responsibilities
URLises is designed to synchronize selected URLises workspaces with a managed bookmark tree in Chrome. The extension maintainers control the extension's client-side behavior. They do not necessarily operate the backend selected by a user.
The operator of the configured URLises server controls what happens on that server, including account administration, server logs, storage, backups, retention, deletion, access controls, and the server's own legal or privacy obligations. For a self-hosted deployment, that operator may be the user or the user's organization.
Back to top2. Data the extension processes
Depending on the configured backend, account, and selected workspaces, the extension processes the following data.
Account and workspace data
- User identifier, email address, and display name.
- Organization and workspace identifiers and names.
- Organization or workspace memberships, access sources, and roles.
Bookmark and folder data
- Bookmark URLs and titles.
- Folder names.
- Folder and bookmark hierarchy, parent relationships, positions, and identifiers.
- This data only for the selected URLises workspaces represented inside the managed URLises bookmark tree.
Configuration and device data
- The user-configured backend URL.
- A randomly generated client/device identifier used to distinguish the extension installation when communicating with the backend.
- The device name entered at sign-in (or the default
URLises for Chromelabel), which is sent to the configured backend. - Selected workspace identifiers.
- Local mappings between Chrome bookmark identifiers and backend bookmark or folder identifiers.
Authentication and local session data
- The user enters an email address and password to sign in. The password is submitted directly to the configured backend for login and is not stored by the extension.
- The refresh token returned by the backend is stored in
chrome.storage.local. - The access token is held in the extension service worker at runtime and in
chrome.storage.session. - A short-lived WebSocket ticket is obtained from the configured backend and used at runtime to open a real-time synchronization connection.
- Redacted session and profile metadata is stored in
chrome.storage.local; the access token is removed from that stored profile record.
Authentication tokens are credentials. They are not anonymous data and should be protected accordingly.
Synchronization, recovery, and diagnostic data
- Synchronization cursors, event identifiers, origin client identifiers, timestamps, and last-synchronization times.
- Workspace and bookmark/backend mappings, selected-workspace projections, operation state, recovery state, health and connection status, and retry information.
- Local status and diagnostic entries, which may include account or workspace context and synchronization or error details.
3. How the data is used
The extension uses this data only to provide and support its current functionality:
- authenticate the user and renew or end the extension session;
- discover organizations, workspaces, memberships, and roles available to the account;
- create and maintain the selected managed workspace projections in Chrome bookmarks;
- send local managed-tree changes to the configured backend and apply remote changes in Chrome;
- receive real-time synchronization events and replay missed events;
- show connection, workspace, synchronization, and account status; and
- diagnose failures, bound recovery work, and help the user retry or rebuild a managed workspace when needed.
4. Network communications and backend operator
The extension initiates application-data requests only to the backend URL configured by the user. HTTP or HTTPS is used for login, session renewal or termination, workspace discovery, bookmark, folder, and event requests. The corresponding WebSocket connection uses WS or WSS for real-time synchronization. The exact transport security therefore depends on the configured URL.
Use HTTPS and WSS for every non-local deployment. Plain HTTP and WS do not provide transport protection against interception or modification. The extension permits them to support local development and does not upgrade or guarantee the security of a configured server.
The configured server receives the data required for the requested operations, which can include account and workspace data, bookmark and folder content, client/device identifiers and labels, event identifiers, cursors, timestamps, and authentication credentials or tokens. The server operator determines server-side processing, logging, retention, deletion, access, and security. Users should review that operator's privacy and security terms before signing in or selecting workspaces.
Back to top5. Bookmark access and managed scope
Chrome's bookmarks permission can technically expose the browser's bookmark tree to the extension. The current URLises implementation limits synchronization behavior to its managed scope:
- It locates or creates the managed root folder named
URLises. - It creates projections only for workspaces the user selects, organized beneath that root.
- It maps and synchronizes folders and bookmarks within those selected managed workspace projections.
- Bookmark events that cannot be resolved to a selected managed workspace are ignored and are not synchronized to the backend.
Moving a mapped item outside its managed workspace can trigger protective recovery or pause behavior rather than causing unrelated bookmarks to be synchronized.
Back to top6. Chrome permissions
| Permission | Why URLises needs it |
|---|---|
bookmarks |
To locate the managed URLises root, read and maintain selected workspace projections, detect changes within them, and apply synchronized folder and bookmark operations. |
storage |
To retain settings, the generated client/device identifier, selected workspace state, redacted session metadata, credentials in their designated Chrome storage areas, mappings, cursors, diagnostics, and recovery state. |
Host access for http://*/*, https://*/*, ws://*/*, and wss://*/* |
To let the user connect URLises to a backend at a user-chosen local, self-hosted, or hosted address. The broad host patterns support arbitrary backend locations; they are not used to read visited web pages. |
The current extension does not declare content scripts and does not inject code into web pages.
Back to top7. Practices not used by the current extension
The current URLises extension and its maintainers do not:
- display or support advertising;
- sell extension data;
- integrate third-party analytics or behavioral profiling;
- perform cross-site tracking;
- inject content scripts into visited pages; or
- download or execute remote code.
This privacy-policy website is static. Its page code uses no JavaScript, sets no cookies, and includes no trackers, analytics, forms, external fonts, or externally hosted assets. GitHub Pages and GitHub Issues may process normal connection, account, or request data under GitHub's own terms when a person visits the site or follows the contact link.
Back to top8. Local retention, sign-out, and deletion
Local data remains in Chrome extension storage until it is replaced during normal operation, removed through sign-out, cleared through Chrome, or removed when the extension is uninstalled.
When the user signs out, the extension:
- removes the locally stored refresh token and access token;
- removes the local Chrome bookmark projections for selected managed workspaces on a best-effort basis;
- clears cached account, organization, workspace, selection, mapping, cursor, synchronization, and recovery state; and
- preserves user settings, including the configured backend URL and generated client/device identifier.
The extension may record a new local diagnostic entry confirming the sign-out. It also attempts to notify the configured backend that the session is ending, but sign-out does not claim to delete the user's backend account, server-side bookmarks, workspaces, server logs, or backups.
Uninstalling the extension or clearing its data through Chrome removes the extension's local Chrome storage according to Chrome's behavior. Managed bookmark content that exists in Chrome should be reviewed separately by the user; browser bookmark data and extension storage are different stores.
Back to top9. Backend retention and deletion
Backend data retention and deletion are controlled by the operator of the configured URLises server. Requests to access, correct, export, or delete server-side account or workspace data must be directed to that operator. The extension maintainers cannot fulfill deletion requests for a server they do not operate.
Back to top10. Security and user responsibilities
URLises limits its client behavior to the functions described in this policy, but no extension, device, network, or server can be guaranteed secure. URLises does not claim end-to-end encryption, encryption at rest, anonymity, or any absolute security guarantee.
Users and server operators should:
- use HTTPS/WSS for non-local servers and verify the configured backend URL before signing in;
- use a trusted Chrome profile and device protected by appropriate operating-system and account controls;
- restrict access to the backend, its database, logs, and backups;
- apply server and browser security updates;
- grant workspace access and roles carefully; and
- avoid placing secrets in bookmark titles, folder names, URLs, diagnostics, or public support issues.
Only connect to a backend you trust. A malicious or compromised configured backend can receive submitted credentials and synchronized workspace data.
Back to top11. Children
URLises is a team-workspace synchronization tool and is not designed or directed specifically to children. A parent, guardian, school, or organization that permits a minor to use URLises is responsible for the account, workspace content, configured server, and any permissions or notices required for that use. Concerns about a minor's server-side data should be directed first to the configured server operator.
Back to top12. International and self-hosted deployments
URLises can connect to a server selected by the user, including a self-hosted server. Data may therefore be processed in any country or region where that server, its logs, or its backups are located. The extension maintainers do not choose those locations for independently operated servers. The server operator and user are responsible for evaluating hosting location, cross-border processing, access, retention, and applicable requirements.
Back to top13. Policy changes
This policy may change when the extension's behavior, permissions, or data practices change. The revised policy will be posted at the public policy URL with an updated effective or last-updated date. Earlier versions remain available through this repository's Git history after publication.
Back to top14. Contact
Questions or concerns about this policy or the extension's client-side behavior can be submitted through the URLises privacy repository issue tracker.
The issue tracker is public. Do not include passwords, authentication tokens, private bookmark URLs, personal data, diagnostics containing sensitive details, or other secrets. For server-side account or data requests, contact the operator of the configured URLises backend.
Back to top