PULSE RELAY

01. Purpose and scope

This policy explains how Pulse Relay 1.0.0 handles information while providing a local visual patchboard for automating tab events. It applies to the extension package, its studio page, and its background service worker.

Pulse Relay lets a user assemble a small circuit from one trigger, one condition, and one action. The circuit listens to browser tab metadata events and, when its condition matches, can perform a tab operation or show a local browser notification.

Because automation can act on tabs, this policy describes both the metadata the extension reads and the state changes it can intentionally make after the user saves a circuit.

02. Plain-language summary

• Circuit definitions are saved locally in chrome.storage.local.
• Tab URLs, titles, pinned state, muted state, and recent access metadata can be read when evaluating a rule.
• A session-only map of tab identifiers to last-activity timestamps supports the Inactive trigger.
• Pulse Relay does not read webpage DOM content, form fields, cookies, passwords, or page storage.
• The extension does not send rules or tab metadata to the developer or third parties.
• Actions are limited to local tab operations and optional local Chrome notifications.

The intended privacy model is simple: the browser provides tab events; the service worker evaluates local rules; the result stays within the browser.

03. Circuit data stored locally

Each committed circuit is stored as a local JavaScript object containing an extension-generated rule identifier, the circuit name, an enabled flag, one trigger type and its parameters, one condition type and its parameters, one action type and its parameters, a last-run timestamp, and a run counter.

Condition parameters can contain text you provide, such as a domain fragment, URL fragment, or title fragment. The Notify action can contain a custom notification message. Those strings are part of your local circuit configuration.

Rules are stored using chrome.storage.local. Pulse Relay does not use chrome.storage.sync and does not intentionally send rules to another profile or device.

Run counters and last-run timestamps exist to make the local interface informative and to suppress very rapid repeated execution. They are not analytics transmitted to the developer.

04. Session-only activity data

Pulse Relay uses chrome.storage.session to maintain a map from Chrome tab identifiers to a last-activity timestamp. This supports the Inactive trigger without creating a permanent browsing history.

The service worker seeds existing tabs with a current timestamp when its runtime initializes, updates a tab's timestamp when the tab is activated or navigates, and removes the entry when Chrome reports that the tab was closed.

Chrome session storage is intended to be ephemeral relative to local storage. Pulse Relay does not copy the activity map into its durable rule database.

The map records numeric tab IDs and timestamps, not webpage body content. A tab ID is a browser runtime handle and can be reused by Chrome across different browser lifetimes.

05. Tab metadata used for evaluation

The service worker can inspect a tab's URL, title, pinned state, muted state, identifier, index, and other standard Tabs API metadata required by the configured trigger, condition, or action.

Examples include checking whether a hostname contains user-supplied text, whether a URL contains a path fragment, whether a title contains text, whether the tab is pinned, or whether it is muted.

The Studio page also uses the tab lastAccessed metadata to choose the most recently used normal tab when you press Test Pulse. This avoids silently testing against an arbitrary first tab when the Studio itself is active.

URLs and titles can reveal browsing activity. Pulse Relay processes them locally for rule matching and does not transmit them to an external service.

06. Triggers

• Tab Activated fires when Chrome reports that focus moved to a tab.
• Tab Created fires when Chrome creates a new tab.
• URL Changed fires when Chrome reports a navigation URL change.
• Title Changed fires when Chrome reports a tab title change.
• Inactive is evaluated by a local one-minute Chrome alarm and compares the configured threshold with the local activity timestamp.

Inactive circuits are designed to run once for a given idle cycle. After a rule has fired since the last recorded touch, the same idle cycle does not repeatedly execute the rule every minute.

Title changes do not reset the inactivity timestamp merely because a background page updates its title. Activations and navigation events are treated as stronger activity signals.

07. Conditions

Conditions decide whether an event should proceed to its action. Version 1.0.0 supports Always, Domain Contains, URL Contains, Title Contains, Is Pinned, and Is Muted.

Text comparisons are performed locally and case-insensitively. Condition strings are stored with the circuit and are not used to construct a developer-side profile.

