In the modern web ecosystem, standard telemetry and analytics endpoints are frequently intercepted by ad-blockers, tampered with by malicious actors, or scraped by bots. To guarantee the integrity and delivery of usage data—such as views and interactions—developers are increasingly looking toward custom, secure pipelines.
By combining End-to-End Encryption (E2EE) with a quirky but effective obfuscation layer via WebSockets, we can create a robust telemetry service that bypasses simplistic deep packet inspection (DPI) while strictly validating data authenticity. Let's break down a fascinating architectural approach to this problem based on a real-world implementation.
1. The Persistent WebSocket Connection
Traditional HTTP requests for analytics are easy to spot and block. Switching to WebSockets provides a persistent, bidirectional communication channel that is harder to casually intercept.
In this architecture, the client (an Angular application) relies on a dedicated service to manage the WebSocket connection.
- The client connects to the analytics endpoint and automatically recycles the connection every 120,000 milliseconds to maintain session health.
- If a registered user token isn't available, the system generates a random UUID (v4) to act as a fallback tracking ID, persisting it in local storage.
- To keep the connection alive and detect dead sockets, the server sends a ping heartbeat every 30,000 milliseconds.
2. The Cryptographic Handshake
Security begins the moment the client attempts to connect. The initial handshake establishes trust and exchanges the necessary cryptographic material.
-
Client Initiation: The client opens the WebSocket connection and passes its public key via a base64-encoded URL query parameter (
?pub=...). - Server Key Generation: Upon receiving the connection, the server generates its own ephemeral RSA-OAEP key pair specifically for this session.
- Session Alphabet Generation: The server generates a random 32-byte seed and uses it to mathematically derive a completely shuffled, unique 64-character Base64 alphabet for the session.
- Secure Exchange: The server encrypts this session alphabet using the client's public key (via RSA-OAEP). The server then signs the encrypted payload with its own private key using RSA-PSS to guarantee authenticity.
3. The "Emoji Codec" Obfuscation Layer
While encryption secures the data, obfuscation helps disguise the nature of the traffic. Instead of sending standard binary or Base64 strings, this system translates the payload into a string of emojis.
The EmojiCodec relies on an array of 64 distinct emojis—ranging from 🚀 and 🌈 to 🌋 and 🎁—which map perfectly to a standard Base64 index. It introduces several layers of mutation to prevent traffic analysis:
- Object Shuffling: Before encoding, the keys of the JSON payload are randomized. This ensures that sending the exact same data twice produces entirely different underlying JSON strings.
- Dynamic Padding: A timestamp and a random client ID (CID) are injected into the payload to guarantee uniqueness.
- Caesar-Shift Cipher: A random emoji is selected as the "key index" (placed at the start of the final string). Every subsequent character in the Base64 payload is shifted along the emoji array based on this key, effectively applying a polymorphic Caesar cipher to the encoded data.
4. Ensuring Data Integrity with Canonicalization
Because JSON object keys can be ordered arbitrarily by different JavaScript engines, validating digital signatures on JSON strings is notoriously difficult. If the client signs {"a": 1, "b": 2} but the server processes it as {"b": 2, "a": 1}, the signature will fail.
To solve this, the system implements a strict canonicalStringify function.
- This function recursively sorts all object keys alphabetically before converting the payload to a string.
- Once the server receives the heavily obfuscated emoji string, it decodes it, canonicalizes the resulting JSON object, and then uses the client's public key (supporting either ECDSA or RSA-PSS algorithms) to verify the digital signature.
5. Idempotency and Event Processing
Once the payload is successfully decrypted and verified, the server processes the telemetry events. The backend validates the incoming data schema—ensuring events are strictly categorized as 'VIEW', 'LIKE', or 'ADMIRE'—and routes them to a StatManager.
To prevent malicious users or network retries from artificially inflating metrics, the server implements caching idempotency:
- When a 'VIEW' event is triggered, an idempotency key is generated using the event's entity ID and the user's session token.
- This key is stored in a cache with an expiration of 1 hour (60 * 60 seconds).
- If a duplicate request arrives within that window, the server safely ignores it.
By layering robust WebCrypto algorithms beneath a mutating, emoji-based obfuscation codec, this architecture ensures telemetry data remains confidential, untampered, and highly resistant to standard traffic filtering techniques.
Top comments (0)