That's our thinking with auto-fix - no matter how good are findings or warnings, or modals blocking publish, some apps will still do it. We work hard on promoting auto-fix, and free fix-all functionality so that users do not hesitate to use it.

Seriously?

Was my reaction then I remembered the world of tech as it currently is and was both not surprised and yet still disappointed.

This is the new future, I'm just not sure I want to be part of it.

It’s really disheartening and disappointing to see how little you can take ownership of Lovable’s part in this. This post doesn’t say “disparate, unconnected apps expose passport details.” These are lovable apps, your apps on your ecosystem. Own it.

Yes. Lovable is pretty much untouchable for serious businesses going forward until they clean up this mess. And even then.

[delayed]

Lovable more-or-less presents itself as 'Wordpress for applications'. That comes with a whole pile of responsibilities and a large chunk of their customers may think they are doing a good thing by picking them instead of hiring a dev team.

"Build something Lovable

Bring a new product, internal tool, or entire company to life."

You can't market like that without having the back-end rock solid. There isn't a word about risk or responsibility there, but there are plenty of disclaimers of responsibility in their terms of service and the CISO (active in this thread) does not inspire confidence.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

Idk why I’m acting like a person read my comment. May as well ask you to write a sonnet for all this addressed what I said

Would it be better to right now risk forcibly (for new apps) breaking a few things to prevent passport details from leaking?

I think the problem is rooted in consideration of the architecture itself. The post mentioned one of the common patterns where people leave permissions too wide, suggestion is to let another LLM take a run at it to make some changes.

My personal reading is that people find it easier to put another bandaid on the top of existing one on the name of security. A sprawl of monitoring and automation tool give a sense of security while adding to the cost. It might be worthwhile to let it be visible to user, who can see the data, who can modify the data when it comes to self vs other and authenticated vs unauthenticated. And of course people are going to try to save money, these scanning features are going to show up as additional bill pretty soon.

We noticed that many projects come from earlier builds. Roughly speaking, building an insecure app is much harder today than 6-12 months ago. Agent will protest and try to suggest alternatives if the builder asks to have no security, for example. But some folks find it easier to build with no RLS and then add them later. But for a complex app, it's a hard task, things break etc. In our blogs, videos and office hours, I always recommend building with all security features on from the beginning, never trying to slap it on top after the fact

We are committed to keeping scanners free. A new UX for security rolls out soon (this month), will get a better understanding of what is wrong, who can see what and why important to fix.

Yes unfortunately security suffers a similar fate everywhere. For MVPs its a cost which is not tied to any revenue so it gets pushed on. Over the period of time you have built ecosystem of applications and services in a incremental way to provide features that customer asked for. Ironically no customer asked for the security explicitly, it was that non-functional requirement that exists in bare bones in some form. Its most likely not the part of architecture for sure in almost all the places, if an architecture exists.

The biggest revenue you will get is from enterprise customers and thats your biggest risk too if security goes south. You already have advantage of being close to customer stories and usage behavior. Some one within the company needs to build the platform again from grounds up with all these security requirements baked into the architecture, sort of parallel project one would say.

> We are committed to keeping scanners free.

This sounds like a good sentiment in theory, however this is a double edged sword. Scanning costs money to you as company and that cost is going to make it to the customer one way or another

Indeed, we are looking into having a path to take down apps that grossly violate privacy and data protection. It's a bit tricky legally so we need to find a good balance. Our thinking is so far: notification with ask to fix, grace period, if no action and no improvement - soft block until issues fixed.

> some apps will still do it.

> these apps

Why do these companies think of their customers as total morons. Publicly demeaning them and blaming them for being victims of their stupidity is beyond ridiculous.

> And that's why I believe auto-fix will solve a lot of problems in this space

Then why didnt you do it. Why would users be interested in your 'thoughts'

Auto-fix is tricky to get right without breaking the apps (imagine us having 99% of auto-fix success, at the scale of 10M apps, it would mean breaking 100 000 apps). We need to get really good at it - otherwise people will be burned by it and will never trust it again. But it's getting really good, I hope we will be able to release soon.

> We need to get really good at it - otherwise people will be burned by it and will never trust it again

As opposed to?

Then why were those apps allowed to run unsecured for so long that they gained enough users and their owners developed said fear about security fixes? Why do they have said fears in the first place? Maybe they don't trust your platform? You said you're company is committed to make security accessible - well, you failed big time. Yet you're unwilling to accept any blame and instead you're trying to shift blame to your users.

It's infuriating how little responsibility you are taking. And it's downright shameless of you to come here with this attitude and try to soothe the outrage with AI speak.

> Why do they have said fears in the first place? Maybe they don't trust your platform?

To be fair, one can harbor a fear of updating after bad experiences with entirely unrelated software.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

The fix is security by design, not the "auto-fixes" you ask customers to apply.

Yeah, exactly. Enforce security even if it breaks apps after, say, a 7 day or 14 day cool off. Lovable markets itself as offering a solution for building apps to those who lack technical skills so should take more responsibility. Saying “we told people” and then washing their hands of it isn’t acceptable because their target market doesn’t understand the technicalities.

> Work on educating users (...)

unacceptable! it's all about the vibes!