Page Content Processing

• 1: Protegrity Standard Attribute
• 2: Custom Mapping Configuration
• 2.1: Domain Matching Rules
• 3: Stored Suggestions

1 - Protegrity Standard Attribute

Protegrity Standard Attribute

The Protegrity Standard Attribute is the most direct way to instruct the Browser Protector to unprotect a specific element on any web page. When an HTML element is annotated with the data-pty-dataelement attribute.

This approach is intended for use when the web application itself can be instrumented — for example, when the application’s front-end templates or server-rendered HTML can be modified to include Protegrity markup.

How It Works

Add the data-pty-dataelement attribute to any HTML element that contains a protected value. Set the attribute’s value to the name of the Protegrity data element that was used to protect the data.

<span data-pty-dataelement="SSN">***-**-1234</span>

When the extension runs (either on page load or on DOM change), it scans the page for all elements carrying this attribute and submits each element’s text content to the Protegrity service for unprotection using the specified data element. The element’s text content is then replaced in-place with the plaintext result.

Processing Behavior

• The attribute value matching against configured data elements is case-insensitive.
• Elements that have already been processed are marked with a data-pty-processed attribute to prevent duplicate API calls.
• Elements with an empty data-pty-dataelement value or no text content are skipped.
• If the attribute value does not match any data element configured in the extension, the element is skipped with a warning logged to the browser console.
• When Unprotect Automatically is enabled, the extension also monitors the DOM for newly added elements carrying this attribute (e.g. content loaded dynamically after page load).

Priority

Standard attribute processing runs first, before custom mapping rules. This means any element tagged with data-pty-dataelement will always be processed by the standard attribute path, regardless of whether a custom mapping also matches it.

Example

Given the following rendered HTML:

<td data-pty-dataelement="FullName">John Doe token here</td>
<td data-pty-dataelement="SSN">***-**-6789</td>

The extension will submit both elements to the unprotection service — one using the FullName data element and one using SSN — and replace their contents with the corresponding plaintext values.

2 - Custom Mapping Configuration

Custom Mapping Configuration

Custom mappings allow administrators to explicitly tell the Browser Protector which HTML elements on a specific site need to be protected or unprotected.

Custom mappings are defined under the optional customMappings key in the extension configuration JSON.

Structure Overview

customMappings
└── domains[]
    ├── domain                          — hostname to scope the rules to
    ├── page[]
    │   ├── path[]                      — URL path segments to scope rules to (empty = all paths on the domain)
    │   └── mappings[]                  — groups of attribute-based rules
    │       ├── attributeName           — HTML attribute to inspect (e.g. id, class, aria-label)
    │       ├── value                   — expected attribute value; omit to match on attribute presence alone
    │       └── entries[]
    │           ├── dataElement         — Protegrity data element name to use for the operation
    │           ├── operation           — "protect" or "unprotect"
    │           ├── splitSegments       — (optional) split text content into individual tokens before processing
    │           └── parentConditions[]  — (optional) ancestor element constraints for narrowing matches
    └── title[]
        ├── path[]                      — URL path segments to scope title rules to (empty = all paths on the domain)
        └── algo                        — identifier for the page title unprotection algorithm to use

Domain Matching

Exact domain entries take precedence over wildcard entries.

To read more about domain rules, go here.

Path Matching

• An empty path array applies the mapping rules to every page on the matched domain.
• When paths are provided, they are matched as substrings of the current URL path (e.g. "/accounts" matches /accounts/list).

Parent Conditions

parentConditions can optionally restrict a mapping so it only fires when the target element has a specific ancestor within a certain number of DOM levels. Each condition can check the ancestor’s tag name, an attribute name, and/or an attribute value.

Example

The following configuration unprotects any element on crm.example.com that has aria-label="customer-ssn", using the SSN data element:

