Sensitivity

Sensitivity

Potentially, any UI element could contain sensitive information that should not be recorded. However, some elements that are not recorded by default could contain harmless, yet vital data for analytics.

👍

Sensitivity

In Smartlook, controlling UI elements recording is done by setting their sensitivity.

📘

In order to provide robust user privacy protection by default, some UI elements, namely text inputs and web views (that typically contain sensitive user data) are set sensitive by the default Smartlook setup. An application author must take active steps to remove these elements from the sensitive elements list in order to record their content.

Possible Sensitivity States

👍

Sensitivity can set to three possible states: sensitive, insensitive or default. These states are typically represented as an optional boolean value (true, false, or null).

The default state specifies that more general rules apply, i.e., a view instance with default sensitivity takes its sensitivity from its class.

When evaluating an UI element sensitivity, the more specific setting is always used, e.g. an individual instance sensitivity overrides the respective class sensitivity.

Handling Sensitivity of Individual Elements

When just one or few individual UI elements' sensitivity must be adjusted, the respective elements references are used to set their individual sensitivity.

On some platforms, Smartlook provides dedicated extensions, accessible as a slSensitive property (usage e.g. myView.slSensitive = false). When this is not possible or practical, Smartlook.instance.sensitivity methods can be used to manipulate individual component sensitivity.

Please refer to each platform API documentation for further details.

Handling Sensitivity of Classes

Sometimes, setting sensitivity on individual views is not practical such as in an application that heavily uses web views for presenting some insensitive content, or if the application defines its own subclasses of visual components that present sensitive user data.

To cover this use-case, Smartlook offers a convenient way to set sensitivity of all descendants of some class or visual elements that conform to a protocol on some platforms.

Please refer to each platform API documentation for further details.

Handling Content Presented in WebViews

Native WebView classes are handled as sensitive by default. Its instances, or the whole class, must be set insensitive in order to record its content. However, each web view can still contain HTML elements with sensitive content, and Smartlook thus does not record the standard HTML elements where the user enters data.

In order to change the default behavior, html elements that are not recorded by default can be set insensitive by assigning smartlook-show css class to them. Any html element that should not be recorded can be set sensitive by assigning smartlook-hide css class to it.

<input type="text" class='smartlook-show'>

<img class='smartlook-hide'>

Handling sensitive events

It is not just the visual elements that can contain sensitive information. Sometimes, a clue to sensitive user data can be found in user interaction events. Consider that, e.g., location of click events on a keyboard area could be used to guess a user’s password even when the keyboard itself is obfuscated.

📘

Click events in the area of the system keyboard are never recorded by Smartlook. User interaction with custom input elements, e.g., custom PIN-Pad, must be filtered out programmatically by the application developer.

The default setting is to track all events (with the exception of events on the keyboard, for obvious user privacy reasons). When this is not desired, the application may fine-tune the level of tracked events.

Typically, the default Full Tracking mode is desired, as it gives a detailed picture of user activities.

On the other hand, on some screens the event location of touches on an otherwise sensitive view can reveal sensitive private information (e.g., custom input view for PIN). In such a case, touches should not be recorded, and the application should switch temporarily to the Ignore User Interaction Events mode.

In specific cases, some apps that handle complex private information on particular screens may prefer stopping event recording altogether, by switching to the No Tracking mode for the screens.

🚧

Event tracking mode cannot be set on a per-UI-element basis, but only for the whole application.

More about event tracking modes can be found in each platform API reference.