[HN Gopher] Bypassing Watermark Implementations
___________________________________________________________________
Bypassing Watermark Implementations
Author : laserspeed
Score : 29 points
Date : 2025-07-22 16:03 UTC (6 hours ago)
(HTM) web link (blog.kulkan.com)
(TXT) w3m dump (blog.kulkan.com)
| laserspeed wrote:
| Bypassing of different Watermark implementations; including
| tricks related to Picture-In-Picture, erroneous assumptions at
| the time of enforcing client-side protections, and then HLS (HTTP
| Live Streaming) and ways to reassemble videos offline by looking
| into m3u8 playlists and encrypted video segments.
| nullbyte wrote:
| It's a good article, but I was a little disappointed that he only
| went over crude watermarking technologies. The more advanced
| systems implant an invisible watermark in the image or video
| itself by using neural networks. Those are a lot more tricky to
| bypass than simply removing a floating div.
| mlhpdx wrote:
| On reading the title, my mind went to crafting image (or video)
| uploads that effectively "undo" the water marking. That is, is
| there a way to alter content before uploading it so that when the
| watermark is applied it reverts the change and so what is
| displayed lacks the watermark. That would be crafty.
| kevindamm wrote:
| You could, but then it becomes even easier to capture without
| the adornment, practically defeating the purpose.
|
| You may be interested in watermarks that are invisible to the
| human eye but are visible to spectral analysis. You can even
| encode data within this invisible watermark, and learn a
| modification that is resistant to various image manipulations
| and even resistant to lossy compressions, in research that goes
| back to 2001 and has seen interesting improvements with
| advances in DNNs, Transformers and Diffusion.
| Lanedo wrote:
| It is not too surprising that many HTML or JS based watermarking
| schemes are very easy to remove, some even via a script. For
| watermarking schemes to be effective, the watermark payload needs
| to be embedded in the content. Here's one approach that works for
| images: https://github.com/tim-janik/imagewmark/
|
| Another that works for audio content is:
| https://github.com/swesterfeld/audiowmark
|
| Incidentally, the latter also supports applying the watermark
| payload to HLS segments.
| josephcsible wrote:
| If you're obfuscating code or writing anti-debugging logic, you
| are the bad guy. Stop trying to control other people's computers.
| Mindwipe wrote:
| To be honest if you are doing client side watermarking outside of
| a secure hardware enclave I'm not sure you expect any genuine
| robustness, because you obviously don't have any.
| miki123211 wrote:
| HLS feels like the best format to actually embed effective
| watermarks in.
|
| With a traditional "large-file" video format, this is non-
| trivial, as you need to reencode (or at least remux) the entire
| video for each user. This is not only computationally intensive,
| it also prevents you from hosting your videos on a CDN,
| increasing bandwidth costs.
|
| With a segmented format like HLS, you can just embed the
| watermark in a few key segments, leaving the rest of the video
| intact. As long as the user can't distinguish between watermarked
| and non-watermarked segments, you get most of the benefit at a
| much lower cost. Crucially, you can keep serving the non-
| watermarked segments off a CDN.
|
| This makes me wonder whether there are "segment-native"
| watermarking algorithms. The idea would be to pre-encode each
| segment multiple times, with each file containing a different
| watermark. A random variant of each segment would be chosen for
| each download, with the IDs of the chosen variants saved in a
| database. THe security of such an algorithm would rely on the
| combinatorial explosion resulting from the number of allowed
| variant combinations. For example, with just 3 variants per
| segment, 15 segments would give you 59 million distinct
| watermarks.
___________________________________________________________________
(page generated 2025-07-22 23:01 UTC)