Hacker News Reader

Comment by jarnix | Hacker News Reader

Watermarking in the browser seems counter productive though.

I can see how it might be counterproductive to do this live in the browser, as someone with an ounce of technical skills can find your un-watermarked images.

But using this to generate a watermark and upload it to somewhere like S3, to then display on pages is pretty sweet.

For instance, this might be utilized by a CMS plugin to support uploading images, watermarking them, and shipping them off to the cloud.

If there is a way of saving the result and posting it to the server (caveat: I have no idea if there currently is, there almost certainly isn't in a "95 of web users will have a compatible client" sort of way) then you could use this to remove some CPU load when accepting images that you want to watermark before presenting to other users. If it is your image being watermarked you are unlikely to circumvent the process.

Yes. Absolutely. The library includes a blob() function for converting a watermarked image to a blob for use with FormData. The site has a demo that does just this for uploading to S3. Any browser supporting File API, FormData, and typed arrays should have no problems. IE 10 is the earliest IE that supports these APIs out of the box, but there are polyfills for IE9. The other modern browsers have supported these APIs for a while now.

Interesting. I didn't realise those things had progressed so far into "generally stable and usable" territory client-side - an occupational hazard due to most of our clients being stuck on IE8 so I only play with less ancient "standards" when I find time for projects outside the day-job. I really need to try arrange some proper play time for myself soon!

How so? Being able to generate watermarks in the browser is one less thing a server has to do right? Especially if that server is in a shared environment without image libraries or lacks tools for uploading things concurrently.

It defeats the point of watermarking since someone with the technical skills can just recover the non-watermarked image.

I think the point is to create watermarked images in the browser for later use. Once that's done, you only show users the watermarked version. This is for administrative use, not end-user presentation.

Watermarking by urls or existing images would leave the non-watermarked image open - you are correct. This case is still fine for most users, but watermark.js also allows the use of file inputs. You can grab an image from a file input, then watermark, then upload it. This would leave the non-watermarked image closed off to anyone else. This would be handy if you need to generate watermarks in a CMS backend or some other administrative tool

Anything that happens client-side is out of your hands.

An potential image thief could just make his browser not run the watermarking function if he wanted. What we are essentially doing here is handing the image thief an image, and then handing him a watermark, and then telling him to watermark the image himself (with no guarantee that he will actually do so).

Reply on news.ycombinator.com