How do I protect my users' privacy in Fullstory?

This article discusses private data capture via Fullstory's element blocklist approach. For information on leveraging our newer allowlist approach to managing data capture rules, please reference this document on Private by Default.

The privacy of your customer data is of utmost importance to Fullstory and is a shared responsibility. Fullstory ensures that your customer data is securely stored and accessible only to you. In addition, we provide you with several tools to ensure sensitive customer information is never captured and never leaves the user’s browser or mobile application.

What follows are recommended best practices to ensure your company uses Fullstory in compliance with our Acceptable Use Policy and with a privacy-first stance toward your end users.

Privacy at Setup

Fullstory will take you through a quick setup process to configure privacy settings when you first open a new account.

Each decision in the Privacy at Setup process is opt-in vs. opt-out, meaning you determine what you want to allow Fullstory to auto-capture, explicitly or not. Follow the steps below to walk through Privacy at Setup:

1. Tell us where you intend to install Fullstory on the initial account Setup page.
2. On the Choose privacy settings page, select from the options provided to tell us what kind of data your site processes, then click Accept & Continue. 
3. From the Install a Snippet page, you can install Fullstory manually via a tag management system such as Google Tag Manager via our browser SDK, or you can send the instructions to a colleague. 
4. Once your account is set up, you can refine and/or change your privacy configurations from Settings.

Managing Privacy Settings in Fullstory

For current orgs (created before February 25, 2022), there are two primary methods of excluding data from Fullstory data capture:

1. Code-first with .fs-exclude or .fs-mask [Recommended]
2. Privacy Settings

In addition to our primary means of excluding certain data from Fullstory data capture, this document also covers the following topics related to element exclusion: 

• Capture data only with user consent
• Quick exclusion via Inspect Mode
• What do we exclude by default?
• Additional Details
• Technically, how do exclusions really work?

Exclude vs. Mask vs. Unmask

Fullstory has three different ways to treat elements when it comes to capturing data on a site or app. These (in order from most private to least private) are Exclude, Mask, and Unmask. Unless you are using Fullstory Private by Default, unmask is the default state for data capture. Let’s explore each of these types of data capture rules in more detail.

Exclude (.fs-exclude)

Fullstory’s most private element data capture rule is an Exclusion. For excluded elements, the element itself (and any child elements) will be ignored by data capture. All excluded elements are replaced in playback by rectangles containing diagonal grey and white stripes. This allows a Fullstory user to differentiate between excluded elements and intentional white space when viewing recreated sessions in Session Replay. Because exclusions apply to all child elements, it is not possible to Mask or Unmask the child of an excluded element.

Events that target excluded elements (click or change, for example) are ignored entirely. If understanding end-user interaction with an element is important, then using Mask is preferable to Exclude.

The CSS class .fs-exclude replaces the deprecated (yet still currently supported) class .fs-block. 

Mask (.fs-mask)

Masking is Fullstory’s “happy medium” privacy setting (and is the default setting for Private by Default customers). Masking is functional enough that even in a fully masked state, it is still possible to understand user experience using search, segmentation, and session replay.

For masked elements containing text, all text will be replaced by irreversibly transformed placeholder text meant to resemble a wireframe of the original content. This placeholder text blob will retain the size, color, and character length of the original text. Additional information on how the collection/rendering of masked text is managed is included in the technical section below.

As with excluded elements, Masking applies to the children of masked elements. However, unlike excluded elements, specific children of a masked element can be Unmasked. This allows for a more granular level of privacy control for complex elements like forms.

Interaction events targeting masked elements (such as click or change events) are captured. Because the actual text is not collected for masked elements, you will need to leverage CSS selectors in search where you might have searched using text had the element been fully Unmasked.

Unmask (.fs-unmask)

Default, unless using Private by Default

Unmask is Fullstory’s “capture everything” setting. When elements are unmasked, Fullstory will capture all text, images, and user interactions. It is likely that for digital products that contain little to no sensitive data, the vast majority of the site or app can be unmasked. On an e-commerce site, for example, the number of places that will need to be masked or excluded is likely limited to parts of the payment flow and/or the end-user's profile or settings. The remaining bulk of the site could safely be unmasked.

Managing data capture rules

Fullstory offers two different approaches to managing your element data capture rules. The first is implementing the appropriate CSS classes into your element libraries, an approach called “code-first.” The second method for managing element data capture rules is through the Fullstory Element Data Capture Rules UI located in Settings > Data Capture and Privacy > Privacy.

