Is your feature request related to a problem?

The current log-filters works fine, but has some limitations that make it hard to use. The fact that we need to pass an already known RegExp during the configuration time (boot time) requires us to know beforehand what the sensitive data will look like, which is only sometimes the case.

For example, we use a pool of users with rotating passwords to enhance our security since 2FA is disabled on those accounts. To comply with the log-filters approach, I inject a known token at the beginning, like @mask@, to better identify my sensitive information. I was lucky since I could change my data, but sometimes, like for access keys, we can't, and this solution is hard to apply.

Describe the solution you'd like.

After the below attempts, a clever solution using the header X-Appium-Is-Sensitive was provided in this PR to fulfill this issue.

After wrapping logger occurrences with the provided utility to mask logger values, the header will be unlocked, and it will be possible to use it in WDIO easily when required.

To provide a more flexible approach where we do not know what the data will look like before starting appium and so be able to adapt depending on the data being sent to Appium, I would like to expose a method to add RegExp dynamically to the SecureValuesPreprocessor

Doing the above will help me cover the masking of sensitive data in WDIO in a more intuitive way and seamlessly for the user as described here. To summarize with an example:
1. In WDIO, we pass information tagged as sensitive, like MySecretPassword
. For the sensitive data, we extract a pretty good RegExp like ^M.{14}d$ or even ^My.{12}yd$ to minimize collision.
3. In WDIO, we call the logger to inject ^M.{14}d$ in the logger as a new log filter rule so that MySecretPassword get masked.
4. To be precise, I also found that a sensitive value from POST /element/${elementId}/setValue was also outputted, with all the characters having a coma in between. It might be something from WDIO and not Appium, but I intend to have a dynamic RegExp for that case, too.

Note: This is my first time with appium code; I'm still unsure how WDIO would call the logger method to inject that; I need to dig (or be advised)

Describe alternatives you've considered

Fetch all sensitive data and pass it into the appium configuration:

1. Put the burden on the developer to fetch and know all the sensitive data in advance instead of having tagged just in time.
2. Fetching all the sensitive data and passing all of them as plain RegExp and, therefore, keeping them in memory goes against the OWASP as quoted below

Overwrite any sensitive information stored in allocated memory at all exit points from the function

Have a more built-in solution

I see the possibility of a broader solution to hide sensitive data that also connects with vendors like BrowserStack. Today, all of them have their in-house solution to mask data (see BS hide solution). Additionally, a more built-in approach would cover other cases, like the reporter in WDIO, that today have no masking option, which is why I started all this.

An embryonic idea is to use a Boolean flag in the command's definitions (like setValue or get) to indicate that we hold sensitive data. With this flag, some touchpoints (logs, reporters, performance metrics) could better decide whether to display or hide their values.

The above approach would be better, but it would require years of investment, changes in Appium's protocols, and communication of its existence to vendors. For me, this is out of the scope.

Additional context

As pointed out, this started here when I saw my password leaked in wdio logs, appium logs, browser stack Text Logs, Wdio reporters and more. After digging, seeing that there is no documentation on the topic in WDIO, and finding the trick to use the appium solution, we still had BrowserStack to find out how. I had to make multiple twists and patches to succeed, which does not give me confidence that it will work in the long term.
So now, I'm trying to find a better solution integrated into WDIO, but I need this change. And who knows, maybe something better will come in the future!