CER10TY

"Should" is doing a lot of heavy lifting there. Most shops are a long way off from secure coding, and from my experience in the last 10 years most devs lack basic awareness of security. I still see people being surprised by OWASP Top 10 or simple things like trust boundaries.

There's no guarantee AI will find existing vulnerabilities proactively during coding, or that it won't introduce new vulnerabilities in the process of shipping features. You're right that shops _should_ be critical and test code, but I think due to the lack of awareness people will end up implicitly trusting any first pass written by AI and not bother to double check it.

Hence why I said the studies here are quite old, and I'd like to see something more recent, though I guess it'll be some time before that's done.

I think most people writing code with AI nowadays will find it's still lacking in some areas. Not because the model isn't good (definitely miles ahead than what we had access to in 2022-2023), just because it wasn't actively mentioned and so the model skipped over it. The same will apply to security.

Bold of you to assume that AI-written and -reviewed code doesn't introduce new vulnerabilities. I think after we're done with this stretch of finding human-made vulnerabilities, we'll have a long road ahead to clean up the mess that's introduced by AI.

It's been shown to be bad at secure coding _unless_ you specifically prompt models to watch out for common vulnerabilities, at which point they're actually quite good at containing the issues, though the studies here are somewhat older (eg https://arxiv.org/abs/2211.03622).

The issue then is that most people aren't actually good at keeping an eye out for security issues in code proactively, so things slip through the cracks (whether human-written or not), just at a much accelerated pace.

Say what you will about OpenAI, Wiz etc but if OpenAI, Wiz, Cloudflare, the PHP Foundation and pretty much every CERT out there together recommend to take down PHP apps and patch immediately then I'm very much inclined to follow that advice.

Due to the insane media coverage there'll of course be a deluge of PoCs, most of which won't work. But constantly refreshing Twitter to see whether there's a working PoC is not a good use of time nor a great security strategy.

To be fair, the warning to either take down websites or patch immediately on release came from the people who've been working on this for months (or those with advance notices like CERTs), not out of nowhere. People just took it down pre-emptively since exploit attempts (whether working or not) popped up in logs way before the patch was released, but it also took forever until the fix actually landed downstream after the advisories were released.

I think people are just latching onto the post that hit the front page earlier today about it being non-trivial to exploit, combined with the fact that there seem to be about a billion PoC out there, most of which don't work.

Are they, though? I seriously doubt some sysadmin is going to look at this and say "Maintainers said to patch, but clearly _this guy_ knows better, so I won't."

Besides, he's got a point. The initial PoC that kept popping up on Mastodon (the ones he linked in the post as well) simply didn't work. One of them even posted an updated exploit later that still didn't work, but supposedly meant the vulnerability went from CVSS 10 to CVSS 4.

Lots of places where Senior just means 3+ YOE and anything more than that has even fancier titles like "Staff" or "Principal".

„Let me ask my LLM“

Satellite Reign was fun. Not sure if I'd call 2015 _recent_ though :)

Hi HN,

Over the last few months, I invested pretty heavily into setting up SSO for my self-hosted stack. However, some apps gate SSO behind paid plans, meaning accounts and thus MFA need to be set up outside of the IdP. This leaves me with a weird mix of accounts handled by the IdP and those that I need to track manually.

There wasn't really a good way to track this mixture, especially once you add multiple MFA devices and sensitive data like recovery codes, because the IdP has one half and the password manager has the other (+ maybe it's the second factor itself).

That's why I built RecoveryCodes. It allows me to track all my accounts, see which MFA devices I've enrolled (I usually enrol 2 per account, in case one is lost) and also gives me a place to store recovery codes (instead of copy pasting them into a random .txt file).

Obviously I'm n=1, so I'm interested in hearing from slightly larger companies how you're dealing with this mix? Spreadsheets maybe, or are most of the accounts covered by IdPs and the rest don't really matter?