Code-first rule management

The code-first approach to managing element data capture rules is Fullstory’s recommended approach. Adding CSS classes to your libraries is simply a less brittle and more future-proof approach than handling these rules through the UI using CSS selectors. Fullstory has three classes for managing basic element data capture rules and three additional classes that interact with our fs.consent API:

Follow the below instructions to add CSS classes to your native mobile experience:

• iOS
• Android

In-app rule management via Settings

In the event that no engineering resources are available and/or there are circumstances that make managing data capture rules in a code-first manner untenable, it is possible for Admin users to manage these rules via the Element Data Capture Rules UI located in the app at Settings > Data Capture and Privacy > Privacy.

From here you can create or modify data capture rules based on CSS selector. Additionally you can apply exceptions to the rule and add a rule “Scope.” The scope is related to preview mode and will be discussed below.

Clicking the “Create Rule” button will open this Add Element Data Capture Rule widget, where the CSS selector is added, the rule type is selected, and the rule is scoped (a similar widget exists for editing rules):

A similar widget is also available for adding element data capture rules directly from Inspect Mode while watching a session:

CSS Supported by Element Data Capture Rules

CSS selectors are the main mechanism for managing Exclude, Mask, and Unmask through the Fullstory UI. It is important to properly make use of broad selectors, especially when Unmasking, in order to keep the list of items in your Data Capture Rules as manageable as possible. For managing data capture rules, Fullstory supports nearly all types of CSS selectors. The complete list can be seen here:

For reference, Element Data Capture Rules DO NOT support the following CSS selectors:

Here are some examples of some broad CSS selectors that have been used for unmasking larger sets of things:

Form Privacy

If your account was created on or after November 10, 2021, you'll also see a feature under Settings > Data Capture and Privacy > Privacy called Form Privacy. Form Privacy automatically enables a set of six-element data capture rules that mask all form elements with the attributes input, textarea, select, andcontenteditable, and exclude all form elements with the attributes radio and checkbox. This proactively protects end users' privacy by preventing Fullstory from logging potentially sensitive user data captured by form elements on your site or mobile application. Learn more about Form Privacy here. 

To Mask or to Exclude: Recommended Best Practices

A common question related to element data capture rules is, “How do I know if I should upgrade the rule for an element from Mask to Exclude?” This is a great question, and while the answer isn’t particularly complicated, it requires careful thought.

First, if the element in question is meant to contain or could possibly contain information of a regulated nature (meaning the information is governed by regulations like HIPAA, FERPA, GLBA, etc.) then you should seriously consider upgrading from Mask to Exclude.

Second, personal confidential data like Social Security numbers, driver’s license numbers, bank account numbers, or passwords should also be excluded.

The third potential application of Exclude over Mask is definitely the most nuanced. You should consider upgrading from Mask to Exclude for elements where the nature of the information, even in masked form and/or end-user interaction with the element, makes it possible to potentially infer personal details about the end user. Let’s look at a couple of examples.

Example 1: We could imagine that there are healthcare-related sites or apps that are meant to collect all kinds of information about an end user’s medical history. If part of the interface were to contain checkboxes for capturing the presence of certain medical conditions, it would not be enough to simply obscure the text content in session replay. Because masked elements collect interaction data, it would be possible for someone with good working knowledge of the product to understand which health issues a user was checking the boxes for. Therefore, the best course of action would be to exclude the checkboxes themselves so that it would be impossible to make these kinds of inferences.

Example 2: This second example comes to us from the financial technology sector. Many different services exist for managing various aspects of one's finances. These include banking apps, investment apps, apps for creating and managing budgets, apps for transferring money and even apps for paying taxes. Many of the elements contained in applications like these would be just fine masked. However, there may be fields (like account balance) where even the relative text length might actually be too much information. If you were comparing the session replays of two different accounts and one showed a placeholder string for account balance that was three inches long and the other had a placeholder string that was half an inch long, you now know more about these two accounts than you probably need to. So, fields like account balance are good candidates for upgrading from Mask to Exclude.

Hopefully these suggestions have helped make it more clear when to consider Exclude over Mask. If there is ever a situation where you are on the fence, go with the most private option. You’ll sleep better, and it’s the right thing to do.

Creating Element Data Capture Rule Exceptions

