Congratulations, don’t use Ghostty or terminals built on top of libghostty and you don’t have to!
I wouldn’t mind OSC8 so much if it had proper security auditing but it doesn’t. The whole thing was pushed by one guy on a GitHub gist who blocked anyone who dared discuss security issues.
At least with browsers, you have masses of people testing these things. But there’s no rigour to any of the tests that happen with terminal emulation. Let alone independent security audits.
And at this rate, it’ll only be a matter of time until we see “don’t cat untrusted READMEs” advice because they might contain boobytrapped escape codes. Which is an absurdly bad place to end up.
So far I can only think of 1: term vulnerabilities due to ANSI escape sequence parser bugs. And that’s exactly the reason I’m suggesting OSC8 should be off by default.
I know you’re trying to disagree with me, but you’re ostensibly raising the same core concerns that I am. :)
I honestly hate escape sequences. I even experimented with building entirely new control plains for the term I’d written. But then who’s going to use it if you don’t also support escape sequences. And so you’re back to original problem again.
The one good thing about these escape sequences was that they only controlled the display. Almost everything that controlled the window behaviour (bar the window title) had dropped out of favour. But things like OSC8 reintroduce behavioural changes that can surprise unexpected users and opens the terminal to whole new forms of abuse by misbehaving input.
If you think back to the HTML analogy; how many times have we seen exploits abuse mouse click events? And these browsers have several orders of magnitude more funding in development and security testing. So what hope do we have that hobby project terminals will even come close to the same level of security despite being used to manage arguably more sensitive systems?