Installing Screendesk script

Add the Script to Your HTML File

Insert the following script tag just before the closing </body> tag of your HTML file. This ensures that the script loads after all the elements on the page have been rendered.

htmlCopy code<!-- Screendesk Embed -->
<script>
(function(){
  var d = document;
  var s = d.createElement("script");
  s.src = "https://app.screendesk.io/widget/xxxxx"; // replace with your id
  s.async = 1;
  d.getElementsByTagName("head")[0].appendChild(s);
})();
</script>

Content Security Policy (CSP) Considerations

If your website uses Content Security Policy headers, you may need to update your CSP directives to allow the Screendesk script to function properly.

Required CSP Directives:

Add the following to your CSP header or meta tag:

<!-- If using CSP via meta tag -->
<meta http-equiv="Content-Security-Policy" content="
  script-src 'self' 'unsafe-inline' https://app.screendesk.io;
  connect-src 'self' https://app.screendesk.io wss://socket.screendesk.io;
  style-src 'self' 'unsafe-inline';
">

Why These Directives Are Needed:

• 'unsafe-inline' in script-src: Required because the Screendesk script uses inline JavaScript execution and dynamic script creation

• https://app.screendesk.io: Allows loading the main Screendesk widget script (which includes bundled Pusher functionality)

• wss://socket.screendesk.io: Allows WebSocket connections to Screendesk's real-time server for live communication

Alternative for Stricter CSP:

If you prefer to avoid 'unsafe-inline', you can use a nonce-based approach:

<!-- Add nonce to your CSP -->
<meta http-equiv="Content-Security-Policy" content="
  script-src 'self' 'nonce-YOUR_RANDOM_NONCE' https://app.screendesk.io;
  connect-src 'self' https://app.screendesk.io wss://socket.screendesk.io;
">

<!-- Add nonce to the script -->
<script nonce="YOUR_RANDOM_NONCE">
(function(){
  var d = document;
  var s = d.createElement("script");
  s.src = "https://app.screendesk.io/widget/xxxxx";
  s.async = 1;
  d.getElementsByTagName("head")[0].appendChild(s);
})();
</script>

Testing Your CSP Configuration:

After implementing CSP changes, check your browser's developer console for any CSP violation errors. If you see errors related to Screendesk, you may need to adjust the directives accordingly.

Understand the Script Content

The script fetched from https://app.screendesk.io/widget/xxxx includes several functionalities like console logging, network request monitoring, and user activity tracking. These are encapsulated within an Immediately Invoked Function Expression (IIFE) to avoid polluting the global namespace.

Reasons for Loading the Script at the End

• Complete DOM Availability: Placing the script just before the closing </body> tag ensures all DOM elements are fully loaded, allowing the script to correctly bind event listeners and manipulate elements.

• Non-blocking Load: Using async = 1 makes the script load asynchronously, which prevents it from blocking the rendering of the rest of the page. This approach improves page load times and enhances the user experience.

Script Safety Measures

• Scoped Functions and Variables: The script uses an IIFE to encapsulate all its code, which prevents conflicts with other global variables or functions in your application.

• Session Storage: The script stores state information in sessionStorage, ensuring that it does not persist beyond the session or interfere with other scripts.

Initialization and Event Binding

Ensure that the script initializes correctly by loading it last in the body. This allows it to:

• Bind event listeners to elements that are already rendered.

• Start overriding console and network methods only after the page is fully loaded.

Detailed Breakdown of the Script’s Internal Code

The script includes several key features:

• Fingerprinting: Collects various browser and device details to generate a unique identifier for the user.

• Blur Functionality: Adds a blur style to specified elements to obscure sensitive information.

• Console Logs Override: Overrides default console methods to capture and transmit logs.

• Network Request Monitoring: Overrides fetch and XMLHttpRequest to log request and response details.

• Event Listeners: Tracks focus, blur, click, script errors, and unhandled promise rejections.

• Pusher Integration: Uses Pusher for real-time communication and logs transmission.

Safety and Performance Considerations

• Asynchronous Loading: The script is loaded asynchronously (s.async = 1;), ensuring it does not block the page load.

• Scoped Variables and Functions: Encapsulation within an IIFE prevents conflicts with other scripts.

• Session Storage: Uses sessionStorage to maintain state across page loads, without persisting data unnecessarily.

Addressing Common Concerns

Impact on Performance

Explanation: The asynchronous nature of the script loading minimizes the impact on the page’s initial load time. Additionally, the script is designed to operate efficiently, using modern web technologies and best practices.

Conflicts with Existing Code

Explanation: By encapsulating its functionality within an IIFE and using scoped variables, the script avoids conflicts with global variables or functions. This isolation ensures that it runs independently of your application’s code.

Security and Privacy

Explanation: The script includes mechanisms to redact sensitive information before sending it over the network. For instance, it masks authorization headers and other sensitive data in network requests:

javascriptCopy codeif (clonedHeaders.has('Authorization')) {
  clonedHeaders.set('Authorization', '[REDACTED]');
}

Reason: This ensures that sensitive information is not exposed, maintaining user privacy and data security.