A circuit with missing modules or an empty required text field is rejected by the Studio validation path instead of being silently normalized into a different rule.

08. Actions and browser changes

• Pin Tab and Unpin Tab change the matched tab's pinned state.
• Mute Tab and Unmute Tab change whether the matched tab emits audio.
• Move to Start moves the matched tab to the first position Chrome permits inside its current pinned or unpinned tab section.
• Move to End moves the matched tab to the last position Chrome permits inside its current pinned or unpinned tab section.
• Notify asks Chrome to show a local browser notification with the message stored in the circuit.

These actions modify browser state on the local device. They do not submit forms inside webpages and do not click webpage elements because Pulse Relay has no content script.

The Studio also offers Test Pulse, which runs the draft rule against the most recently accessed normal tab so the user can observe the action before committing the circuit.

09. Loop prevention and execution safety

The background worker also validates stored rules before executing them. Invalid or unsupported stored definitions are skipped rather than being executed blindly.

Browser events are serialized through a local promise queue so near-simultaneous events do not race while updating the same rule run counters and last-run timestamps.

A short last-run guard suppresses extremely rapid repeated executions of the same circuit. These controls reduce accidental feedback loops but users should still review the behavior of multiple interacting circuits.

10. Permission: tabs

The tabs permission is central to the extension's single purpose. It allows Pulse Relay to receive tab events, read the metadata required by conditions, and perform the selected local tab actions.

Without this permission, the extension could not reliably distinguish domains, URLs, titles, pinned state, or muted state and could not pin, mute, move, or select target tabs.

The permission is not used to read webpage DOM content and is not paired with broad host permissions.

11. Permission: storage

The storage permission allows the extension to save circuit definitions in chrome.storage.local and activity timestamps in chrome.storage.session.

The local rule store persists so the automation survives a Studio reload and normal browser restarts. The session activity map is intentionally separate and more transient.

Pulse Relay does not use browser synchronized storage for its rule database in version 1.0.0.

12. Permission: alarms

The alarms permission is used to create a local alarm named for the inactive scan. Chrome schedules it approximately once per minute while the extension is active under browser service-worker rules.

The alarm does not contact a network server. Its only purpose is to wake local code so Inactive rules can compare current time against last-activity timestamps.

If no Inactive circuit matches, the scan does not perform an action. The alarm itself is not telemetry and does not report heartbeat data to the developer.

13. Permission: notifications

The notifications permission is used only by the Notify action and Test Pulse when that action is selected. The message shown comes from the circuit's locally stored action parameter.

Pulse Relay does not use notifications for advertising, promotional pushes, remote announcements, or developer messaging.

Chrome or the operating system may decide whether a notification is displayed according to user settings and platform policy. The extension does not bypass those controls.

14. No host permissions or webpage injection

Pulse Relay 1.0.0 declares no host_permissions and registers no content scripts. It does not request <all_urls> or inject automation logic into arbitrary websites.

A URL or title exposed by the Tabs API is used as browser metadata for matching. The extension does not use that metadata access to read page text, inspect forms, scrape content, or modify the webpage DOM.

This design deliberately keeps the product at the tab-management layer rather than turning it into a general webpage automation engine.

15. What Pulse Relay does not collect

• No webpage body text or DOM tree.
• No form entries, passwords, payment details, or authentication tokens.
• No cookies or site localStorage.
• No browsing-history export separate from event-time tab metadata.
• No microphone, camera, geolocation, clipboard, contacts, or personal files.
• No advertising identifier, device fingerprint, or cross-site profile.

Circuit parameters are user-authored automation settings, not content harvested from webpages.

16. Network behavior and remote code

Pulse Relay 1.0.0 contains no product network client: no fetch, XMLHttpRequest, WebSocket, beacon, telemetry SDK, remote font request, or developer API call is needed for its operation.

All executable extension code ships inside the package. The extension does not download executable JavaScript or evaluate remote code after installation.

Webpages represented by tabs can independently use the internet. Moving, pinning, or muting a tab does not create a Pulse Relay network request; any network behavior of the represented webpage remains the webpage’s own behavior.