Does Cursor allow you to blacklist certain commands as well? I know OpenCode has this, where you can both whitelist things like grep/ls but then also blacklist things like cat .env, or rm -rf. I usually copy paste my configs nowadays, so I very rarely get prompted for any permissions (except when using Claude, which somehow decided that all users live in ~/Users, even on Linux)

Not a mobile dev so I'm leaning quite heavily on other people's experiences here.

It's my understnading that setting up cookies to work on mobile is quite painful, though it depends on the platform. IIRC iOS has gotten better at it with a shared cookie storage, but Android requests are still stateless by default, so you basically have to manually wire up a cookie jar and carry it around everywhere you go, so to speak.

Attributes like SameSite also behave differently, and WebViews don't share the same cookie jar as native requests as far as I understand.

Bottom line is that maybe "Cookies also don't work on mobile" is a bit of a wrong statement, but it's certainly more of a hassle and a path lined with more footguns than just wiring up an OAuth provider and sending access and refresh tokens back and forth using Authorization headers. The great thing with Session cookies on desktop is simplicity, which you sort of lack on mobile.

Cookies also don't work on mobile, so you inevitably have to maintain 2 different login flows.

But they're still the superior choice for authN on the web, because if you want to, you CAN configure cookies to be secure. Yes, attackers can ride the session, but it's dependent on the user being on the tab and you being able to consistently execute JS. Client-side compromise (ie attacker controls the entire browser) is not feasible to defend against anyway.

The main issue with JWT+localStorage is you can actually execute one-off JS, exfiltrate the token and come back later. I've _never_ seen a well-executed JWT+localStorage implementation in 10 or so years, because teams inevitably realise they can't reliably revoke sessions (another advantage of cookies) and then start giving out long-lived access tokens but adding them to the database. Or some variation of that.

They use Persona for their new "Trusted Access for Cyber": https://chatgpt.com/cyber, at least according to the FAQ

IIRC the creator specifically said he's not reviewing any of the submissions and users should just be careful and vet skills themselves. Not sure who OpenClaw/Clawhub/Moltbook/Clawdbot/(anything I missed) was marketed at, but I assume most people won't bother looking at the source code of skills.

It swings both ways though. I've seen plenty of older engineers dismiss the "new guys" effort and claim that everything had to be custom written, because there's no way a common framework like Django could cover their use case. The same type of engineer has never once worked with a common framework though, so they don't know what's included nowadays.

Turns out it's a lot easier to build on top of a common framework than do everything from scratch.

Only for public repos though - if you're in an org with private repositories you don't get access to them (yet).

Personally, I'd just use common sense and good judgment. At the end of the day, would you want someone to hand your address, and other private data to OpenAI just like that? Probably not. So don't paste customer data into it if you can avoid it.

On the other hand, minified code is literally published by the company. Everyone can see it and do with it as they please. So handing that over to an AI to un-minify is not really your problem, since you're not the developer working on the tool internally.

Presumably they'll threaten to sue you and/or file a criminal complaint, which can be pretty hard to deal with depending on the jurisdiction. At that point you'll probably start asking yourself if it's worth publishing a blog post for some internet points.

That's a good catch. I knew these flags existed, but I figured they'd require at least a human in the loop to verify, similar to how Claude Code currently asks for permission to run code in the current directory.

Personally, I'd expect Claude Code not to have such far-reaching access across my filesystem if it only asks me for permission to work and run things within a given project.

Talk to people outside tech. Lots of small problems worth solving, but not in tech. Also, just because it's a problem in someone's day to day won't mean they'll pay to fix it.

Good luck!

Isn't that pretty much how every "Trusted by these companies" marketing badge works nowadays?

Or, far more likely, they'll reach out to someone in their network. To land in that network, you have to market your services. LinkedIn is somewhat useful for that, but less so nowadays.

I guess the thinking goes like this: Why start a business, get a higher paying job etc if you're getting ~2k€/mo in UBI and can live off of that? Since more people will decide against starting a business or increasing their income, productive activity decreases.