JavaScript Functionality and Security

To address the question of the security of the JavaScript code in terms of its behaviour, I’ll briefly describe what occurs to identify whether a user is engaging in a user test, and then what happens if the user is indeed participating in a user test:

When a URL on which the JavaScript is included is loaded:

  1. A new JavaScript tag is written to the page, instructing the browser to load a remote JavaScript file. This JavaScript file is hosted on the servers which host the entirety of the Loop11 system.
  2. The loaded JavaScript begins executing, and writes some timestamps to cookies on the user’s browser. These timestamps are stored in order to detect participant use of the back and forward buttons, and are written on the browsers of both participants and non-participants. This is necessary because the timestamps must be generated and written prior to the later browser events which would interfere with their function. Note that this can be avoided by disabling the Loop11 feature which attempts to detect the use of the back and forward button.
  3. When the browser completes loading the page, the query string (after the ?) of the page URL is checked for a user test id which would identify the user as a participant. If the ID is found, it is written to cookies to allow the participant to be tracked as they move through the site.
  4. If the ID is not found in the URL the JavaScript then checks if a cookie was previously written by Step 2 of this process. If such a cookie is found, then the ID is retrieved from the cookie.
  5. If an ID was not present in the URL, or in cookies, then the JavaScript terminates. This is the stage at which the JavaScript stops running for a non-participant.
  6. If an ID was found, then the user is identified as a participant. Two additional JavaScript files are then loaded from the Loop11 server; one contains specific configuration data about the user test, and the current stage of the user test if the participant is already part-way through completing the test, and the other contains code which handles the execution of the user test. The request for the configuration JavaScript file provides the URL and page title of the current page to the server, as well as whether the user reached this page using the back or forward button (if this feature is enabled).
  7. The configuration JavaScript file executes the second JavaScript file, passing it configuration information about the current test. The user is then presented with the interface for the user test. If the user is currently engaged in a task, click-logging code is executed so heatmaps can be generated. On each user click, the location of the click and an ID representing the clicked element is sent to the server. If the user is presently completing a question, the question is then displayed. When the user answers the question, the response is sent to the server by the JavaScript, and a new configuration file describing the next step of the user test is retrieved from the server.

In terms of the security of the JavaScript: the file is loaded from the Loop11 server, so only Loop11 staff are able to make any changes to the JavaScript. It is also restricted by the security constraints applied by the JavaScript engine of the browser; it is not able to access anything outside the browser, nor any other tabs or windows the user may have open in their browser.
At no stage does the JavaScript read the content of any field being completed by the user, nor store any of the on-screen content. The only data sent to the Loop11 server by the JavaScript is the element clicked (and then, only an ID – if a user clicks a text field, the ID but not the content of the text field is sent), the URL and page title, and whether the back or forward button was used.

Note that this describes the standard behaviour of the JavaScript. If the site being tested spans across multiple domains or subdomains, then some ID data is stored on the Loop11 server and the client browser stores a Session ID to identify itself to the Loop11 server. This allows the activity of a single user engaged in a single user test to be recorded across domains, which is not possible when storing the participant ID and so forth on the client browser (as it is bound to the specific domain being tested).

Addressing the question of performance:

Including any additional JavaScript on a page inevitably impacts to some extent on performance (although typically the performance effect is negligible). For a user not participating in a user test, the performance impact is due to downloading a JavaScript file from the Loop11 server, generating timestamps, storing three cookies, and a very small amount of string processing on the URL. In practice, this impact is not noticeable.

For users participating in a user test, there is additional execution, and the greatest performance impact is due to attaching IDs to each item on the page for click recording. The impact of this process is dependent on the complexity of the page, but in practice the impact is likely to be unobservable on any moderately recent computer and browser.

One final note on use of the JavaScript: the feature which allows detection of use of the back and forward button on Internet Explorer requires a fragment to be appended to the query string as the user navigates from page to page. This occurs for all Internet Explorer users, even those participating in user tests. If this is a concern, the feature can be disabled to avoid this side effect.

Want more inspiration?
Join the Fab-UX 5!

Five links to amazing UX articles,sent to you once a week.

No SPAM, just pure UX gold!

No Thanks