CER10TY

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.

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

I‘m long gone from that team (thankfully). But hey, the Scrum Master was certified, I‘m sure it‘s all proper /s

Props to you if you manage to follow this and squeeze it into 15 minutes. I‘ve genuinely never had a daily last less than 60 mins.

The issue is that it‘ll absolutely _suck_. If I tell Claude Code to scaffold a web app from 0 outside of React it‘s terrible.

So no, imho people with no app dev skills cannot just build something over a weekend, at least something that won‘t break when the first user logs in.

It‘s easier, since you don‘t have to stare at your monitor for 4 hours straight. But still, people expect availability since you‘re paid for 8 hours.

That‘s corporate jobs for you. It‘s about appearance, not results. That‘s why you make a big deal out of everything you work on.

SEEKING WORK | Germany | Fully Remote

I help startups implement secure API architectures through audits, strategy development, or ongoing support. As a solo consultant with 10 years of experience across startups to enterprise, you work directly with me (no junior handoffs). My goal is to enable your team to develop secure APIs independently, not create long-term dependency.

My website has more info: https://www.soeren.codes/

You'll find additional contact info there as well - feel free to reach out!

Just remember to go through your commit history if you ever plan on making that repo public.

With the new API for GPT-4o image gen releasing soon, we'll probably see a wave of hype products (ie "generate your own Studio Ghibli-style photo album"). I expect these will die down rather quick, but first mover advantage should still net you some profit here.

Which country is your company based in? And which countries are you selling your services to?

Legal/tax things are always different in every country. B2C also makes things a lot more complicated. Overall, lots of sharp edges to look out for.

Would you recommend moving from Google Workspace to Proton? Including emails and so on.

What's a good alternative to Proton? Still haven't migrated my business away from Google Workspace, and I was thinking Proton would be a good alternative, but apparently not if they don't even support IMAP/SMTP.

This happened to plenty of people with Stripe as well.

Doesn't mean Paddle isn't a good place to start - but as you get bigger, you should probably look at other solutions as well, to de-risk your payments infra. It's just that at the start it's too expensive, even in B2B, to think about multiple payment providers to spread risk.

Considering the PCLOB has lost some of its members, it's questionable whether the DPF can continue to exist in its current form. If it does go out the window, then Trump won't need to tell AWS/GCP to stop doing business with the EU, since European companies wouldn't legally be allowed to transfer data to US companies anyway.

I expect the EU commission will take a _very_ long time to actually act on this tho. Maybe we'll see Schrems III first.

That doesn't really work as long as you have legislation like the CLOUD Act, which means EU-based businesses have to think twice about using any US providers, especially if they handle sensitive customer data and also since the DPF is on the way out.