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
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.
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|
|Link to original RFE|