MajesticHobo2

It's not. Or if it is, it's unclear. The article seems more focused on the integrity of remote development servers and deployment targets:

> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.

> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.

Is it? I've read the article twice (yesterday when you posted it and last year when it was first published), and that was not my interpretation.

This part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.

That is a linear growth problem whose answer is very easy to intuit.

You also don't want adversaries to be able to disrupt long-lived streams with bad password guesses, since I think part of Wormhole's security model is it will terminate the session if the other side gets it wrong.

They say it's rate-limited, so at least it probably won't scale to large botnets or similar...

notabug wontfix; that's the end-to-end principle in action. Bring your own all of that.

Browser sandboxing is now fully solved.

It's the same style I see on Twitter and LinkedIn a lot.

Why does it have to be deliberate? It's not surprising that people exposed to output from LLMs will unconsciously pick up their linguistic habits.

I'd say also add a test that shows the HTML injection (which spurred the PR) isn't possible. Given an attacker-controlled URL of:

    foo onclick

the following shouldn't render:

    <a class="item muted sidebar-item-link" href=foo onclick>

The following should:

    <a class="item muted sidebar-item-link" href="foo onclick">

It was definitely partially about model quality. The frontier models are capable of producing valid findings with (reasonably) complex exploit chains on the first pass (or with limited nudging) and are much less prone to making up the kinds of nonsensical reports that were submitted to curl. Compared to now, the old models essentially didn't work for security.

If those script kiddies had been using today's models instead and _still_ didn't do any filtering, a lot more of those bugs would have been true positives.

> With decompilation I think there's a higher risk of it missing the intention of the code.

I'm not sure but suspect the lack of comments and documentation might be an advantage to LLMs for this use case. For security/reverse engineering work, the code's actual behavior matters a lot more than the developer's intention.

That was then, this is now. The new models are scarily good. If you're skeptical, just take an hour to replicate the strategy the article references. Point Claude at any open-source codebase you find interesting and instruct it to find exploitable vulnerabilities. Give it a well-defined endpoint if you want (e.g., "You must develop a Python script that triggers memory corruption via a crafted request") and see how well it does.

Third or fourth, maybe, not first.