17. Analytics and diagnostics

Pulse Relay does not send usage analytics, rule counts, trigger counts, run counters, error events, tab URLs, titles, or performance telemetry to the developer.

The local run counter shown on a saved circuit cartridge remains in the local rule object. It exists to help the user understand whether a circuit has executed.

Chrome and the operating system can collect their own diagnostics under separate policies. Pulse Relay does not receive those platform diagnostics through a developer service.

18. Advertising and data sale

Pulse Relay includes no advertising SDK, sponsored automation catalog, tracking pixel, or behavioral ad integration.

The developer does not sell or rent circuit data, tab metadata, activity timestamps, or notification messages handled by this extension.

Rules are not shared with data brokers, ad networks, or marketing platforms because the extension has no transmission path for them.

19. Third parties

Version 1.0.0 does not use a third-party cloud processor for rules, analytics, notifications, or automation execution.

Chrome supplies the extension APIs and may enforce enterprise, notification, or tab-management policies. The browser provider's processing is governed by its own terms.

Websites opened, moved, muted, or pinned by the browser remain third-party pages with their own privacy practices. Pulse Relay does not become the controller of those sites merely by manipulating their tabs.

20. Retention

Committed circuits persist in chrome.storage.local until the user deletes them in the Studio, clears extension storage through browser controls, uninstalls the extension, or Chrome otherwise removes the storage area.

Last-activity timestamps are stored in chrome.storage.session and are intended to be session-scoped. Entries are removed when the corresponding tab closes and are rebuilt as needed when the worker initializes.

There is no server-side retention schedule because there is no Pulse Relay server receiving extension data.

21. Deletion and user controls

Each saved cartridge has a delete control and an enable/disable control. Disabling a circuit prevents its triggers from matching while preserving the local definition for later use.

Deleting a cartridge removes that circuit from the local rules array. Uninstalling the extension removes the extension package and normally removes its extension-local data under Chrome behavior.

Because Pulse Relay does not create a developer cloud account, there is no separate remote account to close and no server-side rule archive to request for deletion.

22. Security

The extension minimizes exposure by using local browser APIs, packaging all executable code, avoiding host permissions, and avoiding remote data processors.

Local extension storage is protected by the browser profile boundary but is not separately encrypted by Pulse Relay. A person or process with sufficient access to the device or browser profile may be able to inspect local extension files.

Automation can intentionally change tabs, so users should review circuit combinations before leaving them enabled. The validation and serialization safeguards reduce accidental loops but are not a substitute for device and browser security.

23. Children

Pulse Relay is a general browser utility and is not directed specifically to children under 13 or the equivalent minimum age in a user's jurisdiction.

The extension does not knowingly create developer-side profiles of children or adults because it has no cloud account and no analytics collection system.

Parents and guardians should apply appropriate browser, operating-system, and website controls for shared or child-used devices.

24. International transfers

Pulse Relay does not intentionally transfer extension data internationally because rules and evaluated tab metadata are not sent to a remote service.

A webpage may transmit its own data when Chrome loads or navigates it. That site-level traffic is outside the extension's local automation processing described here.

25. Legal requests and disclosure

The developer normally has no Pulse Relay rule database, URL log, title log, or activity map to disclose because these are not collected onto developer systems.

Local browser data remains subject to the device owner, browser platform, operating system, and applicable law. This policy does not make promises on behalf of those independent parties.

26. Policy changes

This policy will be revised if a later Pulse Relay version materially changes permissions, rule storage, network behavior, telemetry, or the categories of tab metadata it processes.

A future version that introduces cloud synchronization, webpage content access, analytics, or remote integrations would require updated disclosure rather than being implied by this version 1.0.0 policy.

The effective date at the top identifies the policy applicable to this release.

27. Contact and package verification

Privacy questions should use the developer contact method displayed on the Chrome Web Store listing for Pulse Relay. That listing is the current authoritative contact channel.

Reviewers can verify the claims in this policy against the package: the manifest lists tabs, storage, alarms, and notifications; the service worker implements local tab events; and the manifest contains no host permissions.