This post is the fourth and last part of our "Keeping OTT Content Secure" series. Feel free to read part three here.
Previously, we explored why forensic watermarking directly answers piracy concerns and why it is commonly implemented alongside DRM. In a nutshell, forensic watermarking enables providers to quickly track down the origin of leaked content and stop that source of piracy.
We ended our previous part by mentioning that we had Jscrambler engineers working closely with the teams of watermarking providers to uncover a key threat — the risk of tampering with forensic watermarking solutions. And to understand this threat, we must explore the different possible implementations of forensic watermarking.
Forensic Watermarking Implementations
We can divide watermarking into bitstream and A/B watermarking. In bitstream watermarking, specific changes that are imperceptible to the human eye (forensic watermarking) can be applied and will uniquely identify the client that leaked the content. This may sound familiar because our previous explanation of watermarking was based on this.
Then, there’s A/B watermarking, where the server pre-processes the content to build two watermarked versions which are combined through the use of a manifest specific to that client and session when streaming the content. This approach by itself has some pitfalls that you can explore in more detail in our white paper.
Both these watermarking techniques can be embedded at the server-side, on an edge server, at the client-side, or a combination of these.
At the client-side, the logic is either implemented at the firmware or at the SDK level and it inserts OTT client-related information. This information should always be generated in the form of a randomized ID at the server-side, to harden the task of an attacker reverse-engineering the information that is inserted into the content. The client-side approach requires integration at the client device level and so security measures — including at the hardware level — have to be added. In the “hybrid” approach, the server will still preprocess the content to build different versions and the watermark is either inserted or managed at the edge servers or on the client-side.
With OTT providers wanting to maximize the end-user’s experience (better player performance) and reduce costs, client-side or “hybrid” approaches have grown in adoption. And as we look closer at this implementation we again are led to the threat of tampering with the source code of the client-side watermarking agent.
Securing Client-Side Watermarking
To address the second problem — DOM tampering — providers must monitor the DOM in real-time to detect/block any attempt by an end-user to hide, remove, or modify the watermark. This includes changes to overlays, which is achieved by tampering with the DOM by changing either its HTML elements or CSS properties. Such a webpage monitoring solution must detect these changes regardless of their delivery mechanism.
If you’d like to know more about these security solutions, get in touch with us.