Problem: Right now for us to block data rendered in fields, we have to do this via OnDemand Privacy rules which are very cumbersome, and you have to create a rule for almost every pattern. This is now gotten to a really challenging level with DOM capture.

Solution: Have an interface to allow blocking of elements directly by the portal admin, by element identifier (ID or name) patterns. Also, any rendered input fields have a WHITELIST option. For example, all data captured by UIC, fields entered would be MASKED or BLOCKED (admin option). This would include default values captured as part of the DOM.

The script could just look for INPUT tags, and their values and block any default values, or look for currState and prevState values where there is any value (any other than blanks) and dynamically block them. It should be very easy to write those patterns into an parsing agent.

We need to be able to easily block patterns of address blocks, whole sections of the DOM or fields, so we make sure we're staying ahead of security and revealing PII.

Marking this as Urgent as OnDemand replay is becoming a major stop gap but we're stuck editing files with very little debugging and this is risking Tealeaf security as a vulnerability vector for PII data.