Acoustic Ideas

Submit new product ideas for Campaign, Interact, Marketing Operations, Marketing Platform, Campaign Managed Hosted, interact Managed Hosted, Marketing Operations Managed Hosted, Digital Analytics, Experience Analytics, Exchange, Watson Marketing Insights, Content, Web Content Manager and WebSphere Portal solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.

Connect with your peers and Acoustic experts on the Watson Marketing and Commerce Community

Submit ideas for other Acoustic Products:

Watson Commerce
Watson Supply Chain

BBR: WhiteList field contents render

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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 20 2018
  • Under Consideration
How will this idea be used?

Admin would be able to whitelist their DOM rendering of fields, and pattern-drop just like Replay Rules DOM elements to have them blocked or mask-redacted.  Note this does need to be security (NT) or Tealeaf group leveled, as we use this to let some people view PII, but some people not view PII.

What is your industry? Banking
What is the idea priority? Urgent
DeveloperWorks ID
Link to original RFE
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 29, 2018 06:36

    Are you aware of the option to have the UI kit default to removing all input values and only specify the ones you want to keep? Also the privacy patterns allow you to easily remove whole sections of DOM. Lots of people like to use an HTML attribute which indicates PII and removes either the value or innertext in a section between tags.