This article provides a comprehensive overview of the Heed Desktop Client detailing its architecture, key operational components, and the security measures in place. It is intended to assist IT administrators, technical evaluators, and support teams in understanding the app’s functionality, deployment, and security features.
Technical Overview
1. Communication with the Server
The Heed Desktop App communicates securely with its backend servers to deliver real-time notifications, perform user-specific operations, and synchronize data:
Protocol: The app uses WebSocket and HTTPS protocols to ensure fast and secure communication.
Port: All traffic is routed through port 443, ensuring compatibility with standard corporate firewall settings.
Server Endpoint: The app connects to
%tenantName%.heed.io, where%tenantName%is the unique subdomain assigned to each customer. This tenant-specific endpoint serves as the central server for all data and authentication processes for that organisation.Telemetry: The client does not collect crash logs or diagnostic reports. It reports minor operational events back to the server over the same connection (for example, notification displayed, notification closed, wallpaper displayed) to support delivery confirmation and engagement tracking.
2. Application Installation and Key Files
During installation, the application deploys its key components to the following default location:
Installation Directory:
C:\Program Files (x86)\HeedKey Files:
Heed.exe– The main application executable that handles user interactions.HeedClientService.exe– The Windows service executable for managing elevated operations.HeedSCR.scr– The screensaver module, integrating Heed functionality with the system’s screensaver.Notifications\HeedNotification.exe– The executable responsible for handling user notifications and associated actions.
For environments with endpoint protection or antivirus software, these files should be added to the safe list to prevent interference with application functionality.
3. Windows Service: Heed Client Service
On Windows, the Heed Desktop App installs a Windows service called Heed Client Service:
Purpose: This service is essential for:
Executing operations that require elevated permissions.
Handling system-level tasks, such as processing notification actions and software updates.
Local System Context: The service runs under the local system account, granting it the necessary permissions to execute privileged actions securely.
Logging: Actions are logged to the Windows Event Viewer
Administrators can manage this service via the Windows Services interface (services.msc).
4. Log Files and Local Cache
The application stores logs and configuration data in the following default directories:
Logs:
%APPDATA%\Heed– Contains operational logs to assist in troubleshooting and monitoring.Local Cache and Configurations:
%LOCALAPPDATA%\Heed– Stores user-specific cache files and configuration settings.
These locations can be reviewed during troubleshooting or for clearing cached data.
5. Additional Features
Notifications: Delivered in real time via WebSocket, with actions processed locally by
HeedNotification.exe.Screensaver Integration: The
HeedSCR.scrmodule integrates Heed features into the system screensaver, providing a seamless user experience.
Security Overview
1. Secure Communication
Encrypted Data Transmission: The app uses TLS 1.2+ for all communications, ensuring data is encrypted during transit.
Server Validation: The app validates the SSL/TLS certificate of the customer's
%tenantName%.heed.ioendpoint against the operating system's trusted certificate store before establishing a connection, preventing man-in-the-middle (MITM) attacks. The client does not use certificate or public-key pinning, so it is compatible with environments that perform TLS inspection via a corporate proxy, provided the proxy's certificate is trusted by the device.Standard Port Usage: By exclusively using port 443, the app aligns with standard network security practices.
2. Local System Security
Elevated Operations: The Heed Client Service securely executes privileged actions required by the app. These operations include managing system notifications and performing administrative tasks.
Controlled Privileges: The service runs under the local system context, providing access to necessary system resources while adhering to strict security boundaries.
3. Application Hardening
Digitally Signed Executables: All executables (
Heed.exe,HeedClientService.exe, etc.) are digitally signed to ensure authenticity and integrity, preventing tampering.Minimal Local Data Storage: The app limits local data storage and encrypts sensitive configuration files in
%LOCALAPPDATA%\Heed.Screensaver Security: The
HeedSCR.scrscreensaver module is sandboxed and does not access sensitive files or require elevated privileges.
4. Protection Against Common Threats
Injection Mitigation: Input data is sanitized and validated before processing, reducing risks of SQL injection or similar attacks.
Replay Attack Prevention: Communications include nonce and timestamp validation to prevent replay attacks.
DLL Hijacking Defense: The app ensures that only trusted DLLs from its installation directory are loaded, protecting against malicious library injection.
5. User Authentication and Access Control
Secure Authentication: All interactions with
%tenantName%.heed.iorequire authentication, validated on the server side. Authentication is configured per Desktop Profile and supports methods such as Microsoft Entra ID (Azure AD), which enables silent sign-in for Entra ID-joined devices without a manual credential prompt. See Entra ID (Azure AD) Authentication for details.Session Management: Following authentication, Heed issues its own session token (a JWT with a defined issuer and audience) for the ongoing connection. The token is valid for 8 hours and is renewed automatically in the background before expiry, maintaining a persistent connection without requiring the user to re-authenticate. The token is stored locally in a DPAPI-encrypted file, scoped to the signed-in user and device.
Access Control: Heed uses a role-based permission system to control user access, with built-in roles (User, Manager, Admin) and configurable permissions governing access to features and data. See User roles and permissions for details.
Revocation: If a user is disabled, access to the Heed portal and desktop notifications is revoked immediately.
6. Compliance with Industry Standards
The Heed Desktop App follows best practices and industry standards for application security, including:
OWASP Top 10: Heed applies security controls mapped to the OWASP Top 10 Web Application Security Risks, covering areas including injection, authentication, access control, and secure logging. See Heed and The Open Web Application Security Project for details.
GDPR Compliance: Ensuring that user data is processed and stored in compliance with privacy regulations.
Best Practices for Administrators
Firewall Configuration: Allow outbound communication to
%tenantName%.heed.ioon port 443, where%tenantName%is specific to your organisation.Antivirus Whitelisting: Add the key files (
Heed.exe,HeedClientService.exe, etc.) to your antivirus safe list if necessary.Regular Maintenance: Periodically clear local caches if troubleshooting or optimizing app performance.