✨ [RUM-10415] Add support for action name allowlist masking

[cy-moi]

Motivation

Mask action name with allowlists generated from rum privacy build plugin(WIP). This approach is purely client side and allowlist-based. We aim to mask all action names (custom & auto) OOTB with build time configuration using a build plugin.

The raw string literals would be extracted at build time and loaded on demand in runtime with pre-injected helpers. In SDK, we only check action names and node text in SR with allowlist to mask action names.

Note: As we are using innerText to get action names, we can over mask in some cases.

Changes

• Add allowlist processing helpers
• Mask all action names with the allowlist when privacy build plugin is opt-in

Test instructions

Tests with BrowserStack should pass (for regEx compatibility)

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.22%. Comparing base (ec025eb) to head (cf3170f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3648      +/-   ##
==========================================
+ Coverage   92.20%   92.22%   +0.02%     
==========================================
  Files         333      336       +3     
  Lines        8322     8357      +35     
  Branches     1874     1894      +20     
==========================================
+ Hits         7673     7707      +34     
- Misses        649      650       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cit-pr-commenter]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	151.43 KiB	152.39 KiB	978 B	0.63%	✅
Rum Recorder	19.06 KiB	19.06 KiB	0 B	0.00%	✅
Rum Profiler	5.17 KiB	5.17 KiB	0 B	0.00%	✅
Logs	54.70 KiB	54.70 KiB	0 B	0.00%	✅
Flagging	N/A	931 B	931 B	N/A%	✅
Rum Slim	109.92 KiB	110.79 KiB	884 B	0.79%	✅
Worker	23.60 KiB	23.60 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base Average Cpu Time (ms)	Local Average Cpu Time (ms)	𝚫
addglobalcontext	0.012	0.016	0.004
addaction	0.032	0.032	-0.001
addtiming	0.005	0.006	0.001
adderror	0.030	0.031	0.001
startstopsessionreplayrecording	0.005	0.005	0.000
startview	0.010	0.010	0.001
logmessage	0.035	0.033	-0.003

🧠 Memory Performance

Action Name	Base Consumption Memory (bytes)	Local Consumption Memory (bytes)	𝚫 (bytes)
addglobalcontext	26.32 KiB	28.95 KiB	2.62 KiB
addaction	45.11 KiB	47.11 KiB	2.00 KiB
addtiming	24.19 KiB	26.82 KiB	2.64 KiB
adderror	49.04 KiB	50.45 KiB	1.42 KiB
startstopsessionreplayrecording	23.74 KiB	25.60 KiB	1.86 KiB
startview	422.00 KiB	428.05 KiB	6.05 KiB
logmessage	83.68 KiB	94.30 KiB	10.62 KiB

🔗 RealWorld

[sethfowler-datadog]

Could createActionAllowList() register the observer? It feels like this code shouldn't need to know about that. (Maybe createActionAllowList() is really startActionAllowListObserver() or something?)

Going a bit further: right now, there is no code that removes the allowlist observer when startActionCollection()'s stop() is called. So we create a new dictionary and add another observer whenever startActionCollection() is called, but nothing ever removes them, and they keep building up. I don't think we want that.

We should pick one of two approaches:

• Use a single global allowlist observer and dictionary, and never replace them or clear them. (Reasonable, since $DD_ALLOW is also global.)
• Register the allowlist observer and set up the dictionary when action collection starts; unregister the allowlist observer and clear the underlying dictionary when action collection stops.

The first avoids reprocessing the raw strings when recording restarts, so it has a performance benefit, but naturally you'll have to add some additional affordances for testing with that approach.

[cy-moi]

I see.
With the first approach, do we need end-to-end tests or just keeping the contexts in unit tests would be enough? I'm ok to proceed with the second approach for now but clearing the dictionary and re-process could get expensive. We might need some field data on this.
Fixed with the 2nd approach.

[amortemousque]

❓ question: IIUC, when multiple tokens are masked, we might end up with a name like "MASKED MASKED MASKED", which could be confusing from a UI perspective. Especially, given that the other masking strategy displays "Masked Element", shouldn’t we aim for consistency? Do we have product input on this?

[cy-moi]

Indeed, although Masked Element is not idea for tokenized the names either, maybe we should seek another way, ie XXX XXX in session replay. Will ping product on this.

[amortemousque]

💬 suggestion: ‏I find this source name confusing. As mentioned in my other comment, I think we should ensure consistent behavior across our masking strategies. That way, we can keep using MASK_PLACEHOLDER as the source. If we need to identify which masking strategy was applied, we could include it as a separate event attribute. Wdyt?

[cy-moi]

Ideally, yes we would like to distinguish the two strategies. We did add mask_disallowed as a name source in rum-event-format as a separate attribute. But I'm open to change it to another name.

[cy-moi]

/to-staging

[cy-moi]

Per discussion internally, we changed to the exact match with DD_ALLOW approach.

[cy-moi]

/to-staging

[dd-devflow-routing-codex]

View all feedbacks in Devflow UI.

2025-07-23 14:52:07 UTC ℹ️ Start processing command /to-staging

---

2025-07-23 14:52:22 UTC ℹ️ Branch Integration: starting soon, merge expected in approximately 11m53s (p90)

Commit cf3170f0f0 will soon be integrated into staging-30.

---

2025-07-23 14:52:51 UTC 🚨 Branch Integration: this merge request has conflicts which couldn't be solved automatically

We couldn't automatically merge the commit cf3170f0f0 into staging-30!

To solve the conflicts directly in Github, click here to create a fix pull request.

Alternatively, you can also click here reset the integration branch or use the following Slack command: /devflow reset-branch -r browser-sdk -b staging-30

[dd-devflow]

🚂 Branch Integration: starting soon, merge expected in approximately 11m53s (p90)

Commit cf3170f0f0 will soon be integrated into staging-30.

[dd-devflow]

🚂 Branch Integration

Commit cf3170f0f0 has been merged into staging-30 in merge commit 5897d98d7e.

Check out the triggered pipeline on Gitlab 🦊

If you need to revert this integration, you can use the following command: /code revert-integration -b staging-30

[datadog-datadog-prod-us1]

⚠️ Tests

⚠️ Warnings

🧪 1 Test failed

recorder › scroll positions › should be recorded across navigation from recorder/recorder.scenario.ts (Datadog)

createTest.ts:204:3 should be recorded across navigation

[Firefox] › ../lib/framework/createTest.ts:204:3 › recorder › scroll positions › should be recorded across navigation 

    Error: expect(received).toBe(expected) // Object.is equality

    Expected: 100
    Received: 150

       at recorder/recorder.scenario.ts:802
...

ℹ️ Info

❄️ No new flaky tests detected

Code coverage: total 92.23%, base diff 0.02%, patch 100.00% (view details)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3ecbb66 | Docs | Was this helpful? Give us feedback!}