Handling Sensitive Data
The goal of analytics is to understand the user journey in the application and their interaction with it, to better improve the user experience. To gather the necessary data, Smartlook follows user actions and records what users see on the screen. This indeed represents a challenge for protecting user privacy – out of decency, the law requirements, and also because the data itself is rarely needed for analytical purposes.
What analytics uses is the metadata.
There are several ways how Smartlook protects user privacy when gathering the information it needs for its purposes. Smartlook obfuscates out of the box the native visual elements that typically contain private information. The data are replaced by neutral colour boxes during the recording process, they never make it to our systems. Moreover, Smartlook offers a set of methods that enable application developers to avoid recording unnecessary information.
Potentially any UI element may contain sensitive information that should not be recorded. On the other hand, some elements that are not recorded by default may contain harmless data vital for analytics. Smartlook offers a comprehensive set of methods to handle various scenarios.
Terminology: in Smartlook, disabling UI elements recording is done by blacklisting it. Enabling UI elements recording is done by whitelisting it. Blacklisted UI elements are also called sensitive.
Most UI elements are whitelisted by default. Some types of UI elements (text edits, web views, etc.) are blacklisted by default.
There are three levels of granularity established for handling the sensitive data recording:
- individual UI elements recording
- UI element types recording
- the whole screen recording
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 not recorded in the default Smartlook setup. The application author must take active steps to whitelist these elements in order to record their content.
The support for individual sensitive data protecting methods depends heavily on the technology used for creating the particular user interface.
|Technology||Wireframe modes||No rendering||Individual elements sensitivity||Classes sensitivity|
|iOS UISwift||limited||supported||coming soon|
|Gaming (OpenGL, Metal) frameworks||supported|
In order not to record a particular view, like here in an example with an image view that shows a portrait image of the user, use a variable that holds a reference to the view with one of the following approaches to blacklist it.
When, on the other hand, an otherwise blacklisted view (in our example a web view) should be recorded, follow this example code:
In some use-cases, whitelisting or blacklisting individual views is not practical, e.g., 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 on some platforms a convenient way to blacklist or whitelist all descendants of some class or visual elements that conform to a protocol.
Native WebView classes are blacklisted by default. Its instances, or the whole class, must be whitelisted in order to record its content. However, a whitelisted web view can still contain HTML elements with sensitive content, and Smartlook thus does not record the HTML elements where the user enters data.
In order to change the default behavior,
html elements that are not recorded by default can be whitelisted by assigning
css class to them. Any
html element that should not be recorded can be blacklisted by assigning
css class to it.
<input type="text" class='smartlook-show'><img class='smartlook-hide'>
This functionality is fully available only on some platforms. Please consult the API reference what rendering modes are available for a particular development toolchain.
There can be scenarios when direct recording of the screen is not appropriate or necessary to understand the user behavior. In such cases, Smartlook can be instructed to use (permanently or just temporarily) one of its wireframe rendering modes.
When a wireframe mode is on, Smartlook draws a sketch of the screens instead of copying its content literally into the video. The principal UI elements and user interaction with them are still clearly distinguishable, but their actual look and content (texts, images) are replaced by an abstract representation.
The default rendering mode for an application is set in the dashboard.
When debugging or experimenting to find the most suitable one for a particular application, the default rendering mode can also be set within the setup options. In production releases, this option should not be used.
The application can change the rendering mode at any time, e.g., to temporarily hide the sensitive user content on some screens. It is also possible to obtain the currently used values.
More about rendering modes could be found in the API reference.
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 blacklisted 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 the API reference.