How is this a replacement for LangSmith? I browsed the source and I could only find what appear to be a few small helper functions for emitting structured logs.
I’m less familiar with LangSmith, but browsing their site suggests they happen to offer observability into LLM interactions in addition to other parts of the workflow lifecycle. This just seems to handle logging and you have to pass all the data yourself- it’s not instrumenting an LLM client, for example.
I’m curious why there appears to be a pretty significant delta between their data and yours.
Also, if you’re open to suggestions, I had trouble finding the pricing for gridstatus. Entirely possible I was missing something obvious, but I wanted to see how much it might cost to get the long term Ercot generation-by-source dataset and couldn’t seem to get a clear answer.
Regardless, building things like this takes a ton of effort, and I appreciate all you’re doing. Keep up the great work!
Congrats on the launch! Could you expand a bit on how you differentiate your product from other products in the space like Tailscale and Nebula?
Edit - I see you mention that Tailscale uses userland WireGuard. Is that the biggest difference between the two? Do you foresee yourselves running into issues by not using the userland implementation?
> - Healthcare staff have great animosity towards the unvaccinated patients.
In addition to this, I’ve also heard anecdotally that many of the unvaccinated (by choice) patients have animosity towards the healthcare workers themselves because the patients see this virus as politicized.
Overall I can imagine that it’s resulted in a more-hostile-than-average working environment which is bound to be stressful.
That's the thing. If we're watching syscalls, we see these checks. These would be things like attempted file-reads. Would they be enough to set off alarms? Maybe, maybe not.
This is generally the cat/mouse game of malware detonation in general. There are attempts to make sandboxes appear realistic, but I'd argue that our use case is even simpler since running commands or making network connections during installation is not a normal thing. It might be benign, but it's abnormal enough to warrant investigation.
There will always be ways to try and get around the system, but I'm pretty firm that this will significantly raise the bar which is a Good Thing.
1) The “observable window” is the entire installation time. If they make installs take forever, that’ll affect everyone which should raise alarms pretty quick.
2) The conditional execution is possible but the installation is done using a vanilla alpine container which will match many legitimate hosts too. And any fingerprinting activities that involve syscalls would be detected in the process.
All this to say, there’s always room to continue raising the bar!
I've been in touch with folks from the Open Source Security Foundation [0] who is interested in making this a centralized service.
I'm a big believer that functions like this should be centralized under a foundation like that, and have really close connections to package manager maintainers so that we can work together towards solving the problem.
You almost certainly don't need a web framework. Over the long term, it's easy to find yourself boxed in with how opinionated many of them are.
Instead, if you build on the standard library, you can compose your application from there- a good muxer, some standard middleware that are generic http.Handler's, a session library, etc.
This is a scam that has been going on for years that has adapted its techniques over time.
We used this botnet as a case study back in 2018 when doing analysis on finding Twitter bots at a large scale. You can find the paper here [0] - the cryptocurrency scam botnet starts on page 28. You can also find the talk here [1] where we go into a little more detail. In full irony, someone tried sharing our research on Twitter, and one of the bots replied to the thread trying to spread the scam.
> S2 Systems NVR technology intercepts the remote Chromium browser’s Skia draw commands, tokenizes and compresses them, then encrypts and transmits them across the wire to any HTML5 compliant web browser (Chrome, Firefox, Safari, etc.)
Nice! I did the same recently, where I requested my data from 14 different location data companies. [0] One company returned my data. Part of the difficulty was making the CCPA requests since I live in Texas, but the majority of responses were along the lines of having no way to identify the person behind the device identifier.
I love seeing comics like this that aim to show concepts in simple ways. Kudos!
Worth noting that "The Handshake" episode [0] covers the key exchange using RSA. This has the downside that it doesn't support forward secrecy, meaning if an attacker ever compromises the server's private key they can retroactively decrypt traffic they previously captured.
It's more common these days to use an ECDHE exchange in which the client and server exchange keys that are generated just for this session (or at least, they should be [1]) and use those to generate the "shared secret".
In fact, in TLS 1.3 ECDHE is the only key exchange mechanism. [2]
The server then uses its long term keypair corresponding to the certificate to sign all the handshake messages that were seen previously [3].
I’m less familiar with LangSmith, but browsing their site suggests they happen to offer observability into LLM interactions in addition to other parts of the workflow lifecycle. This just seems to handle logging and you have to pass all the data yourself- it’s not instrumenting an LLM client, for example.