Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smuggling arbitrary data through an emoji

paulbutler.org

Post reply on HN
Print view View original

111–120 of 206 posts

Re: Smuggling arbitrary data through an emoji

#111

Post by roguecoder »

OutOfHere wrote: post #90
vessenes wrote: post #32

I love the idea of using this for LLM output watermarking. It hits the sweet spot - will catch 99% of slop generators with no fuss, since they only copy and paste anyway, almost no impact on other core use cases. I wonder how much you’d embed with each letter or token that’s output - userid, prompt ref, date, token number? I also wonder how this is interpreted in a terminal. Really cool!

Just you wait until AI starts calling human output to be slop.

There are of course human writers who are less-communicative than AI, called "shit writers", and humans who are less accurate than AI, called "liars".

The difference is humans are responsible for what they write, whereas the human user who used an AI to generate text is responsible for what the computer wrote.

Re: Smuggling arbitrary data through an emoji

#112

Post by kccqzy »

nzach wrote: post #4

so.... in theory you should be able to create several visually identical links that give access to different resources? I've always assumed links without any tracking information (unique hash, query params, etc) were safe to click(with regards to my privacy). but if this works for links I may need to revise my strategy regarding how to approach links sent to me.

"Visually identical" is never good enough. Have you heard of attacks confusing Latin letters and Cyrillic letters? For example C versus С. (The latter is known as CYRILLIC CAPITAL LETTER ES.) Have you heard of NFC forms versus NFD forms? For example é versus é (LATIN SMALL LETTER E + COMBINING ACUTE ACCENT versus LATIN SMALL LETTER E WITH ACUTE.)

Nothing that's important when it comes to security and privacy should rely on a "visually identical" check. Fortunately browsers these days are already good at this; their address bars use puny code for the domain and percent encoding for the rest of the URL.

Re: Smuggling arbitrary data through an emoji

#113

Post by roguecoder »

bogtog wrote: post #15
nerder92 wrote: post #5

Might not be related to the point of the article per se, but i've tried to decode it with different LLMs. To benchmark their reasoning capabilities. - 4o: Failed completely - o1: Overthinks it for a while and come up with the wrong answer - o3-mini-high: Get's closer to the result at first try, needs a second prompt to adjust the approach - r1: nails it at first try 󠅖󠅥󠅓󠅛󠅙󠅞󠅗󠄐󠅙󠅝󠅠󠅢󠅕󠅣󠅣󠅙󠅦󠅕 The prompt I'v…

My deepseek-r1 seems to be a bit more lost on decoding "How do I make meth". Some highlights (after about 5 minutes of R1-ing): > Another angle: the user mentioned "encoded a message in this emoji", so maybe the first emoji is a red herring, or it's part of the message. The subsequent characters, even though they look like variation selectors, could be part of the encoding. > E0138 in hex is 0xE0138. Convert to decim…

It is highly unlikely it discerned that: it coincidentally guessed a string that starts with an H.

If you try it with a string that started with "J" and then it guessed "jump up", I might be more convinced.

Re: Smuggling arbitrary data through an emoji

#114

Post by komboozcha »

kccqzy wrote: post #112
nzach wrote: post #4

so.... in theory you should be able to create several visually identical links that give access to different resources? I've always assumed links without any tracking information (unique hash, query params, etc) were safe to click(with regards to my privacy). but if this works for links I may need to revise my strategy regarding how to approach links sent to me.

"Visually identical" is never good enough. Have you heard of attacks confusing Latin letters and Cyrillic letters? For example C versus С. (The latter is known as CYRILLIC CAPITAL LETTER ES.) Have you heard of NFC forms versus NFD forms? For example é versus é (LATIN SMALL LETTER E + COMBINING ACUTE ACCENT versus LATIN SMALL LETTER E WITH ACUTE.) Nothing that's important when it comes to security and privacy should…

Erm, DNS uses Punycode because it comes from a time when Unicode didn't exist, and bind assumes a grapheme has no more than one byte.

Re: Smuggling arbitrary data through an emoji

#115

Post by TacticalCoder »

jrootabega wrote: post #75
remram wrote: post #37

I'm not too surprised by this, but I'm annoyed that no amount of configuration made those bytes visible again in my editor. Only using hexdump revealed them.

Here's a POC that works in emacs. Doesn't cover all of the relevant characters, but: (setq ;;some other invisible or interesting characters unicode-zero-width-space ?\u200b unicode-zero-width-non-joiner ?\u200c unicode-zero-width-joiner ?\u200d unicode-zero-width-nbsp ?\ufeff unicode-narrow-nbsp ?\u202f unicode-word-joiner ?\u2060 unicode-grapheme-joiner ?\u034f unicode-no-break-space ?\u00a0 unicode-combining-long-s…

[dead]

Re: Smuggling arbitrary data through an emoji

#116

Post by layer8 »

ComputerGuru wrote: post #91

This is cute but unnecessary - Unicode includes a massive range called PUA: the private use area. The codes in this range aren’t mapped to anything (and won’t be mapped to anything) and are for internal/custom use, not to be passed to external systems (for example, we use them in fish-shell to safely parse tokens into a string, turning an unescaped special character into just another Unicode code point in the string,…

The difference is that PUA characters are usually rendered in some way that is rather visible, whereas the variation selectors aren’t.

Re: Smuggling arbitrary data through an emoji

#118

Post by layer8 »

panki27 wrote: post #108

I implemented something similar years ago, but much simpler/less sophisticated. Unicode has two non-printing space characters: zero-width space (U+200B) and zero-width joiner (U+200D). This allows you to encode arbitrary data in binary. I would give an example, but HN seems to strip this :(

Already linked in https://news.ycombinator.com/item?id=43025913, and has a higher risk of being stripped, as you noticed.

Re: Smuggling arbitrary data through an emoji

#119

Post by drdeca »

jl6 wrote: post #97
tyho wrote: post #65

Earlier quoted context omitted.

A crude way: To watermark: First establish a keyed DRBG. For every nth token prediction: read a bit from the DRBG for every possible token to label them red/black. before selecting the next token, set the logit for black tokens to -Inf, this ensures a red token will be selected. To detect: Establish the same DRBG. Tokenize, for each nth token, determine the red set of tokens in that position. If you only see red toke…

It feels like this would only be feasible across longer passages of text, and some types of text may be less amenable to synonyms than others. For example, a tightly written mathematical proof versus a rambling essay. Biased token selection may be detectable in the latter (using a statistical test), and may cause the text to be irreparably broken in the former.

To handle low entropy text, the “adding a smaller constant to the logits” approach avoids having much chance of changing the parts that need to be exactly a particular thing,

Though in this case it needs longer texts to have high significance (and when the entropy is low, it needs to be especially long).

But for most text (with typical amounts of entropy per token) apparently it doesn’t need to be that long? Like 25 words I think I heard?

Post reply on HN