Security & Trust Overview

Your data never leaves your browser.

A transparent look at how FieldPulse handles your Salesforce data — our architecture, permissions, and the promises we make to the people who install us.

01 · Executive Summary

Four trust pledges, enforced in code

These are not marketing claims — they are architectural facts. The rest of this page shows exactly how each one is enforced.

01

Zero external servers

FieldPulse has no backend, no cloud, no database. Every calculation runs in your browser on your machine.

02

Zero telemetry

No analytics SDK, no event tracking, no error reporting. We don't know when, where, or how you use it.

03

No credential storage

FieldPulse never asks for or stores your username or password. It uses your existing Salesforce session.

04

Read-only by design

Only SELECT and COUNT queries. Architecturally incapable of modifying records, fields, or metadata.

02 · Data Flow

Where your data actually goes

Every byte of Salesforce data touched by FieldPulse follows this exact path. Notice what's missing: a FieldPulse server.

YOUR BROWSER Salesforce Page (Lightning record view) Content Script (renders overlays) Service Worker analyzer + cache (all math here) Local Cache session + IndexedDB YOUR SALESFORCE ORG Salesforce REST API UI API + SOQL queries record ID SELECT / COUNT field data — no third-party server exists in this diagram —
Figure 1 — The complete data path. Traffic flows only between your browser and your Salesforce org.
03 · Trust Boundary

What lives where

FieldPulse has only two trust zones: your device and your Salesforce org. Nothing else. Most extensions introduce a third — "the vendor cloud". We deliberately don't.

TRUST ZONE 1 · YOUR DEVICE CHROME FieldPulse Extension service worker + content script + panel Session Storage (tab-scoped) IndexedDB (cached field metadata) Local Storage (preferences only) All above: cleared by "Clear Cache" button HTTPS TRUST ZONE 2 · YOUR SALESFORCE Salesforce REST API v62.0 / UI API / SOQL Your Org's Records access via your user's perms Session Cookie issued by Salesforce at login Governed by Salesforce's own security
Figure 2 — Only two trust zones exist. If our company disappeared tomorrow, no FieldPulse-hosted data would be at risk — because no such data exists.
04 · Authentication

How we log in without your password

FieldPulse never asks for Salesforce credentials. It borrows the session your browser already established at login.

1 You log into Salesforce (as you normally do) 2 Salesforce sets a session cookie (stored in Chrome) 3 FieldPulse reads the cookie (scoped) only from SF domains 4 Sends API call with Bearer token direct to your org Credentials never touch FieldPulse We do not see your username, password, MFA code, or SSO credentials. The session cookie is the only auth artifact we use, and it is only read at query time — never persisted to disk by the extension.
Figure 3 — The four-step authentication path. No credentials pass through FieldPulse.

What this means in practice

Your org's login policy still applies in full. FieldPulse piggybacks on the session it was given — nothing more.

  • SSO, MFA, and IP restrictions still apply. FieldPulse inherits them automatically.
  • Revoking access is instant. Logging out of Salesforce invalidates the cookie; FieldPulse loses access immediately.
  • User permissions are respected. FieldPulse cannot see fields you can't see.
  • No refresh tokens. Nothing for an attacker to steal that outlives your Salesforce session.
05 · Permission Justification

Every Chrome permission, explained

Chrome extensions declare their permissions upfront in manifest.json. Here is each one FieldPulse requests, exactly why, and what it does not let us do.

Permission Why FieldPulse needs it What it does NOT allow
activeTab Detect when you're on a Salesforce record page and inject the overlay only into that tab. Cannot access other tabs, history, or bookmarks.
storage Save your preferences and cache field analytics locally. Cannot sync to any cloud. Storage stays on this device.
sidePanel Render the analytics dashboard in Chrome's native side panel. Cannot open panels outside FieldPulse's own UI.
scripting Inject the overlay script into Salesforce pages on navigation. Cannot inject into non-Salesforce sites — host permissions restrict it.
alarms Run a background timer to refresh stale cache entries every 30 minutes. Cannot schedule network calls outside Salesforce. Only internal cache refresh.
cookies Read the Salesforce sid session cookie to authenticate REST API calls. Scoped to Salesforce domains only. Cannot read cookies from other sites.

Host permissions — where we can run

The extension can only execute on four domain patterns. Outside these, FieldPulse is dormant.

https://*.my.salesforce.com/*
https://*.lightning.force.com/*
https://*.force.com/*
https://*.salesforce.com/*

Content Security Policy

The extension enforces a strict CSP — meaning only scripts bundled inside the extension package can run.

script-src 'self'; object-src 'self'

No inline scripts. No remote CDNs. No eval(). This prevents injected or tampered code from executing even if a vulnerability were ever discovered.

06 · Data Storage & Retention

What's cached, where, and for how long

FieldPulse caches analytics locally to make repeat visits instant. All cache lives on your device. You can clear it at any time.

Storage Layer What it contains Retention Location
Session Storage Most recent analytics result for the current browsing session Until tab closes Chrome session memory
IndexedDB Field metadata, fill rates, edit-frequency counts 1 hour – 7 days (by type) Chrome profile, this device
Local Storage Preferences (fp_settings) and recent records list Until uninstall / cleared Chrome profile, this device
You own the data

Uninstalling FieldPulse from Chrome deletes all three storage layers. The "Clear Cache" button performs the same wipe on demand. We have no way to recover the data because we never had a copy.

07 · What We Never Do

The negative-space promise

Sometimes the strongest trust signal is a clear list of things an extension cannot and will not do — backed by architecture, not just policy.

08 · Verify It Yourself

Don't take our word — check

Every claim on this page is independently verifiable. Here's how to audit FieldPulse in about ten minutes.

STEP 01

Inspect declared permissions

Go to chrome://extensions, find FieldPulse, click "Details". Review "Permissions" and "Site access". The full set matches the permission table above.

STEP 02

Read the manifest

Enable Developer mode on chrome://extensions, click "Inspect views: service worker". Open manifest.json — the permissions, host_permissions, and content_security_policy blocks are the source of truth.

STEP 03

Watch the network

Open DevTools → Network tab while using FieldPulse. Filter by Fetch/XHR. Every request's domain should show only your Salesforce domains. Any other destination is a bug — report it.

STEP 04

Read the source

Chrome extensions ship as unminified JavaScript. On Windows, the folder lives under %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\. Open every file — no bundlers, no hidden build steps.

Total transparency by design

We chose not to minify, bundle, or obfuscate the extension. The entire codebase is approximately 2,300 lines of plain JavaScript — readable in an afternoon by a developer comfortable with vanilla JS.

09 · Reporting & Contact

Found something? Tell us first.

If you discover a vulnerability, privacy issue, or behavior that contradicts anything on this page, email us directly — before filing a public issue. We aim to acknowledge within 2 business days and fix (or mitigate) within 14 days.

Download the full security report

11-page branded PDF — share with your IT team or security review board.

Open PDF report

Security contact

Email: srbagal.ceo@gmail.com
Subject line: "FieldPulse Security"

Include: extension version, Chrome version, steps to reproduce, and (if relevant) a screenshot of DevTools showing the unexpected behavior.

What counts as a security issue

  • Any outbound request to a non-Salesforce domain.
  • Any data persisted outside the three storage layers above.
  • Any request that modifies Salesforce data.
  • Any execution on a non-Salesforce domain.
  • Any violation of the declared CSP.