I'm not sure how I'd do acceptance/E2E testing without the magic of port 0. As long as you have a way of capturing what port it ended up using (which most languages are able to out of the box more or less), parallelizing testing workloads becomes such a breeze without having to manage ports and all that jazz, just fire everything up with N parallism and let the OS figure out what the free ports are, pass the references down and stuff just works. Thanks Linux :)
We have something similar in Spain, except instead of "comparable rentals in the area" there is a index (called IRAV (Índice de Referencia de los Alquileres)) maintained by the government each year, which limits how much rents can be increased. My landlord just reference that each year, it's easy for me to check if it's right, then that's it. For the areas where supply is limited ("áreas tensionadas"), as some areas like Barcelona is geographically limited to expansion, there is a total limit as well, independent of the IRAV.
Of course, if there are improvements in the rental, you can go beyond the index as the property been "improved", but it's really handy to know each year that it's limited and the exact amount. For 2026 it's locked to 2.14% for example, for everyone.
What return path could possibly lead to a RCE? That's crazy, no telemetry requires "backend could return any command that gets run on the client", you're doing telemetry in a very non-standard way if this is even possible.
At worst, the telemetry backend might first send the client a config, but none of that would contain executable commands because again, that'd be crazy.
> we cannot absolutely claim that browsers don’t have RCE(s).
Of course, you can never prove the absence of bugs (and/or security issues), but given that browsers aren't wildly exploited at this very moment, nor have been for quite some time, we can pretty confidently claim there are no browser RCEs in wide use today.
It's true that browsers have pretty big attack surface, but it's also true that it's the class of software that gets the more pentesting, since the payoff would be so great when you manage to find holes.
API protocol says “return value is either “OK” or “ERR””, attacker sends “Floccinaucinihilipilification”, overflowing the 3-byte response buffer allocated on the stack.
I'm sorry, but I still find it hard to believe you work with other professionals that when they implement telemetry in client applications, that usually ends up exposing a RCE on the client because of the telemetry implementation.
> But a team of SWEs at different experience levels for the same role won't be different job descriptions.
Why would you put people with different experience levels in the same role? You'll have three classes of people, only one of them "happy", for the others it'll be too much or too little. You cannot put a junior in the same position as a person who wants to be tech lead?
I think maybe I'm misunderstanding what you're saying, because having one job description for those three roles don't make much sense as I understand it currently.
I'm probably not explaining myself well, but besides from FAANGs that use levels, this is how every company i've worked at does thing.
We need a team of X people, we have minimum requirements. We are open to anyone as long as they are close to the requirements (100% match is never possible).
We evaluate the comp based on interview feedback... then as the team gets filled what we look for starts to narrow to "fill out the bench" so to speak.
But we won't ever go back and update the description or pay-band, no need.
> "Open banking" is kind of a thing with PSD2/PSD3, but in name only. In reality, it's impossible to build anything useful
You mean the step from sandbox to production application, or you're not even getting access to the sandbox itself? I managed to get sandbox access with ease via two separate banks (both Spanish though), with no problems, think it took them one (working) day or something to review my "application". I never tried to get anything into the production environments though, but makes sense they'd be a bit tighter on that tbh.
Not sure why you'd claim it's impossible, it's in wide use already by banks, fintech and payment service providers across the union.
I'd go out on a limb here perhaps, but I'd claim that if your telemetry means that the one SENDING the data gets a RCE by default by it, you're doing telemetry very wrong. Maybe look into different libraries/services than the ones you use today, please.
> helps to protect your computer from dangerous commands that your ai agent might execute
How does "a local audit of what your coding agent did and why" help prevent dangerous commands? Sounds like your solution comes too late, innit? Sure, I can see that at 16:48 the agent ran "rm -rf --no-preserve-root" but if it already executed it on my personal computer, isn't it too late then?
Personally, I think this solves the wrong problem. If you're one stray "rm" away from letting the agent delete stuff on your personal computer, you're running the agent harness the wrong way. At least give it its own user, ideally limit what paths/network it can use, but don't rely on "auditing" to prevent dangerous commands, it'll bite you in the future.
You are correct, but it's generally very hard to come up with good access control policies up front. Also, as you grant more access the system tends to become over-permissioned over time, and often you don't really find out until so wrong that it hurts. The ability to audit is necessary to maintain good policies. It allows you to discover gaps in your policy even when things didn't break terribly.
You’re right
the command from my comment only generates a report and doesn’t actually prevent anything. stroq init sets up hooks that prompt for confirmation before a dangerous command is executed—but that’s a filter, not a sandbox
I have received two pre-interview repos from recruiters on LinkedIn (NK hackers targeting crypto people), and both would be hard cases for this. Almost all offers there in DMs are now fake recruiters, and it's not trivial to figure out if the account is fake.
One had an eval() hidden inside a controller function named getCookie(), running whatever a remote server sent back. npm start, npm build and npm test all triggered it. Cursor didn't catch it when I asked "is this repo safe to run?" and then told it to check all dependencies.
Other one came as a bunch of Solidity files in a zip file with an issue to resolve as the interview task, nothing suspicious at first sight. However, that zip carried the whole .git folder, hooks included, which a git clone never copies, and the folder is hidden by default in Finder. Of course, there was a hook that fires on any commit or push, again eval() on some remote address.
In both cases the agent only runs npm test or git commit. Would Stroq see anything in these situations?
to be honest, in the first scenario, the hook will only detect 'nom test' command itself. in the second scenario 'stroq inspect' will identify the hook before the folder is opened and issue a warning. thanks for these examples :) I'll use them to improve product
Such a shame they ended up enlarging that series just like every other phone out there. I had the first generation of Moto G all the way up to 6 or 7, when they made it too large for my hands.
I'd probably kill someone (bad) for the 3rd generation Moto G but with modern specs.
reply