This article shows a couple of interesting zero-width characters techniques for the invisible fingeprinting of text.
In early 2016 I realized that it was possible to use zero-width characters, like zero-width non-joiner or other zero-width characters like the zero-width space to fingerprint text. Even with just a single type of zero-width character the presence or non-presence of the non-visible character is enough bits to fingerprint even the shortest text.
I also realized that it is possible to use homoglyph substitution (e.g., replacing the letter “a” with its Cyrillic counterpart, “а”), but I dismissed this as too easy to detect due to the differences in character rendering across fonts and systems. However, differences in dashes (en, em, and hyphens), quotes (straight vs curly), word spelling (color vs colour), and the number of spaces after sentence endings could probably go undetected due to their frequent use in real text.
The reason I’m writing about this now is that it appears both homoglyph substitution and zero-width fingerprintinghave been discovered by others, so journalists should be informed of the existence of these techniques.
Software development is never just about writing code. Programming is only a small part of the software development work. The rest touches and intervenes with a whole lot of other areas – documentation, support, testing, marketing, and so on and so forth. Recently, Slashdot ran this story on the art of writing release notes. There are a couple of links from the story to this article on IEEE and this on TechCrunch.
These provide a lot to think about, at least for someone who wrote nearly 300 release notes just this year alone (yeah, we had to catch up on historical releases).
I’ve been a fan of Jeff Atwood’s writing on Coding Horror for years. But it was mostly about technology and programming. Today, I was reading through his review of a video game – Player Unknown’s Battlegrounds – and for the first time in a really really long time, I wanted to download it and start playing even before I finished reading his post.
That reminded me of how gaming reviews and guides were done back in the 90’s – not by professional content managers and editors, but by people who had a passion. Learn from that, the gaming industry. Learn from that, everyone else!
“Google Developer Documentation Style Guide” is a guide for Google developers on how to write the developer documentation. As someone who have been involved in technical documentation for years now, I find a general lack of such guides from other companies interesting and slightly disturbing.
Kudos to Google for the effort and for sharing with all of us who are trying to improve the technical writing.
The Daily Post blog which I mentioned a few times before has started yet another rather useful thingy – a series of posts on how to become a better photographer. Here is the first post, and it’s rather good. There are not too lengthy explanations, bullet point summaries, and, of course, excellent images.
There are several common misconceptions about photography: it’s about art, it’s about light, it’s about subject. All of those things are true, but even before all of that, it’s about people and psychology. (Even photographs that have no people in them!) The photographer makes an interpretation of the scene/subject; on the other end, the viewer makes another interpretation. The very best photographs and photographers convey their ideas cleanly to the end viewer, while still leaving room for imaginative interpretation. This means that to make a good image, you need to be able to recognize one.
Back when photography was one of my primary hobbies, I read a lot of articles, books, and forums. Writing like that is rare. Simple, yet concise language. It’s almost like someone is just talking to you.