What's new in Hotjar

We recently published a blog post about our commitment to privacy. As a Hotjar co-founder and Director of Engineering, I am following up with this technical explanation of the changes we made to our recordings so they are more secure and privacy-centric for you and your website visitors.

How do recordings work?

When visitor sessions are recorded, recording tools such as Hotjar typically take a copy of the HTML of each page and record keystroke data (anything that the users types within input fields) to be able to replay those sessions accurately.

At Hotjar we have always been conscious of respecting people’s privacy and, in an effort to ensure all sensitive data is suppressed, we have offered Hotjar users two options:

• The ability to completely turn off the recording of all keystroke data (while always suppressing credit card number and password fields automatically).
• The ability to suppress other sensitive data, such as names or usernames, within HTML elements by adding a small snippet of code to their website.

What’s changing?

1. By default, Hotjar will now suppress all keystroke data within recordings

2. We’ve given Hotjar users the ability to whitelist fields they wish to record keystroke data for

3. Hotjar will never record keystroke data on potentially sensitive fields

4. We’re now loading and replaying recordings over HTTPS

1. By default, Hotjar will now suppress all keystroke data within recordings (unless the fields have been manually whitelisted).

To ensure we remove all potentially sensitive information from text written into input fields, we are now:

• suppressing keystroke data by default for all new accounts, and
• introducing a new whitelist system that allows Hotjar users to manually tag the fields they wish to record. 

Hotjar suppresses keystroke data using JavaScript directly on a web visitor’s browser. This means that the Hotjar script does not record or send the data to our servers, and asterisk (*) symbols are sent instead of the actual text. We will also be randomising the length of these asterisks strings to further obfuscate the suppressed data shown in recordings.

If a Hotjar user wishes to record keystroke data on specific fields, an account admin will need to turn on keystroke data recording from their site settings and manually whitelist fields (they will do so by adding an attribute or class to their input or textarea fields, as explained below).

How does this affect you if you currently record keystroke data on Hotjar?

You will need to whitelist the specific fields you wish to keep recording (explained in the next section). If you have this setting turned on, but do not whitelist any fields, Hotjar will still suppress keystroke data.

How does this affect you if you currently have keystroke data recording turned off on Hotjar?

If you currently do not record keystroke data, nothing will change. Hotjar will keep suppressing all text entered into input and textarea fields in recordings.

2. We’re giving Hotjar users the ability to whitelist fields they wish to record keystroke data for.

To improve their visitors' experience, sites may have specific needs to record and replay keystroke data on individual fields. If this is your case, Hotjar now offers the ability to manually whitelist fields.

Note: We have whitelisting restrictions in place, which means that there are specific fields we will never record, regardless of whether they are whitelisted or not (explained in section 3 below).

If you wish Hotjar to record your fields, you can follow these two simple steps:

1) An account admin will need to enable the "Record keystroke data on whitelisted fields" setting. This can be done from the site settings, when starting a new Recording snapshot or by editing an existing Recording snapshot.

2) Hotjar users need to manually add a “data-hj-whitelist” attribute OR add a “data-hj-whitelist” class to their input and textarea tags to whitelist their fields.

Using element attributes:

<input type=”text” name=”company” data-hj-whitelist />

<textarea name=”comments” data-hj-whitelist></textarea>

Using element classes:

<input type=”text” name=”company” class=”data-hj-whitelist” />

<textarea name=”comments” class=”data-hj-whitelist”></textarea>

Once you’ve turned on keystroke data and whitelisted your fields, Hotjar will start to record keystroke data from them unless those fields form part of our whitelist restrictions list.

3. Hotjar will never record keystroke data from potentially sensitive fields.

Regardless of whether whitelisting has been used, there are some specific field types that Hotjar will NEVER record when detected.

As a session is being recorded, Hotjar tries to detect sensitive fields such as names, addresses, phone numbers, passwords and credit cards and suppresses any text written in them.

Our whitelisting restrictions include:

• Any input fields of the following types: password, email, tel (telephone number).
• Any fields which contain content that looks like emails or credit card numbers (detected through regex).
• Any fields with the following name or id: username, name, surname, lastname, familyname, fullname, email, phone, telephone, tel, mobile, address, address1, address2, addressline1, addressline2, postcode, postalcode, zip, zipcode, ssn, nis, ppsn, dob, dateofbirth, password, pass, creditcard, cc, ccnum, ccname, ccnumber, ccexpiry, ccexp, ccexpmonth, ccexpyear, cccvc, cccvv, cctype, cvc, cvv. We also ignore case, “-” and “_” characters when matching (“NAME”, “full-name” or “family_name” would also be matched).

If Hotjar detects any of these fields, their content will be immediately suppressed and replaced with a string of asterisks (with the length randomised), before they are sent to Hotjar’s servers.

4. We’re now loading and replaying recordings over HTTPS.

HTTPS is a widely used Internet protocol used to ensure data can’t be viewed or modified by a third party as it is being transmitted to a user’s browser.

Hotjar now loads and replays all recordings of fully secure sessions over HTTPS: if the original session recorded happened over HTTPS (a secure session), Hotjar will play that session back over HTTPS.

Note that if only parts of the original recording happened over HTTPS, Hotjar will have to replay the entire recording over HTTP.

What’s next?

At Hotjar, we really care about your privacy and the privacy of your website visitors and users. Hotjar is NOT designed to show how a specific and identifiable person is using the site or app: we are building a solution that teams can use to truly understand how a site or app is being used, and more importantly why, as a whole and without making any of the individuals recognizable.

The difference between these approaches is huge. While most of our competitors allow you to tag, identify and search for specific users, with Hotjar we allow our customers to understand their visitors’ experience and identify common issues and opportunities without making individual users identifiable.

Over the next few months, we’ll be making some changes to start automatically suppressing any personally identifiable data detected in pages within the HTML itself. We will also be working on further improvements throughout the whole of Hotjar as part of our initiative to be compliant with GDPR - a new EU legislation that is completely in line with our own beliefs about user privacy. As always, we welcome your feedback to help us keep improving Hotjar for everyone.