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.
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.
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.
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.
That takes 2 seconds. But the PO usually expected a detailed breakdown of what went well or bad and what could be improved right then and there. Simply saying "Yeah, I'm doing X, still doing it, bye" would be bad, because you're also not inviting _collaboration_.
We were 5 people total - PO, Scrum Master, 3 devs. Been years since I was in that team but it was expected that everyone would give a lengthy update about the previous day
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.