There are many cases where you may wish to exclude or mask some, but not all, elements that match a particular selector. For example, perhaps you'd like to block all input elements except for your site search, which provides valuable insight into your user's digital experience. Using element data capture rule exceptions gives you a high degree of control over the user data Fullstory captures. By creating restrictive data capture rules and applying exceptions to only specific selectors likeinput.safe, you ensure that new elements added to your site match the most restrictive rule by default–safeguarding sensitive data as your site evolves.  Learn more about how to use element data capture rule exceptions here. 

Scoping Data Capture Rules

With the introduction of Fullstory’s Preview Mode, Admins now have the ability to test new data capture rules on their own sessions before pushing these changes live for actual end-users. This should help to increase the confidence that Admins have about new iterations of their data capture settings and should reduce the need to constantly test new data capture rules in an actual staging environment.

As noted briefly in the Settings UI section above, all element data capture rules can now be Scoped. This means that you can set data capture rules to function in four different ways:

To learn more about using scoped rules with Fullstory's Preview Mode, please check out the existing help article for Preview Mode.

We pre-populate the exclusions list with industry-standard HTML. You'll want to double-check how your company has coded these sensitive fields. If your input fields have different CSS naming conventions, you'll need to add them to the exclusions list.

If you're using the industry standards, we'll block the following default exclusions:

• Passwords with input[type=password]
• All credit card data / payment card information with [autocomplete^=cc-]
  • Name
  • Credit card number
  • Expiration date
  • Security code
  • Card type
• Hidden inputs with input[type=hidden]

You can find the exclusions list by clicking on Settings > Data Capture and Privacy > Privacy.

Additional details about excluded content

• When you encounter a field that’s been excluded while viewing a session, you’ll see a gray box with cross-hatches over the field, indicating it’s blocked from data capture.

• Only the inner contents and some attributes (value, checked, src, data, alt) of excluded elements will be excluded. Any HTML attributes—except those listed above—of the excluded elements will still be captured (though they won't be visible in the Fullstory UI during playback). Take, for example, the following:
  
  <div class="fs-exclude" data-secret="abracadabra" value=”abra”>Your secret is abracadabra</div>
  
  In this example, the text Your secret is abracadabra will not be captured. However, the text <div class="fs-exclude" data-secret="abracadabra"> will be captured.
  
  If you are storing sensitive data within HTML element attributes, you'll need to exclude the parent of the element to be excluded. (Note that there is no way in pure CSS to specify the parent node of a selector).

How does excluding or masking elements work? What are the technical details?

Fullstory captures the user interface (UI). The only method Fullstory uses for capturing the UI is by tracking the DOM structure and any changes to it. This means the data capture script sends changes to the DOM structure to Fullstory's servers, along with raw input events and metadata.

Element exclusion and masking, therefore, operate at the DOM level. This means:

• Excluded or masked elements never leave your users' browsers or mobile applications or touch Fullstory's servers. 

• All excluded or masked elements are processed locally in the user's browser. When changes to the DOM structure are sent to Fullstory's servers, excluded elements are left out, and masked element text is left out.

• Relatedly, some raw input events (e.g., click events) are also redacted when they relate to an excluded element.

If you ever have a need to remove a session or all sessions in a Fullstory segment, please follow our instructions here.

Respect the consent of your users with FS.consent

Is there a subset of data you wish to share with Fullstory but only upon receiving consent from the end user? If so, we give you the power to respect the consent of users when determining what data should be sent to Fullstory. You can learn more about our FS.consent API here.

FAQs

Can I target Shadow DOM elements with privacy rules?

Yes! However, there are some caveats. Fullstory is unable to index selectors that maintain continuity when crossing the shadow boundary (into the shadow root), so CSS selectors don't span across the shadow boundary. As such, you can target elements within the shadow DOM with privacy rules, but you must use CSS selectors that are relative to the shadow root, rather than the parent page.

Example

<div>
  #shadow-root // start shadow root
    <p class="shadow-dom-text">Secret</p>
  // end shadow root
</div>

In this example, for a Privacy Rule targeting the "Secret" paragraph element, div p would not match because it cross the shadow boundary—since it selects the parent div element. However, using just p or .shadow-dom-text or p.shadow-dom-text would work because it is relative to the shadow root (references selectors contained entirely within the shadow DOM).

Thusly, creating a mask rule for p.shadow-dom-text would mask the "Secret" paragraph element specifically.