[revenz]

One reason nefarious people would use this is to gain verified account name information. Get enough of those and there are bound to be some passwords that are easily brute forced.

Furthermore as the article states blizzard could use this to track private servers.

[cheald]

You now log in to your accounts with your email address, so account discovery is something of a moot point.

[Contero]

What I don't understand is why the screenshot would contain your literal realm id, and not a hash that only Blizzard could understand.

As long as Blizzard is the only party that can glean meaningful information from these watermarks I see no problem with it.

[ef4]

A hash isn't really the right construct for that purpose. If Blizzard just produced a salted hash of user_id & realm, it would be pretty expensive for them to reverse it, even given possession of a complete list of user ids and realms. If they didn't salt it, they could keep one big "rainbow table", but then again so could anyone else.

What you'd really want is encryption. If you chose symmetric encryption, the key would be in every client (easy to steal). If you chose asymmetric encryption, the message would suddenly get much, much bigger to the point where it's harder to reliably encode in a screenshot.

[Contero]

You're over engineering this I think. The "hash" only needs to be an internal account id that can be plugged into Blizzard's database to get your account info. No encryption is necessary. There is no way to get a mapping of internal code to account info without their database.

[shenberg]

The data wouldn't get much bigger - a 2048-bit RSA key requires the output to be at least a 256-byte block, roughly 3 times as much data as the current watermark has, not some insane amount of data. The watermark is repeated many many times in the image anyway, so it seems like the trade-off could be made between less copies of the watermark and more data in it.

[makomk]

Current speculation is that most of the 88 bytes of data in the existing watermark is an error-correcting code that hasn't been reverse-engineered yet, so in practice it has less actual non-redundant data than that.