Lockdown Compat: Hardened TextDecoder instance with nodejs fast path (eg ascii encoding)

[kumavis]

Describe the bug

Seems like a nodejs + override mistake compat issue.
When using a hardened textDecoder with ascii encoding, there is an error on certain platforms.

harden(new TextDecoder('ascii', { fatal: true }))

Cannot assign to read only property 'Symbol(kLatin1FastPath)' of object '[object TextDecoder]'

Steps to reproduce

1. lockdown
2. make textDecoder with 'ascii' encoding.
3. harden the textDecoder
4. decode text buffer

lockdown()
t = harden(new TextDecoder('ascii', { fatal: true }))
t.decode(Buffer.from([]))

// SES_UNCAUGHT_EXCEPTION: (TypeError#1)
// TypeError#1: Cannot assign to read only property 'Symbol(kLatin1FastPath)' of object '[object TextDecoder]'

Expected behavior

No error

Platform environment

Nodejs versions checked:

20.18.0 🟢
20.18.2 🟢
20.18.3 ❌
20.19.0 ❌
20.19.1 ❌
20.19.2 ❌ (latest v20)
21.0.0 🟢
21.7.3 🟢 (latest v21)
22.0.0 🟢
22.15.1 ❌ (latest v22)
24.0.0 ❌
24.0.2 ❌ (latest v24)

Additional context

https://github.com/nodejs/node/blob/b395420a99fff9e59256a66437762cbdacd44cb7/lib/internal/encoding.js#L424

Attempted a workaround by warming up the textDecoder (decoding once) before harden, but harden still broke further use of the text decoder

[kriskowal]

Do we see the same with utf-8? The only web-portable use of Text* is utf-8. If we want to transcode ASCII, we would need ponyfill, to fall back to lifting the low seven bits of a Uint8Array and plopping them into a string, like String.fromCharCode(...byteArray.map(assertAscii)).

[mhofman]

We may need a mitigation like for async_hooks symbols. Or try to provide an upstream patch to fix this madness (like we partially did for async_hooks). Would be good to see what commit introduced this regressions and file a bug.

[mhofman]

According to git blame of the provided line, the culprit is nodejs/node#55275

[mhofman]

It mentions that there is a similar fast path for utf-8, which doesn't seem to differ at first glance. Do we know if that's broken as well?

[mhofman]

I actually don't understand how we're tripping this up. The only place where the symbol is potentially modified is when calling decode with a options.stream param, which the repro doesn't seem to need.

Regardless, this is potentially a footgun for that case, and the async_hooks workaround would apply:

• create a TextDecoder instance
• grab its own symbols
• add accessor props on the TextDecoder prototype that use a weak map to store the value of this flag. Maybe only support an implementation that can trip it one way to avoid unbounded 1-bit communications through this (I don't remember if a TextDecoder instance claims to be observably state-less)