"customMappings": {
    "domains": [
        {
        "domain": "crm.example.com",
        "page": [
            {
            "path": [],
            "mappings": [
                {
                "attributeName": "aria-label",
                "value": "customer-ssn",
                "entries": [
                    {
                    "dataElement": "SSN",
                    "operation": "unprotect"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

When the extension detects an element such as:

<span aria-label="customer-ssn">***-**-1234</span>

This example html element will match the custom mapping rule above, allowing the Protegrity browser protector to know this is an element that when selected, will use the SSN data element for unprotection.

Page Title Unprotection

The title array within a domain entry enables unprotection of protected values embedded in the browser’s page <title>. This is useful for single-page applications (such as Salesforce) that reflect record data in the tab title after navigation.

Each title entry specifies:

• path — URL path scope (empty array = applies to all pages on the domain)
• algo — the name of the page title extraction algorithm to use

The extension monitors the <title> element for changes and re-runs unprotection on navigation or if the title changes.

Example

"customMappings": {
  "domains": [
    {
      "domain": "myorg.example.com",
      "title": [
        {
          "path": ["/example/r/User"],
          "algo": "Example_Algo"
        }
      ]
    }
  ]
}

For a title such as example Title, the extension will unprotect and rewrite the title with the plaintext result.

Notes

• Attribute matching is case-insensitive.
• Class attribute matching supports partial class list matching (i.e. the configured value only needs to appear as one class in a multi-class attribute).

2.1 - Domain Matching Rules

Exact Match Rules (config does NOT start with *)

Config: example.com

Config: www.example.com

Config: hr.example.com

Wildcard Rules (config starts with *)

Both *example.com and *.example.com normalize to base example.com.

Config: *example.com or *.example.com

Exact vs. Wildcard Priority

When both example.com (exact) and *.example.com (wildcard) are in config, exact entries are evaluated first. Wildcard is only used as a fallback.

Things That NEVER Affect Matching

3 - Stored Suggestions

Stored Suggestions

Stored suggestions are the extension’s memory of past user-confirmed unprotection actions. When a user manually unprotects an element through the extension, that element’s location and data element mapping are saved locally. On subsequent visits to the same page, the extension can automatically re-apply those unprotections without any further user interaction — provided the Unprotect Based on Past Usage setting is enabled.

How Suggestions Are Created

Each time a user performs a manual unprotect operation on an element, the extension records a suggestion containing:

• The element’s XPath and positional offsets within the DOM
• Contextual XPaths of the surrounding elements (preceding sibling, following sibling, parent)
• The element’s id, class, attributes, and any custom attributes
• The data element and operation type selected by the user
• A match_frequency counter, starting at 1

Suggestions are stored in Chrome’s local storage (device-local, not synced across browsers) and are scoped per URL — organised by domain, path segments, query parameters, and hash.

Match Frequency

Every time a suggestion is confirmed again on the same element, its match_frequency counter is incremented. This counter acts as a confidence signal: the more times a particular mapping has been confirmed by the user, the more reliably it can be applied automatically.

When Unprotect Based on Past Usage runs on page load, only suggestions whose match_frequency exceeds the configured frequencyResetThreshold are applied automatically.

A suggestion with match_frequency of 1 will not be applied automatically at the default threshold — it must be confirmed at least twice before it is trusted for automatic unprotection.

How Automatic Re-application Works

When the page loads and Unprotect Based on Past Usage is enabled, the extension:

1. Looks up stored suggestions for the current URL
2. Filters to only those exceeding the frequency threshold
3. Resolves each suggestion’s XPath against the current DOM
4. Submits the matched element’s content to the Protegrity service for unprotection using the stored data element

Stored suggestion unprotection runs after standard attribute and custom mapping unprotection in the processing order. Elements already processed by an earlier step are skipped.

Storage Scope

Suggestions are stored in chrome.storage.local — they are local to the device and browser profile they were created on. They are not synced via Chrome’s sync storage and are not shared across devices or user profiles.