I found the general premise of the tools (in particular LangGraph) to be solid. I was never in the position to use it (not my current area of work), but had I been I may have suggested building some prototypes with it.
I think there are probably lots of thorough critiques, but for me it boiled down to this:
Langchain claimed to be an abstraction on top of LLMs, but in fact, added additional unecessary complexity.
Prompt management was such a buzzword when langchain came out, but 99% of LLM use cases don't need prompt management - GitHub and strings works just fine.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.
>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.
>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.
So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.
I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).
I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.
In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).
Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.
Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.
I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard.
This is unacceptable and the amount offered in general is low. It feels like we can agree on this.
I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.
I was under the impression that the security concerns there are handled by AppArmor and SELinux (though maybe not granular access control to secrets). Which all desktop Linux installs should be using one or the other, because there's much more than just D-Bus that can be a security risk.
TS decision to choose Go was primarily, because they could take the existing code and do a near 1-1 translation. You can frame that as an architectural concern, but it's really only one that applies when your attempting to migrate an existing program to a new language. The Go rewrite has some negative outcomes as well, most concerning is the performance of the WASM builds is worse than the old JS/TS version.
A TS compiler from scratch built in Rust would be fine.
> You can frame that as an architectural concern...
"Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management."
"The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. "
If memory management and ability to handle complex graph processing efficiently isn't related to architecture to you I don't know what to tell you.
> If memory management and ability to handle complex graph processing efficiently isn't related to architecture to you I don't know what to tell you.
Rust can do complex graph processing, as well as efficient easy memory management, but it's going to do it in a different structure than a GCed lang would. Hence my statement that 1 to 1 translation was the primary factor.
> CTRL+F "rust" on the Go issue and see how many results you get.
Yes and so what? There's 35 for .NET or 74 for C#, yet you don't see people claiming the C# cult was harassing the TS team.
Sure, and Rust is the most used language for modern TS/JS tooling, outside of TS/JS. There would have been substantial ecosystem benefits had Rust been chosen.
Success isn't a binary thing. It's true that Servo has long struggled to make progress, and that can be seen as a failure. It's recent progress can also be seen as a success.
Your life might improve if you stop believing that Rust devs belong to a cult of your own imagination.
Measuring success of a project against a bar that the project didn't set is like complaining that an F1 car is hard to park: that's not what it was meant to do.
Servo was meant to be a test-bed for new architectures that might or might not be usable by Firefox. It was never meant to become Firefox' new web renderer, and it wasn't until more recently and long after the Mozilla-pocalypse that a new team took over the project with a goal of productionalizing the project as a whole. Stylo, for example, was integrated into Firefox 57 and allowed for parallel CSS style calculation, an effort that was tried unsuccessfully multiple times in C++.
Excessive social media is detrimental (to everyone). Age restrictions are not a good solution, it effectively categorises it as an adult activity, and glorifies it further.
Kids are very good at identifying hypocritical behaviour and scare tactics. It'll end up counterproductive like the D.A.R.E. program.
If the kids are forced out, the adults should be too.
It was a big mistake to leave Jony Ive in charge of design after Steve Jobs left. Jobs had a good design sense that was key to grounding Ive's work.
Ive's vision of Apple as a luxury brand certainly aligned with Cook's focus on profit, and the results of that sadly still echo through the company today.
Wouldn't the implication of them being "opposite" be that in some sense they are mutually exclusive? I don't really see evidence of that. Your example of sensory input vs world model weight is a bit flawed, because both of those are extremely multifaceted. One can have extreme weight in sensory input in one sense but not others, as well as extreme weight on world model for certain aspects of life.
I found the general premise of the tools (in particular LangGraph) to be solid. I was never in the position to use it (not my current area of work), but had I been I may have suggested building some prototypes with it.
reply